Welcome to this new episode on the OWASP Top 10 vulnerabilities series. Today, you’ll learn about the OWASP Sensitive data exposure vulnerability. If you already now the theory behind this vulnerability, you can practice on this tutorial.
The agenda will cover the following:
- Define what is sensitive data exposure
- Explain Sensitive data exposure types
- Show you some attack scenarios
- Share with you some related HackerOne reports
- Explain the impact of this vulnerability
- Teach you how to prevent Sensitive data exposure
What is sensitive data exposure?
Each month, increasing exabytes of data get transmitted on the globe. The data sensitivity ranges from cat videos and static landing pages to Personally Identifiable Information (PII) and nations secrets.
But how to distinguish between sensitive and no-sensitive data? Well, this depends on many factors. For example, you can measure the impact of disclosing your data in terms of Confidentiality, Integrity or Availability. In fact, the general idea is to measure what would be the impact of this data if third-parties know about it. For example, an e-commerce website’s database is sensitive because it holds Credit Card records and personal data of its customers. If an unauthorized party accessed it, all customers’ identities and financial situation would be at risk.
When critical data lands on unauthorized hands, we can qualify it as sensitive data exposure.
Sensitive data exposure types
We can divide the data into two broad categories, data in transit and data at rest.
Data in transit
Data transmitted over a network is considered data in transit. For example, when you browse the web, you generate HTTP traffic which carries data between you and the target server. Because it is in motion, this type of data can be targeted in many ways:
- Sniffing: When the network traffic is not encrypted, an attacker can perform a Man-in-the-middle attack (MITM). For example, if you land on a website which asks for your credentials without using HTTPS, your credentials will transit in cleartext.
Data at rest
All data which doesn’t move in the network is at rest. This includes archives, backup files, databases, etc. So how this data can be at risk if it doesn’t move? Well, an attacker can access it through a lack of authentication, poor access control on a repository, etc. Consider this incident where a publicly accessible MongoDB database stored plaintext personal details of Millions of records.
Sensitive data exposure attack scenarios
Since Sensitive data exposure is a broad vulnerability, we will explore some scenarios which would help understanding when a vulnerability falls into this category. Later, you can also practice your skills on this hands-on tutorial.
Attack scenario 1
A web application allows users to search for available books based on keywords. Unfortunately, a SQL injection in the keyword parameter allowed an attacker to dump the authors’ table, which included PII information in plaintext.
In this scenario, there are two problems, the SQL injection and the plaintext data. However, the problem which relates to Sensitive Data exposure is the latter. In fact, sensitive data should never be stored in plaintext.
Attack scenario 2
A web application doesn’t properly protect log files. This allowed an unauthenticated attacker to read them. Some log entries contained login requests with credentials in the GET parameters. This led to a massive credential theft and a huge compromise of multiple accounts.
In this scenario, the sensitive data was transmitted using GET parameters, which is a bad practice. In fact, GET requests get stored on logs, browser history, bookmarks, etc. Unauthenticated access to the log files themselves is a problem which belongs to Broken authentication, which is not directly related to Sensitive Data Exposure.
Attack scenario 3
An internal hospital web application allows staff members to sign up, log in and upload healthcare data. The application uses HTTP. An attacker compromised the hospital’s Wi-Fi network. Because there was no Network segregation, the attacker was able to listen on HTTP traffic and capture the session cookie of the admin user. He then authenticated to the application and modify data for a target patient.
In this scenario, the problem related to Sensitive Data exposure was in the fact that the application used an unencrypted protocol to carry sensitive data.
As you can see, Sensitive Data exposure vulnerabilities focus on data itself. In other words, giving that an attacker got access to your data or can sniff the traffic carrying your data, what defense mechanism do you have to prevent him/her from exploiting it?
Sensitive data exposure Hackerone reports
These are some real-world vulnerabilities related to Sensitive data exposure.
- In this report, Twitter publicly exposed a production API key on GitHub. The impact was not tangible, hence the low bounty amount. However, this is a great example of finding sensitive data exposure on GitHub.
- In this interesting report, the hacker dumped hashed passwords from the database. However, he found a key in another component inside the DB, which allowed a potential Remote Code Execution. This is an interesting sensitive data exposure PoC to demonstrate that all sensitive data should be encrypted.
- In this report, you can see how separation of privileges can properly reduce the impact and prevent Sensitive Data exposure. In fact, the hacker found a SendGrid API key which allowed him to impersonate Uber when sending emails. However, the API key’s permissions were properly set to only send emails.
Sensitive data exposure impact
Exposing sensitive data to unauthorized parties has many serious implications. For example, if the data contains PII information, any leak can cause a fine under the EU GDPR law, which can go up to 20 Million Euros. Have a look at Facebook’s GDPR fines history. Besides, exposed data puts customers at risk, violates their privacy and impacts the image and revenue of the leaking party.
Sensitive data exposure remediation
To prevent such a vulnerability, you can implement many measures.
Firstly, you need to classify your data. This ensures that you clearly distinguish your sensitive data. There are many data classification policies which you’ll find in the references below. You can choose whatever you want based on the nature of your business. For instance, if you manipulate Credit Cards, then you’d go with the PCI DSS standard.
Then, you need to ensure proper encryption, both in transit and at rest. Make sure you comply with the standard of your choice. For example, there are specific encryption requirements for PCI DSS. I am not an expert when it comes to the details of each standard, but the general rule would be to use strong encryption algorithms and protocols.
Finally, apply the least privilege principle on the way you access your data to reduce the attacker abilities to read sensitive data. For example, use unprivileged database users and grant only the permissions your business needs on the tables which support the feature.
For in-depth prevention measures, you can read the Sensitive data exposure prevention OWASP Cheatsheets in the reference section.
Data classification policies:
- PCI DSS policy: http://www.infosecisland.com/blogview/20167-Data-Classification-and-Controls-Policy-for-PCI-DSS.html
- Information Security Office Guidelines for data classification: https://www.cmu.edu/iso/governance/guidelines/data-classification.html
- UC Berkeley Data Classification Standard: https://security.berkeley.edu/data-classification-standard