OWASP Top 10: Sensitive Data Exposure (A3:2017)

15th July 2020 ‧ By Simon Bell ‧ Category: Web Application Security

4 min read

This is part of my OWASP Top 10 series covering the top 10 most critical web application security risks. If you've missed any of the previous security risks, check out the intro and overview.

Risk Rating

What is sensitive data exposure?

Sensitive data exposure, as the name suggests, is when information (such as usernames, passwords, credit card details, date of birth, etc) stored in an app becomes publicly accessible. Sensitive data exposure is different from a data breach. In a data breach, the leaked information is accessed by an attacker through unauthorised access.

Sensitive data exposure usually occurs as a result of not adequately protecting the systems where information is stored, such as databases. It could be caused by various things such as software flaws, weak encryption, no encryption, or human errors such as uploading data to the wrong system.

Examples of sensitive data exposure

Let's say Alice is doing some online banking. She's accessing her bank's website -- which encrypts data with SSL/TLS -- to manage her bank account. Mallory can see Alice's network traffic (e.g. through an insecure WiFi connection) but it's encrypted. So Mallory downgrades Alice's connection from HTTPS to HTTP. Mallory can now see Alice's network communications with the bank, and get Alice's session ID. Mallory uses Alice's session ID to hijack Alice's session -- allowing Mallory to access Alice's account and viewing Alice's sensitive data. In this example, the sensitive data exposed was the session ID which gave Mallory access to more data.

In another example, Alice enters her credit card information into an e-commerce website. Her credit card is encrypted, then stored in a database. However, the database automatically decrypts the data when it's requested. Mallory conducts an SQL injection attack which reveals Alice's credit card information.

What's the impact of sensitive data exposure?

Once an attacker gets hold of an individual's sensitive data they could use it to carry out various nefarious activities such as identity fraud or even sell the data on underground markets. Sensitive data isn't just limited to individuals, sensitive data of organisations can include intellectual property, financial information, plans, etc. If an organisation's sensitive data is exposed it can have many implications, such as impacting reputation, giving advantage to competition, etc.

How to defend against sensitive data exposure

First, it's important to identify and classify all data that an application handles. This includes data that's transmitted, stored, and processed. Identify how sensitive the data is and check with relevant laws, regulations, and business needs.

Once the data has been classified, controls can be put in place to limit access. Different levels of sensitivity may require different levels of control. For example, passwords and credit cards may require more stringent controls than, say, usernames.

Don't store data for longer than necessary. If you need to store information such as credit cards, use Payment Card Industry Data Security Standard (PCI DSS) to ensure the data is held in a secure environment. Ultimately, data that is not retained cannot be stolen.

Use encryption and check it's up-to-date. All stored sensitive data should be properly encrypted using the most up-to-date algorithms and protocols. Encryption keys and certificates must also be managed correctly.

All data in transit should be encrypted with SSL/TLS. Keys should be changed frequently to reduce the impact of compromised keys (perfect forward secrecy). Our example above -- where HTTPS was downgraded to HTTP -- could have been avoided by using policies such as HTTP Strict Transport Security (HSTS).

Always hash passwords (one way encryption) using salts to mitigate rainbow attacks. Use hash functions with work factors; they're computationally expensive which reduces the speed / increases the cost for an attacker.

Independently verify an applications settings, configuration, and potential weaknesses. Some sensitive data exposure weaknesses can be reduced using automated tools such as Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST). However, not all sensitive data can be automatocally classified and detected.

More on OWASP Top 10

• OWASP Top 10: Intro
• OWASP Top 10: Injection (A1:2017)
• OWASP Top 10: Broken Authentication (A2:2017)
• OWASP Top 10: Sensitive Data Exposure (A3:2017)
• OWASP Top 10: XML External Entities (XXE) (A4:2017)
• OWASP Top 10: Broken Access Control (A5:2017)
• OWASP Top 10: Security Misconfiguration (A6:2017)
• OWASP Top 10: Cross-Site Scripting (XSS) (A7:2017)
• OWASP Top 10: Insecure Deserialisation (A8:2017)
• OWASP Top 10: Using Components with Known Vulnerabilities (A9:2017)
• OWASP Top 10: Insufficient Logging and Monitoring (A10: 2017)