2017 OWASP Top 10 for PHP Developers Part 3: Sensitive Data Exposure

There is a lot of exposed data floating on the web. People hear about such events all the time – it seems like data breaches are becoming more and more common.

With data breaches being so prevalent, one would expect people should protect their data better. However, with many developers underestimating the importance of protecting private data, this isn’t always the case – when developers fail to adequately protect data, sensitive data exposure might occur.

Sensitive data exposure is currently ranked number three in the 2017 OWASP Top 10 vulnerabilities list – that makes it a pretty significant vulnerability, and that is what I am covering today.

What is it?

Sensitive data exposure is such a vulnerability that occurs when an application fails to protect sensitive information. Sensitive information can be either passwords, session tokens, credit cards or other data.

How prevalent is it?

Such a vulnerability is very, very prevalent. Every other day we see data leaks from all sorts of companies – be it small discussion forums or big social media websites. Noone is exempt from data breaches – that’s the harsh reality we have to deal with.

The impact of sensitive data exposure may vary depending on what data was exposed. For example, if the exposed data would contain only email addresses, the impact would not be very high.
On the other hand, if the exposed data also contained passwords, credit cards and other information, you’ve got yourself a way bigger problem.

How to protect against it?

There are a few ways developers can prevent sensitive data exposure. As usual, I will list some of them below, then talk about each of them.

To protect against sensitive data exposure, developers can (and should) ensure that the following steps are performed:

• All authentication pages should be served over SSL
• Sensitive data should only be stored when necessary
• Stored sensitive data should be adequately protected

Authentication pages should be served over SSL

Serving authentication pages over an unencrypted connection is bad – in order to maintain a secure connection between the website and the browser, HTTPS must be used.

Serving pages with password and / or credit card input fields over HTTP will produce this on Firefox:

Chrome on the other hand behaves like this:

Even though both Firefox and Google Chrome does give out security warnings when visiting an authentication form over HTTP, such occurrences are still very common:

Warnings are not the only thing you should be concerned about too: credentials transmitted over an unencrypted connection could be intercepted.

Sensitive data should only be stored when necessary

Sensitive data should only be stored when such actions are a necessity and it should be removed immediately when it’s no longer needed.
Storing unnecessary data can waste your money and disk space by the virtue of you backing it up and it also presents a security risk – the more data is stored, the more of it can be stolen.

Stored sensitive data should be adequately protected

At last but not least, if you do store sensitive data, protect it. By saying “protect it” I mean if you do store passwords, hash them.
If your organization handles credit card data, make sure your website complies with the Payment Card Industry Data Security Standard (PCI-DSS). And, if you do suffer a data breach, please let your website visitors know.

The recap

Though I did mention three very important security precautions that should be taken to ensure that the chances of sensitive data being exposed could be minified, the points I made are far from exhaustive – you could also implement a defense-in-depth mechanism meaning you could use a Web Application Firewall (WAF) to protect your website from threats and so on.