Many companies now have a website that stores or collects their customers personal details and as has been highlighted by Sony recently, these details are often not as secure as you may think. As a business owner you are caught in the dilemma of not necessarily knowing (or needing to know) the details around how your website is designed, built and secured and that of ensuring that sufficient security is in place to protect that information. As a result of the major theft of data from Sony, where millions of their customers personal and payment details were stolen, we conducted an internal review to ensure that our internal policies and infrastructure not only met best practice, but also provided a measure of protection against the type of data loss that Sony encountered.
During this process we discovered what we consider to be some major flaws in the build of a lot of websites (albeit e-commerce and otherwise) that leave a lot of potentially sensitive data vulnerable to the type of attack that Sony suffered.
This article will hopefully go some way towards explaining the types of procedures necessary to properly secure your sensitive data and to highlight at least one common flaw in the design of most websites that could leave them open to the same level of data theft as Sony.
General Security
There is often a very large separation between your web developer and your infrastructure provider. Your infrastructure provider will provide the hardware (e.g. the servers upon which your web site is hosted), network connection and possibly the web server software itself, they may even keep it all up to date for you. If the server is on your company network it’s very likely you have a firewall between your website and the general internet, if it’s a shared hosting service provided by a third party this is less likely. Your web developer will usually focus on the design and functionality of your web site and not necessarily on it’s security.
Generally most security measures concentrate on keeping any potential threats out of a server, this will involve a large number of tasks undertaken regularly and (hopefully) with great vigour. All of these security measures are usually aimed at one thing, to allow visitors to access the services they are supposed to be allowed to and nothing else, i.e. not allowing anyone to gain access to the root or administrator accounts (e.g. site managers who have the permissions and capability to do anything they want to).
Most services running on a server will run under an account of some description (much like a user account but with even more restricted privileges), this is to prevent root/administrator access to attackers who manage to break into (for example) your web service.
All of this focus on infrastructure security leads to a tendency on many web developers part to assume that the website is secure as long as they follow one or two simple guidelines, and that anything further is the responsibility of the infrastructure providers. In fact several current practices leave sites vulnerable in specific ways that can lead to disaster.
Sessions and Cookies
As the internet and the World Wide Web in specific has progressed over the years many features have been added and built onto the original standards, the two most important additions, currently are sessions and cookies. Without these you would not be able to experience websites as you do now, there would be almost no e commerce, no webmail etc.
When the Web was first designed, it was for static pages, you went to a site and were displayed the index page, you clicked a link and were taken to the second page and so on. Now behind this concept there is no need for the web server to know, or care that the web browser who is navigating to the second page is the same person who navigated to the index page, the server just delivers the page. To enable such functionality as an e-shop, you need an e-basket that persists across pages, which under this methodology is not possible, and so cookies and sessions were born. A cookie is a small piece of data that is stored in your browser, the server sets this cookie and the browser will only deliver it to the server that set it in the first place. A session is a server concept, where small pieces of data are stored on the server and combined with a cookie enables the server to store things like the contents of your current e-basket, with the cookie telling the server that you are you.
However, all of this data is currently sent back and forth across the internet as plain text, which means that anyone with the right tools can potentially read the data your browser is sending to the server (and that the server is sending to your browser), including the cookie that tells the server that you are you. Again with the right knowledge an attacker can take this cookie and pretend to be you, and thus gain access to your current session on the server (which will usually include the ability to change your password, possibly read you personal data etc.) and so we move to the concept of SSL.
SSL
SSL (Secure Socket Layer) has two purposes, one is verification and the second is encryption. A SSL enabled website is identified in several ways, the URL starts with https:// instead of http:// and you will normally see a locked padlock or a green or blue bar in your browser. If you are viewing a URL that starts with https:// then all the data you send to the server and all the data the server sends to you is encrypted and so the data being sent back and forth should not be readable by a third party. However there are threats that mean that you are not visiting the site you think you are, hence the verification part of this process. Built into your web browser is a verification process that shows that the secure site that you are actually visiting is the one that you think you should be visiting, this is when you get presented with the green/blue bar and the locked padlock.
SideJacking
The threat of sidejacking has been talked about in the IT press quite a bit and still hasn’t been fully addressed in various websites. Sidejacking is a flaw in the development process of web sites and there is nothing the infrastructure people can do about it. It relates to sessions/cookies and SSL and provides an attacker a method to gain access to your on-line account even if SSL is being used. As mentioned above if an attacker can gain access to the un-encrypted cookie that identifies you as you, they can access your account and personal data. The process for accessing a site usually goes something like this:
- You browse to http://www.securesite.com
- Click login
- Land on page https://www.securesite.com
- Login correctly and start your activities
However, behind the scenes there are several things going on. Normally at point 1 the session is established and the cookie is set, once it is set for the browsing session most sites do not change it. Therefore an attacker can gain access to the cookie at point 1, wait until you login and then gain access to your secure account and all your details with it.
There are two ways to prevent this:
- Do not have a non SSL site, this is the best and most secure way of doing things, this way all access is encrypted, even the initial cookie, your clients/customers only ever go to https://.
- Your web developer needs to restart the server session at point 2 and the session needs to be stopped if ever your clients/customers leave the https:// to go to the http:// portion of the site.
Patching
So your infrastructure provider keeps all of your servers up to date therefore you are safe from having your server broken into right? Sorry no, a patch is a fix to an operating system or software bug that, in the case of a security flaw, would allow an attacker into your server. This means that until the patch is applied your server is vulnerable to that flaw, it also means that the bug in your operating system/software that the vendor/maintainer doesn’t yet know about is still in the operating system/software waiting to be exploited and fixed. Ultimately this means that even if your systems are fully patched they are still always vulnerable to the next flaw.
Data Sensitivity
So what data do you consider to be sensitive? Most people when talking about websites will say credit card details which whilst true is not the most significant. The rising crime of the moment is identity theft and it’s easy to see why, if an attacker breaks into a site they can also gain access to the list of used credit cards and then clone them. If they break into a site and gain access to personal details they can steal identities and apply for multiple credit cards, loans etc.
Therefore probably the most sensitive data on your site is your client/customers personal details, which will include name, address, date of birth etc. most of which is stored in a database protected by security, coded by your web developer, on your web server.
PCI Compliance
PCI compliance is a series of tests you have to go through before you are allowed to accept/process credit card payments, in this case on your website. It has a series of conditions you need to meet before you will be allowed to accept credit cards. So if you’re PCI compliant or you are accepting credit cards you are okay right? Sorry again, probably not in fact at least if Sony is any example. PCI compliance only applies if you accept credit cards on your site, so if you are using PayPal, or something similar where during the checkout process your customer is re-directed to a third party site to accept the credit card details you not have needed to be PCI tested and so probably aren’t compliant. Even if you are, a lot of web developers simply do not store the credit card details and thus you only need to meet minimal standards, which will mean personal details that are not credit card related could be stored in your database and accessible by your web server. Even if the details are stored in the database, but encrypted, they are often only encrypted at the web server and are open to an attack.
Encryption
Encryption of data is basically a process of changing the data such that it cannot be read by anyone unauthorised to do so. This will usually use a standard process and will use a key of some description. The use of this key is required to both encrypt and then to decrypt the data. A web developer will, if they are actually encrypting the data (most do not unless specifically required to do so), run the encryption process and store the key on the web server.
Sony specifically said that the credit card details that were stolen were encrypted however no details were released about the level of encryption, if it was possible that the encryption key was stolen, or if the personal details were encrypted at all.
The Problem
We have already established that your sever has a weakness somewhere (it may not have been identified yet but it is there), so therefore there is a possibility that an attacker can get into your server and therefore run commands as the user account that the web server runs under. The problem with this is that anything that your web service can do, the attacker can also do, including but not limited to:
- Access your database using the same credentials your web service uses, and therefore have access to the same data.
- Access your web service log files.
- Access any session details in progress.
- Read any web code on the server
So what does all of this mean in practice? Well if your web server can access all the rows in your database, so can the attacker, if your security filters are based on your web code, then the attacker can by-pass them. If your site administrator is logged into your content management system, the attacker can highjack their session and have a nice easy way to gain full access to your site. If you do encrypt your personal data and the key is stored in the web code the code can be retrieved and therefore any encrypted data downloaded and un-encrypted.
This is exactly what happened to Sony, the web server was broken into and all of their customers data was stolen.
The Solution
The solution lies with your web developer, you need to make them fully cognisant of the fact that you want your clients personal data to be secured. They need to determine how to store the encryption key off of the web server such that it is not accessible if the web server is broken into. During your discussions with them you need to insist that the data is encrypted and in such a way as to allow your admin staff to be able to decrypt as well as the customer themselves.
In fact it is at least as important that your web developer is as security aware as your infrastructure provider, because if they leave a flaw in your website code that allows access to your site, or even allows access to your un-encrypted data, you may release your clients personal details into the wild and never even know about it.
Sony have more or less regained their feet, could you?
Mark Bond is the Technical Director at IceStar Media Ltd.
This article was also published in Issue 37 (July/August 2011) of the Herts Chamber News.
