OWASP Top 10: Sensitive Data Exposure
Welcome to Secumantra! We are on a mission to understand OWASP Top Ten in detail and have already covered top two vulnerabilities – injection and broken authentication. In this post, we’re going to talk about the number three vulnerability in the OWASP Top Ten 2017 version which is sensitive data exposure.
OWASP (Open Web Application Security Project) is a nonprofit foundation that works to improve the security of software. OWASP Foundation is globally recognized by developers as the first step towards more secure coding. It releases OWASP Top Ten List every 2-3 years sharing the most critical security risks to web applications. For more details, please read our previous post here.
What is Sensitive Data?
Let’s first decide which data is is classified as sensitive data. It actually depends on the criticality of the data and business impact if it gets exposed. Few examples of sensitive data are –
- Banking information: account numbers, credit card numbers etc.
- Health and medical history information
- Personal information: Social security numbers, phone numbers, date of birth, etc.
- Login credentials
As the name suggests, security threat occurs when the web application doesn’t adequately protect such sensitive information. It may cause a financial loss, identity hijacking, blackmailing which ultimately results in decreased trust in the brand.
Sensitive data exposure occurs when an application accidentally exposes sensitive data. This differs from a data breach, in which an attacker accesses and steals information. Various causes that can lead to this are missing or weak encryption, software flaws, storing data in the wrong place, uploading etc.
Example Scenarios and Reasons
Let us divide this risk into three broad categories and look at few examples for each.
1. Insufficient Use of SSL (Transport Layer)
In 2010 edition of OWASP Top Ten, there was a dedicated risk for insufficient transport layer protection. It is kind of the same problem here.
Clearly you must post credentials form the login page over a secured connection (HTTPS). The other thing is that you must load that login page over a secure connection. If you don’t then an attacker can manipulate, redirect or do anything nasty. This is man in the middle attack and attacker can even manipulate the data sent over HTTP. Read more about HTTP and HTTPS here.
Once you logged in, you get a an authentication cookie. Now this cookie may be hijacked. If an attacker gets the cookie, they can become a valid use. So cookies got to be protected and transmitted over a secure connection.
Mixed mode is another example where website commonly get SSL wrong. They might load the page over HTTPS but then they embed things like JavaScript over http not thinking of what an attacker can do, if he can modify the JavaScript. He can control anything in the DOM of the page so he can now change the page to post data to somewhere else.
IMAGE PPT
2. Bad Cryptography
Another big risk in sensitive data exposure is bad cryptography. This can take few different shapes. So for example, how a password is stored. Commonly they are stored with no cryptography, which clearly is a bad decision. Sometimes they are stored with symmetric encryption. Now that’s also bad because if the application is compromised and the keys are obtained, then all of the passwords are immediately discoverable.
Using strong one way hashing algorithms designed specifically for passwords storage is essential. It is generally very easy to break a bad hashing algorithm used for strong passwords.
Poor protection of keys – if you are going to use symmetric or asymmetric encryption, the protection of keys is essential. The keys are the only things protecting the ciphers, the output of the encryption process.. If people put in the configuration files that are easily obtained when a web application is breached, the cryptography becomes useless.
Furthermore, many of the encryption algorithms we have been using in the past are being insufficient now. It is no good using encryption if the algorithm is easily broken and very often that’s done by doing things like compromising the keys.
So there are are some very important aspects of cryptography. If its implemented incorrectly, the sensitive data is readily exposed.
3. Other Exposure Risks
There are few other general risks which OWASP talks about. For example, browser auto-complete – if you have got auto-complete and I went in the browser for something like a credit card field, you run the risk of the browser remembering the credit card details. Someone else comes along to the PC and could use these details stored insecurely in the browser.
Disclosure via the URL – A lot of people pass sensitive data around in the URL. this is not really ideal, even when sent by the https. Because inevitably that URL poses its own risk. For example, one thing that people like to do is share URLs. you have a logged in use that decides to share a URL over social media without realizing that their credentials are stored in it. It sounds funny, but it happens! That is a serious risk.
We also see logs often exposed that contain sensitive data. For example, lets imagine you put sensitive data in the URL, its stored in the web server logs in plain text and the web server logs are exposed. That is one more example how sensitive data can be leaked.
Here is the list of few more reasons which could lead to exposure of sensitive data:
- Hardcoding data like tokens, secret keys, passwords in the source code.
- Logging sensitive data in server logs.
- Caching sensitive data.
- Transmitting sensitive information in plain text.
- Using old or weak cryptographic algorithms.
- Using default crypto keys, generating or re-using weak crypto keys.
- User-agent (e.g. app, API) not validating received server certificate which can result in a rogue server attempting to masquerade as a legit server.
Prevention Strategies
Let us now talk about few different common defenses against the risk of sensitive data exposure.
1. Minimize Sensitive Data Collection
This one is very obvious. If you dont have it, you cant lose it. For example, do you really need to store a person’s phone number? Do you really need to store things like birthdate or their gender? People get rather upset if this information gets exposed. If you dont have it it cant be xposed.
That may also mean – having it and then discarding it. So need to carefully decide what is the retention window for which that data is actually needed. If you need a piece of financial data to process a transaction, do you really still need it after the transaction? So think about what you can get rid of. Don’t store sensitive data unnecessarily.
2. Apply HTTPS Everywhere
This is a a big one because we get it wrong so often. It is lot more prevalent than what OWASP actually suggest. It is very easy to get it insufficiently implemented.
There are many examples where people are loading login form over HTTP or loading a page over HTTP and then putting an iframe in the page and loading a login form into that over HTTPS. But it is all sitting inside this great big insecure request which is the HTTP page.
If you can simply wrap HTTPS around the entire website, the insufficient component almost completely goes away. It certainly makes it much much easier. It also solves problems like mixed mode and exposure of cookies. So just try and start secure by default position, and make your life a lot easier.
3. Use Strong Crypto Storage
It is essential to get the algorithms designed to store passwords rightly implemented. Just a salted hash is not enough. Store passwords using strong, adaptive and salted hashing functions with a work factor (delay factor), such as:
These are designed specifically for protecting passwords. Also when we move into encryption and particularly when we talk about private keys, the storage of those is critical. Give careful consideration to key storage.
Ensure that all encryption algorithms are latest, and strong, and that the corresponding protocols and keys are in place. Keys should be stored safely.
OWASP Risk Rating
Let us look at the OWASP risk rating matrix –
Looking at the attack vector, exploitability is classified as difficult. This risk covers a number of different ways that an attacker might access sensitive data. For example mentoring traffic on network is little difficult than exploiting a SQL injection. In terms of security weaknesses, it is less common than the other risks and detectability has been classed as average.
Many of these things are very easy to discover, in fact they are very easy to publicly observe when you are using any website. Technical impact is severe, because if sensitive data is exposed that could lead to some very significant fallout.
Summary
Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, phone numbers, login credentials or any business critical information.
Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
It is important to identify what data collected are sensitive and classify them. This can depend on the type of application, privacy laws, regulatory requirements or business needs. Do not forget to apply fundamental defenses we talked here to prevent sensitive data exposure.
It is important to note sensitive data exposure risk move from sixth position in 2013 edition to position third in 2017 edition. Thank you for reading. Stay Safe, Stay Secure!
