Sensitive Data Exposure or Information Disclosure is a vulnerability that allows an attacker to gather internal information such as software and versions in use, that will allow him to prepare a focused attack, commit identity theft and impersonate other users of a website.
Sensitive Data Exposure is labelled as A3 by the owasp top 10. This means it’s the 3rd most dangerous attack on web applications since 2017.
It is not a very “fancy” hackerman- esque attack, that the intruder has to perform in other to access this data.
Usually, the risk comes from applications already exposing something in the browser, HTTP header, or even in the URL.
Sometimes they’re encrypted and decrypted wrong or just stored in plaintext.
All Your Data Are Belong To Us
Such sensitive data could be Health information, banking information or used software and versions.
Let’s go through some examples:
Example #1: Version/ Software Disclosure
Usually, something like this occurs via the HTTP Header.
Most Servers are proud to announce what Web- Server, OS and even the version of them is running on them by default.
When given a version number, OS and software that is running, an attacker can tailor his attack, or just copy a CVE to exploit the web server.
Such exposure can be prevented by configuring the web server to not broadcast everything, or using a middleware to filter HTTP headers.
Example #2: Credit Card Information Leaking
Storing credit card information encrypted in a database seems like a good idea. Even if the attacker gains access to the database the information is not leaked.
But wait. What if the web app decrypts the information to display it to the user?
That’s a problem!
If an attacker is able to perform an SQL Injection and retrieve the data via the database, it will be decrypted. And thus leaked.
Usually, the website itself doesn’t need the data. Some back-end service will use it for billing.
So a good way to protect against such loss is asymmetric encryption:
The website encrypts the information with a public key of a backend server. The backend server will decrypt it with its private key.
To keep it convenient for the user, most pages display some digits of the credit card number. A separate field or table should store them. Possibly encrypted.
When leaked, credit card information can be abused by whoever wants to commit financial fraud.
Bonus Tip: If a website displays your full credit card info, how do you think it’s stored?
Example #3: No HTTPS on login pages
That’s a big NO. Nowadays you can get an SSL Certificate for free, so there’s no excuse for not using https at least on login pages.
I’m an advocate for https everything, even static websites. But especially for logins.
If your password is transmitted via a form, no matter if POST or GET and not encrypted via https, an attacker monitoring the network traffic could read and even store your credentials!
If your form submits via GET, then the password will be plaintext in the URL and can be seen if the user shares the website, screenshot or his/her history.
Sensitive Data Exposure can happen to the best of us. It’s important to be aware that we all make “rookie” moves once in a while.
I’m sure there are more examples and methods to abuse or cause this vulnerability like storing sensitive documents in the browsers localstorage, or similar.
When creating a web app, you should be cautious of what you share and what you hide.