Sensitive Data Exposure, an OWASP Top 10 vulnerability that often affects smaller players, can put critical sensitive data at risk. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their list of the ten most common vulnerabilities one by one in our OWASP Top 10 blog series.
Sensitive Data Exposure occurs when an application does not adequately protect sensitive information. The data can vary and anything from passwords, session tokens, credit card data to private health data and more can be exposed.
A few examples would be exposed data that someone mistakenly uploaded somewhere, weak crypto that means an attacker would be able to read the data if they successfully compromised the target and the lack of headers that prevent browser caching. In short, every possible way where it would have been possible to better protect the sensitive data.
When building an application, many are going to down-prioritise protection of sensitive data, and even if the developer is aware of the fact that they should, for example, hash passwords, it is common to plan to do this afterwards. A workable application is the top priority and once the application is working, the planned protection is forgotten, or simply skipped.
Dealing with crypto is also one of the most difficult things to do. It is therefore common to make mistakes when implementing a self-built solution, which will result in insufficient protection of data.
Sensitive Data Exposure is therefore a typical vulnerability that is worst for small players, like hobby projects and smaller companies. However, as can be seen by looking at some well-known events, big players are affected by these vulnerabilities as well, but not as often.
As the finding only applies to sensitive data, the potential impact is always considered high. What the data consists of varies and so does the impact. The danger lies in the data being exposed, and the potential impact reflects the data’s sensitivity.
For example, if credit card data is stolen, the attacker can empty the victim’s bank account. If passwords are exposed, the attacker can abuse these credentials. If certificates are stolen, the attacker can pretend to be the target. It all depends on what kind of data is at risk of being exposed.
Most crypto-related vulnerabilities are considered hard to exploit, especially on a larger scale. With that said, some of the vulnerabilities that fall into this category are really easy to “exploit”. If an attacker were to get hold of a database that had been left unencrypted, they would not need to do anything special at all to access sensitive data. With a layer of protection removed from the attack process, exploiting the vulnerability can be considered easy.
In general, with the exception of strictly crypto-focused ones, the vulnerabilities within this category are likely to get exploited.
100 million passwords in plain text from VK.com have recently been leaked. That means that the attacker could, after getting access to the database, login as any user of choice. It also means that if a user were to use the same password on VK.com as on another site, anyone (as the leak is public) would be able to use these credentials to logon to that service and cause great harm.
Another example of a different vulnerability still within this category are exposed tokens in public source code. Many companies have mistakenly exposed private sensitive tokens on Github, which we have written about before. By searching for publicly available code, an attacker could get full access to internal communication.
How to discover
This is not a vulnerability that you can look for in the same sense as other more traditional vulnerabilities. Most vulnerabilities within this category cannot be scanned for due to two main reasons:
- To determine risk, it must be decided what information is considered sensitive, which can be a hard task to carry out automatically.
- An external pentester cannot know whether internal data is encrypted or not as that is not exposed.
To assess whether you are vulnerable to Sensitive Data Exposure, read the steps under Prevention and establish if any of the steps have not yet been taken. In most cases, this is the only way to identify this vulnerability type.
However, some of the findings can be automatically scanned for, such as lack of sufficient headers to prevent caching behind pages that require authentication or lack of HTTPS on logins.
How Detectify can help
We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Detectify is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 700 vulnerabilities, including OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable »
Example of vulnerable application
As the finding includes every case where sensitive data is exposed or insufficiently protected, the examples are many. To get an idea, here are a few of the most common ones:
- Data stored in plain text, such as passwords or credit card data (see the first well-known event)
- Lack of HTTPS on authenticated pages
- Hashed passwords with lack of salt, making the password easily cracked
- Tokens disclosed in public source code (see the second well-known event)
The first step is to figure out what data can be considered sensitive and therefore important to protect.
When that is done, go over each of these data points and make sure that:
- The data is never stored in clear text.
- The data is never transmitted in clear text. Example between database and server, or over the internet.
- The algorithms used to encrypt the data are considered strong enough.
- The generation of the keys is secure.
- Browser headers are set to not cache when the sensitive data is presented to end-user.
There are more things to look for when securing data, but what matters most is understanding what data is considered sensitive, and make sure it is treated as such in every instance.