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:
- data that is stored (at rest)
- data that is transmitted (internally between servers, or to web browsers)
In both cases, problems occur when sensitive data (banking information, health records, Personally Identifiable Information) is not sufficiently protected:
- if transmitted or stored in clear text
- if encrypted or hashed with a weak algorithm
What you must understand is that an attacker will try the following:
- decrypt data stored on a server (previously stolen through other kind of vulnerabilities),
- intercept data between a server and the browser (of between servers)
- trick your web application to do several things like changing the content of a cart in an e-commerce application, or elevating their privileges…
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…).
How do avoid such vulnerabilities?
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