In this lecture we will talk about the major issues in internet security for non IT managers involved in secure web projects or operations, and for us all as consumers using the internet for banking, shopping and social-media.
We will consider firstly the largest threats; look at some of the technical means of attacking and defending our security at the user level - also touching on server level diligence - ; visit a complete alternative to open internet traffic for encrypted communication ; look in more detail at some of the potential technical loopholes or hacker opportunities ; and then summarise what steps should be included in web site development; At the very end ,as not just an appendix, we will discuss the highest level of practical internet security used for consumer banking today, the digital token system.
Acknowledgements and further reading: In compiling this I am very much indebted to the Harvard University E75 course, as streamed on Academic Earth.com and conducted by Professor David Malan. Please regard this as the main reference material for building a less technical while well informed background to this lecture. The course has been excellent in extending my own knowledge as a largely non-technical project leader earlier within the industry. One thing which inspired me to write this is actually the verbose and often esoteric nature of many wikipedia entries relating to internet technologies, but for all acronyms I would refer the user there as I have at least followed them up and used some as information sources, all authors recognised and copyright not infringed.
The Major Threats in Internet Security
The biggest security threats to your use of web sites and related e-mails on the internet today are all from what we could summarise as euphemistically " human error " namely ** :
- Phishing scams and resulting identity theft, or temporary seizing of control of bank/shopping accounts- the human error in opening the links!
- Sloppy programming allowing for loopholes like SQL/script injection and session ID capture, as well as link mediated phishing scams or copy-cat web sites.
- Using your own laptop in an open network or public Wifi spot... and resulting identity theft or temporary seizing of control of bank/shopping accounts
Threat #1: Identity Theft and Open Public Networks
Having someone hijack your facebook session ID and log into your facebook may seem trivial and just irritating, but in doing this they can get enough information to commence a very good identity theft. Also your session may be with a web shop who have lax security "around the edges" meaning that someone could control your account details, deny you access and use your credit card or balance on the site to make purchases or bogus payments.
Why are public WiFi networks not safe?
Public WiFi is one of the main threats to internet security, when you engage with a public network or do not suitably protect your home or office WiFi. Passwords sent over a public network , Starbucks, etc, are completely open to copying if there is no SSL or Javascript VPN encrypting communications.
On any non https (SSL) web site, or web page for that matter, your data communication is completely open on a public network: so you are exposed to potential identity theft and more sophisticated phishing scams which use other communications like SMS, e-mail and telephone calls to coerce you into giving out more information over a web URL address, leading to theft.
For example, Wireshark - formerly Etheral - sniffs wifi or other routers and can intercept any packet of http on an open network router like in a wifi hotspot.
Even with SSL you could be victim to an attack from a local computer on the Wifi /LAN running a copy-cat site which intercepts your internet traffic and makes you believe you are entering user name / password to the real world version of the site. ( A.k.a. "middle-man-attack")
The same is actually true for FTP: the password can be intercepted on a network which is not secure, and standard http where the http packets can be intercepted by third parties. SFTP makes FTP passwords encrypted.
A "Perfect" Secure Solution is Out There: VPN - But at What Cost?
The supposedly perfect means of connecting in a secure way over the "Internet", is actually to go against all the usual principles of free movement and negotiate a VPN: a virtual private network.
These are similar to WANs og GANs (wide or global area networks) but use a higher level security by encrypting everything using a private key, not communicated over the internet/WAN. Sometimes VPNs dispense with usual TCP-IP and have alternative connection protocol and technologies centred on encyrption.
The VPN relies on a defined route over the internet, sometimes between just two internet nodes / routers, and crucially it relies that both sides have the same private network key for encryption, or synchronise this key in a way which relies on the closed loop of the key never being transmitted. The VPN is yet more secure by being relatively private or closed off from the rest of the internet traffic at the router level, where interception of data by hackers could be possible.
However VPNs are largely impractical and overly expensive for most e-commerce applications where users, sorry consumers, are not readily able or willing to set up a secure encyrption key. It would mean that for simple shopping on the internet, people would just move away from the shop asking for VPN set up, going to a competitor. Consumers are used to simple steps using https, a password and for lower value transactions with the big brands or trusted sources, they are comfortable with the level of risk.
Also we would undoubtedly have to pay a lot more for our connection to the "internet" in using this kind of ring-fenced data route (a.k.a a tunnel).
On the other hand, with the use of token mediated security, the cost and time of establishing VPN between high value consumers and their banks and secure trading areas may outweigh the risks of using http and https at some point, or at least the percieved risk.
However, this could lead to a false sense of security, and hence if someone does take control of the remote computer or hack the server, then any delay in detecting this could lead to a higher relative financial or IPR loss because the stakes were probably high enough to pay for a VPN in outset.
Threat # 2: Sloppy Programming
There are several areas which are subject to security breaches caused by sloppy programming for want of a better word for lazyness or poor project resource- invesment.
- Server Side issues: File Management, Security, Configuration and so on.
- Web site areas which go in and out of secure pages while the "session" is still continuing
- Making code easily copyable such that someone can fake your web site in a phishing or middle-man scam.
- Not programming out loopholes in how information from web sites enters the web server- allowing for SQL/PHP or JS scripts to control the server log in area or crash the server
- Not managing the session ID ( cookie) in a secure way which means making them expire and replacing the ID number next time with something which cannot be guessed from the previous one.
- Neglecting to use POST data for some important stages when a visible GET URL is shown instead, exposing a security risk.
It should be pointed out that the small JS programming routines (scripts) operating in the browser, which do things like allow for only 10 characters in a user name, or ensure the operators " <>&%?" etc in a field are invalidated or neutralised (escaping the data), also help increase security from unforseen attacks with new command lines.
We will cover most of these types of attacks in a little more detail below. Realistically they can all be managed-out with due diligence routines in the security section of a sweb project, long before launch.
Don't Take Your Internet Browser For Granted
What we actually rely on for much of our internet security at home, is not our ISP or national DNS authorities, but our humble internet browser.
Sometimes new techniques evolve within the possibilities offered by the internet, which mean that hackers can gain access to information being passed to-and-from, or held in our PCs. Or worse, they can take control of our own PCs over the internet, or actual entire web servers.
One example of this was when Javascripting allowed for pop ups and there was possibility for cross domain JS scripts running automatically before you could stop a cascade of new windows opening.
I myself lost control of a laptop once by wandering my cursor over a gambling banner-ad' or icon, clicking by accident: it opened many casino sites and some hard porn sites in Russia, dozens of them within a couple of seconds, which in turn opened a download dialogue and landed a trojan horse executable in the background which was active just before the antivirus found it and was therefore able to run several exe's essentially taking administration control of my machine and not allowing me to even use CTRL-ALT-DEL to find out what was running!
The pop up issue with JS (javascript) above, lead to a rapid introduction of new security measures in the browsers. This included the control of all pop ups which are cross domain, or those which automatically ran the scirpsts leading to this action, and involuntary start up of scripts running file management actions ie auto down load of files out of your control.
The latter versions of all main browsers, have closed down this type of activity so you have to opt in to opening such pop ups, third party scripts, file downloads and external links with a warning controlled by the browser, so clicking "cancel" does not take your vote for the Republicans. This has of course gone further with more restrictions within Hot- and G- mail interfaces for example, which block all html link and script content at source code level in e-mails.
Browser security is an arms race which has, by-in-large for now, been completely won by the leading makers of browsers. Hackers spend more of their energies trying to capture data in transit, steal identities from snail-mail, or catch out our sloppy programmers as mentioned, rather than programming work-arounds for browser security.
Internet Explorer, FireFox, Safari, Opera and Chrome hold the majority of the world's internet access in their hands, and do really an admirable job for what is freeware! These programmes contain the https (SSL) encryption and certification system, the controls of javascript and the security rules on what web sites can and cannot access: for example web sites should not be able to view other web sites cookies (as info references, stored user names or session IDs): and one web site may not use scripting from another source by the policing of this by the browser in the standard cross domain policy.
However, despite having just stated that the battle against browser mediated hacking is "won", microsoft/Apple/ Mozilla/Google all keep ahead of potential or emerging threats by updating their software, which is more or less automatic for you and me. Therefore you really should not impeed the progress of updates to IE, Firefox or Safari because despite this being free, it is of high value to you!
Threat # 3 : Server Hijacking
One of the nirvannas of hacking used to be gaining control of supposedly secure servers. Now as e-commerce and web serving perhaps becomes more widespread or under cost pressure to offer cheaper hosting, non IT managers should be aware that investment in resources and best practice in this area is essential.
Apache and other server secutiry issue: super user status: on default programmes running on linux Apache, the super user is "Root", and this means that some programmes running are actually at the level of super user, so if they crash or are manipulated then an external hacker can run the whole server by assuming that super user during and after the crash. This is avoided by having a different default super user on an internal machine, so that programmes crashing just crash or the server needs to be rebooted by the administrator with those permissions.
When web pages on a unix/linux system are served via Apache, then the permission to access is fully public, but the properly configured apache server will send your dot com or IP requests at top level domain just to index.php or -.html and send the request in dynamic web URLs to the file to be processed to give a result ( expects the result to be the reply to the URL request, say a GET$) and NOT the actual source code. Other users on the APACHE served network could see your source code though , but there are other security programmes which empose a layer of administration permission onto your own file area: eg suPHP, substitute user PHP.
Some web hosts will however, configure their linux environment so that the Apache has super user access, and allows for a public route to the served content and operations, while not allowing file admin to anyone but the owner of those web sitess, and the apache /linux super user administrator. If there is a php environement running anyway, then suPHP does this rather well according to Prof. David Malan at least, so the extra work is probably not worth the time. The permission can be applied to directory AND file, such that if abberant files or hacks can be stopped from working.
Threat # 4: Cookie and Session Hijack Issues
Cookies : storing user name and password in a cookie is a bad idea, because it is both open over any open network when you connect to the owning site and communicate these details over: and if your machine is compromised or you are on a shared machine, it is there as a visible text on the hard drive. Https only protects in transit, and quite a few web sites are sloppy, starting a user session and setting up initial user name cookies outside the https encryption, meaning the cookies can be read by interceptors.
Sesssion hijacking means the open account, after password is passed, has the cookie and session ID running and can just be copied and while you are logged in. The other hacking user can have a duplcate session running: this is why re-set password should include re-iterate current password so that they cannot just exclude you from your own account from such an interception and temporary hijack.
Sessions are useful because http is not a continuous connection, and also now you have quite a lot of JSON/XML/Ajax/API functionality in the background giving you useful data while you are logged into an area or otherwise in a "session".
Google analytic cookies: google gets around the cross domain policy because they are so often opted in on so many sites, becase they offer those sites free web stats in return. This means that they can link the information on where you have been because they are the same domain accessing and laying the cookie upon request. As we will see a phishing URL could mimmick google while actually sending cookie data to an third party site in an XSS conflict attack.
Browsers though can disable such third party cookies ( 'external site' in firefox), but at the moment is is not a default and in fact in FireFox's latest versions it is actually only specifically in add ons which must be installed seperately.
Session IDs can be completely random, because they are huge numbers in PHPs session ID engine for example. The chances of a hacker second guessing one is low, in relation to a user name, and the chances of two users on the same server and web site getting issued the same session ID are null if the random issuing is not reiterative through a pseudo random listing.
A cookie's sphere of influence or reading can also be limtied to certain file directories in the server URL / directory set up, in the little packet of info in the cookie which helps restrict GET URL theft of Session ID or use of it further.
The Major Cornerstone in Today's Internet Security: SSL and https
When you see the sign for https then you know you are utilising a line which encrypts form data and information coming back from the site, using a certified system integrated on servers and browsers called SSL ( secure socket layers).
Https is what you see at your end, as well as some dialogue pop out window warnings, usually about entering or leaving a secured area. Also you may be warned that the Security Certificate for a web site is expiring, which means its accreditation to most often microsoft, has run out.
These little warnings about entering and leaving a secure area may be annoying, but if you are using a public network it is very well worth noting that you may still be "logged in" and using some facilities private to you while the "http" has lost the little "s". Thus your communications are open again. It is worth deleting all cookies when you leave a public computer or making sure you log off from the web site you were on before you shut down the machine or window.
Using https helps the problem of potential router-interception or public Wifi network session hijacking, but it is still possible that any info or pages not in https reveal the cookie session ID on a public WIfi network for example or an insecure router. Such a hijacked session could then revert to the https area and abuse your account or credit card.
SSL/https is not supported by all serves ( if not all routers ?), and most sites which have https requires that bit extra time and processing means that after log in , facebook amongst others kicks you over to standard http and uses a session ID. So https is a performacne and server capacity issue, but under the UK dataprotection act at least, personal details linked to web registration, would be reasonably expected to be protected by SSL as a consideration for due diligence.
SSL: secure socket layers; SSL Certificates : What is all this About?
SSL certificates usually cover one domain name on one IP address, and they are issued/certified by your trusted domain name partner, like network solutions, Verisign, Go Daddy etc when you buy an https ready web domain.
The browser types themselves, like IE 6, have approved SSL partner lists from Microsoft, giving a certain level of confidence and meanign that you should have a host which is on the MS list for SSL certified source. Having one enables you to receive and send https on the network or internet routers. The >SSL certificate contains a code which denotes the vendor.
You can get a *.com 'wildcard' SSL for a single IP address running as a virtual web host, but this is expensive and the key will possibly be the same across all the web sites you have running there. However given good apache / linux file admin, this can be attractive for TLD names and sub domain level name security.
SSL's Public Key Encrytpion Practice and Theory
SSL's system is sometimes called assymetric encryption, because the users have a their own respective public key and this public encrytping key is different to the decrytpting key, the private key.
As a new customer / visitor we do not have a shared secret key in advance : the shared secret would be sent "In the clear" so it could be intercepted.
Public key and privat key are generated at browswer installment time, and at the SSL certified server side when say Apache is installed or upgraded to SSL at that unique IP address. There is actually a mathematical relationship between the public and private keys.
What happens is that you communicate the public encryption key to each other and send the data encrypted to this key, while it is actually decrypted by a local private key. Your SSL public key is open for any https connection to read, and that web site will then encrypt using that key, but only YOU can decode that encryption. The reverse is true for sending data, you get the servers public key code when you request an https transaction and only the server can then decrpyt that - in theory, using their private key.
Elegant!
Theory:
The two numbers as mentioned are related to each other, and the public is generated from the private : to overly simplyfy: the public is the private to the power n for example with the private being a prime positive integer for example. The public numbers are shared to perform a one way encryption of ASCII and other characters over to numbers. The public key can be accessed, but the computational power needed to decrypt any messages would be so huge that it renders it unpractical to do so.
Issue: is middle in the man attack or of course hijacking in either an internet cafe scenario: someone on that network intercepts your https initial request to say amazon, and presents themselves as amazon, sending a key they of course can decrypt. The same could be true if a mis-spell or an expired domain name is hijacked, and maybe you return there with your pass word and user name, and they then ask you to reissue your credit card details.
Other Security Risks Relating to Sloppy Programming :
SQL Injection Attacks
This means that a SQL coding is written into a form field/s and then submitted then becoming a query ie a valid SQL command. This is worked around by 'escaping' the syntax, like apostrophes which enclose a string to be submitted: the content of the field string then becomes like CDATA, and this can be done also at the javascript level to help users whose names contain "illegal" characters.
Same Origin Policy Breaches
JS code does not allow for direct republishing or integration of data in JS from cross-origin web sites. RSS and XML do allow for this, usually done server side through importing via PHP , but that is safer than allowing JS to roam the internet outside the origin who wrote it. So FB can update to itself in JSON/Ajax but not use this API
Third party javascript cannot look into your browser behaviour : so ad's cannot directly do this. Frames are the same, so you cannot manipulate a frame requested from another URL.
The data has to first be "imported" to your own or the common domain so that when served to you it is : the same is true of APIs: you have to copy google maps JS and then it is just looking for permitted flat data in their google maps repository.
CSRF ( Phishing email and bad web site links)
A commonly used web site which involves financial / buying can be embedded in a link in an email or a phishing site, which you click on and then it uses the session ID to then open a direct account: these can be hidden at the top of jpeg http requests, so you don't even click on them.
This can be worked around by good cookie management and requesting password for any buy or send sensitive data. Also this is related to URL GET$ so it is wise to use POST data for some key transactions.
Cross Site Scripting - XSS - Vulnerabiliy
This is similar to SQL injection: an HTML GET line or form submission is mimmicked in a link, which also may contain a script activation reference, overcoming cross domain policy. The first half of the URL is mimmicking the real web site and its form fill /submit page or GET $URL, but then also requesting a bit of javascript linking to the attacking site.
Once again, these URL links can be automatically run in http headers for jpegs etc, and hence hotmail and g-mail protect against content with links in HTML-mail.
The phishing URL will request a JS held on the Baddie URL which is embedded / referenced to the fake host URL. www.amazon.com/?....script js..document.location=
Increasing Security
Top Ten Tips When Considering Implementation or LifeCycle Updates of a web site which should have a diligent level of security:
- Block subversive commands in data submitted to your dynamic web sites ( "/&%" and so on) All GET$ and POST $ data being submitted should be "escaped" that is the string sent is like CDATA- the computer knows to ignore the content until it comes to the end of the escape
- You limit the legnth of the form $ to a known or reasonable number of characters in the POST/GET on server side, and you can do this with JS during form control.
- You also limit the characters possible to submit from the web form.
- You use POST data instead of GET$ in open URL, and call this POST command set up in a hidden file area from general web page code,
- Make sessions ID only temporary with an expiry inversely proportional to the potential personal financial loss from session hijack or reuse of a public computer.
- Request password ( or token key number, see below) at vulnerable points where payment is required, value is to be transfered or personal details and credit cards can be viewed.
- Re-set password should also include re-iterate current password so that a hacker cannot just exclude you from your own account from a session hijack. Ideally this should be accompanied by an e-mail or SMS action as in 8:
- To activate accounts or change e-mail addresses to accounts, you force an e-mail to be sent to the original email address on the original registration: you keep this field as a locked UID for the user and copy the e-mail address over to a field modifiable by the user. Consider using an SMS mediated activation code or temporary password from an original mobile phone number in this vain.
- Log suspicsious IP addresses which attempt the submission of SQL/Bolean or HTML coding in form fields. Refresh session ID underway to those which are suspicious and leave a permanent cookie with a special user ID on that side to see if they repeat an attack. If the IP address is common to a small ISP, a university or the like, contact their system administration or security manager. Exclude IP addresses from countries with which you have no business with or are noteworthy sources of criminal internet attacks.
- When the transactions, personal information or IPR exposed is of significant value and the traffic volume is acceptable in cost-benefit, then consider either using an SMS key or password system, a digital token system or setting up a VPN connection to users ( See below) . The same could be true if you are aware that there have been many attempts or several successful breaches of security from user identity theft or Session Hijacking.
Technical Approaches in the Highest Level of Consumer Internet Security In Practice Today
VPN is one solution: virtual private network. This relies on a defined route, sometimes between just two internet nodes / routers, and also that both sides have the same private network key. This is discussed in some detail already, and we have mentioned the use of tokens, which are in effect symmetrical or highly encrypted assymetrical encryption keys.Another means of internet security for the highest levels of banking, software exchange (inc high value web services), film streaming and e-commerce itself is the use of "token" based password/ verification / encryption code. This adds an additional layer of security which is difficult to intercept and virtually impossible to guess. The token itself plus the log in and password would all need to be stolen from the user and used before they could alert the bank.
The most popular type of token is the stand alone, thumb sized medallion, which have a preprogrammed number generator which generate a password or encryption key number either synchronisously/sequentially done with the server or interpreted like an SSL key.
There are also dongle and cordless types which send the data when you allow connection, and latterly out-of-band tokens can be used which send an SMS or other datapacket through another type of telephony than the internet TCPIP.
In many banking web systems, the token key is a one time password and is requested both at log in and when movements or payments are to be made. Banks always use https and SSL certification, thus there is a very good extra layer of security requiring this token be to hand. If you had your token AND your identity stolen you would notice it, or be the victim of a "extortion with menaces" ie an off line mediated crime.
This further reduces the chances of Session Hijacking getting anywhere, but you could in theory still be open to middle-man scams if someone was really able to mimmick the bank site, and then pass the current synchronised token key on further in actioning fraud in your real web account.
Back End Security
The key issues of back end security arise beyond the SSL decryption on the server side. For example, log in passwords and credit card numbers are then fed back to the database server for verification, or initial data entry. This has in the past lead to employees stealing databases, or developers loosing laptops which included copies for WIP testing. Now even MySQL, the shareware, includes modules (eg AES) which allow for industry standard encryption of password: some use the ASCII coding in the password as the actual key, and this has some native appeal given the initial connection was SSL and the user keeps their password to themselves. The down side is that no one can know the original password, or even the legnth of it on better encryption, so if you forget it, then you have to register new or go through some other security checks and get it sent to you by e-mail or SMS.
ENDS--
Posts
No comments:
Post a Comment