A recent news report about a travel services company who has been fined £150,000 by the Information Commissioner's Office for a breach of an 'internal' system, hosted on the same server as their main e-commerce website (that lead to the compromise of over 1.1 million credit/debit card details) has driven me to write this post, so that further incidents of this type do not happen.
They Will Still Find It
Just because you haven't told search engines about your internal system, doesn't mean that they won't still find it. Your easiest method of stopping them is a robots.txt file that denies access to your application from search engines.
However, even this isn't foolproof. Malicious attackers have created custom search engines that explicitly ignore the contents of a robots.txt file, and in fact use it to tell them what to look for.
The best way of keeping confidential, internal systems secure is to run them internally, on servers that aren't accessible from the Internet.
It Only Takes One
If you are going to run 'internal' applications on your public servers, please keep in mind that ensuring the code developed for your internal application doesn't expose your server to basic security attacks is even more vital.
In the case of this travel services company, their internal application (which they thought no one outside the company could find) was vulnerable to a SQL Injection attack, which enabled the attacker who compromised it to gain access to the database of their e-commerce website, which contained the credit card details of all their customers, dating back to 2006!
People outside the security industry often think that an attacker has to compromise each website or application they target separately - this is not the case.
Your separate websites or applications often share resources on your server, such as the application that they use to store their data. Therefore if you can compromise one application's access to that shared resource, you can often escalate your access privileges and get access to the data from other applications that use it.
It's Not All About Passwords
Another common misconception people outside the security industry have is that the only way to compromise a website involves cracking the password of an existing user. This rarely happens in practice.
More often than not, websites are compromised through small, but significant flaws in the code that was written by the people who developed them. These flaws have no impact on the normal operation of a website, so they often go undetected until an attacker exploits them. By far the most common of these is a SQL Injection vulnerability.
Simply put, it occurs when the developers of a website or application fail to properly verify the data supplied from user input fields, leading to the ability for an attacker to replace the legitimate database query from the application, with one that they have written themselves.
This enables an attacker to tell the database server to do anything that the user account that the application is using to connect to the server can (which, if it's been configured properly, and the database server is up to date, should be very little outside of the database of the vulnerable application).
One of the things they can do is to dump a list of other tables in the database that the compromised application uses, and then use that information to dump the contents of user tables (including your passwords).
If, as was the case with this security breach, your database server is itself vulnerable to further attacks, an attacker can use the access they have gained through SQL Injection to exploit the server and then gain access to any database it contains.
More Pain On The Horizon?
There is of course another aspect of this story that hasn't been covered much - the response of the credit card companies.
When you decide to run an e-commerce website and accept credit/debit cards, you are required to ensure that your server, website and any other system that those details pass through is compliant with the Payment Card Industry Data Security Standard (PCI DSS).
This standard ensures that the card details that customers give you are stored securely, and not retained for any longer than necessary.
Failing to comply with PCI DSS can lead to your merchant services provider (or the PCI itself) suspending your ability to process credit/debit cards, and also issue you with a fine that can reach millions of dollars.
Security Experts Are Here To Help
The penalty notice published by the Information Commissioner's Office identified that the affected application had not undergone any security assessments since it was put into service.
Had the company had a security assessment of their application done before it was deployed, they would have discovered the SQL Injection issues and fixed them before anyone had the chance to exploit them.
People may think that security testing is an expensive waste of time, and that they don't need it - but it is often the only way security issues can be found (until of course, someone actually exploits them).
In the face of a £150,000 fine, plus any compensation claims or additional fines from other organisations, spending a few thousand pounds for someone to make sure that your systems and applications are as secure as possible seems like good value to me.