Still in our series of articles about web vulnerabilities, this 6th episode is about Sensitive Data Exposure.
As usual, we won’t dive into the highly technical details here (this would require several pages) and won’t therefore discuss cryptography.
This type of vulnerability is ranked number 6 on the OWASP Top 10 2013. These vulnerabilities are usually quite difficult to exploit by hackers, but the impact being really severe, it is very important to properly understand them and make appropriate choices in the application architecture.
We can make the distinction between two types of data:
In both cases, problems occur when sensitive data (banking information, health records, Personally Identifiable Information) is not sufficiently protected:
What you must understand is that an attacker will try the following:
Let’s take a simple example:
An attacker successfully attacked your server with an SQL Injection attack (covered in the first article about Injections) and has been able to retrieve a part or the entirety of your database, where you store the passwords of all your consumers. Unfortunately, the passwords have been hashed with a weak algorithm (such as MD5). The attacker will be able to use “rainbow tables” (plenty of them are available), to compare passwords of your database with pre-computed hashes of passwords. You can be sure your consumers’ passwords will be exploited.
Here is another example:
You did not protect authenticated pages on your website with HTTPS (SSL/TLS), or with a weak version of it. By “sniffing” the web traffic on the wires, attackers can see all transmitted data in clear text, including whatever information your website is dealing with (credit card info, login, passwords…).
1. The first step is to avoid dealing with data you don’t really need to collect on the website, and avoid storing data that does not need to be stored.
That sounds quite easy, and it is. During the functional and technical design of the web application, take enough time to evaluate the need to collect/store.
2. Identify sensitive data, and ensure it is encrypted with the appropriate algorithm, when transmitted, and when stored.
3. Ensure strong and non-deprecated algorithms are used.
The OWASP and many other sources of information will tell you which on is good and for which purpose.
4. Run a web application penetration test, to make sure you did not miss anything. Running a security audit periodically will also help you ensuring that your web application remains strong over time.
If you want to read more around this topic, I would recommend the 3 following cheat sheets (you’ll need technical skills):
OWASP Cryptographic Storage Cheat Sheet
OWASP Password Storage Cheat Sheet
OWASP Transport Layer Protection Cheat Sheet
