OWASP’s #3 Web Application Risk – the Threat of and Solution to Sensitive Data Exposure

Thursday, June 28, 2018 By

Sensitive data exposure is #3 in the current OWASP top Ten Most Critical Web Application Security Risks.

In business terms, it is a single risk that can cascade into a huge financial cost to the company; comprising the cost of security remediation, the cost of victim notification and support, the cost of regulatory fines (potentially from more than one regulator), the cost of legal actions against the company, and the cost of reputational damage to the company.

OWASP’s #3 Web Application Risk – the Threat of and Solution to Sensitive Data Exposure

In technical terms, sensitive data is at risk of being exposed through multiple other IT risks and IT vulnerabilities – including OWASP #1 and OWASP #2 already covered in this series. But despite the vulnerabilities preceding data theft and the subsequent costs following data theft, there is fundamentally just one risk: the actual exposure of that data. If data is kept safe, the IT vulnerabilities count for very little, and the subsequent costs go away almost entirely.

A classic example is the Equifax breach of 2017, where the exposed sensitive data of more than 145 million Americans was stolen. Exploiting a known vulnerability in the Apache Struts Web Framework, attackers gained access to and stole a vast amount of sensitive customer information. The definitive list of what was stolen can be found in the Equifax statement to the U.S. Securities and Exchange Commission.

As of March 2018, the cost to Equifax for allowing such a breach was estimated at $439 million, but this does not include all the regulatory and consumer rights cases still pending against the company. Furthermore, if the breach had occurred this year after May 25, the company would have been liable to General Data Protection Regulation sanctions because of the approximately 100,000 UK citizens affected.

The point of OWASP #3 is not the vulnerability or vulnerabilities that led to the breach, nor even the theft of the data – the risk comes from the Equifax exposure of sensitive data.

Avoiding exposure

The basic method to avoid the risk of sensitive data exposure is to encrypt the data. There are other techniques including anonymization and pseudonymization – but we’ll limit this discussion to encryption. The repercussions on Equifax come not from the breach nor even the theft of the data – but because sensitive personal information was unencrypted and therefore exposed to the thieves.

Encryption is not simple. Firstly, there are two common states for data: at rest (ie, in storage); and in transit (ie, being sent from one location to another). Each requires a different type of encryption. Secondly, there are two types of encryption: standard encryption for large scale data; and hashing algorithms (not strictly encryption because a hashed value cannot be decrypted) used for storing user passwords. Thirdly, not all cryptography is equal – there are old weak algorithms, broken algorithms, and misconfigured algorithms. All current cryptography can ultimately be broken by brute force given enough time and computing power – and if there is a flaw in the design of the algorithm, it can be broken in a meaningful period of time.

Data at rest

Sensitive data at rest includes stored password databases, sensitive user information necessary for the application, and sensitive intellectual property belonging to the company (for our purposes the latter two can be treated similarly).

If the former is not adequately hashed, and the latter is not adequately encrypted, it falls under the OWASP #3 risk of sensitive data exposure. Any successful hacker can steal the data and make use of it.

It is particularly important that password databases use a modern, slow, hashing algorithm with random added salt – and even multiple hashing operations – because of the susceptibility of stolen hashed passwords to being cracked by rainbow tables.

The choice of an encryption algorithm for other data at rest is equally important. Common advice is to eschew proprietary encryption – always use one of the mainstream algorithms that is openly available, is peer-reviewed, and has been tested by time.

But as important as the algorithm is its configuration, its implementation, and the business processes around it. Good encryption cannot be broken. Instead, hackers will often attempt to use the business processes. For example, bank card numbers may be stored encrypted, but need to be decrypted for use. It is at this point that malware will attempt to scrape the data and send it to the hacker.

Data in transit

The simplest example of data in transit that needs to be encrypted is the bank details or card numbers used to purchase goods over the internet. If this data is not encrypted, any attacker able to stage a man-in-the-middle attack will have access to the sensitive data.

The usual solution is to transmit the data using the SSL or TLS protocols (HTTPS rather than unencrypted HTTP). These generally use RSA or ECC algorithms, and are today unbreakable – but not everyone uses them.

In March of this year it became clear that the Emirates airline shared customer data with analytics companies using the HTTP protocol, rather than the more secure HTTPS. High Tech Bridge's Ilia Kolochenko commented at the time, “Sending sensitive information over unencrypted HTTP protocol is at least negligent and can put customers at risk. Interception of the HTTP data usually requires additional conditions, such as attacker’s access to the wireless networks of a victim... nonetheless, these risks are material: some cybercrime gangs compromise and backdoor public wi-fi routers to intercept plaintext passwords and other sensitive data.”

High-Tech Bridge’s ImmuniWeb SSLScan service can be used to remotely assess SSL/TLS configuration, and check its compliance with PCI DSS requirements, HIPAA guidance and NIST guidelines.

Since HTTPS encryption is currently thought to be unbreakable, hackers again attack the processes; that is, by attempting to steal data while it is exposed before transit and after it is decrypted after transit.

Summary and solutions

Preventing the exposure of sensitive data is difficult and complex – and isn’t just a case of encrypting all data. Firstly, you must know what data needs to by encrypted, and then you need to know where it is. Data classification can help with the former; but without expensive data monitoring software it is tedious and prone to error. And few companies in these days of agile cloud and mobile computing can honestly claim to know where all their sensitive data is located.

Once the data to be encrypted is known, effective encryption should be employed. But the business processes around sensitive data also need to be secure. If encrypted data is automatically decrypted by an application that needs to use the data, then concern over the application needs to be taken.

Quite simply, preventing the exposure of sensitive data is so difficult that many companies do not give it sufficient regard – preferring instead to protect the infrastructure rather than the data. History shows this is the wrong approach.

And finally, a note for the future… The best cryptographic algorithms are uncrackable today. That will not last. Probably within the next decade a new generation of quantum computers will become commercially available. These computers will have the power to brute force much existing encryption in hours rather than the thousands of years currently required. Certainly, the current encryption used for data in transit will fall.

At the same time, a quantum process known as quantum key distribution (already becoming available and currently used in Swiss elections) will apply the physical rules of quantum mechanics to secure data in transit. At some point soon, the current weakest area of data in transit will become the most secure part of preventing the exposure of sensitive data.

Actionable introduction and analysis of web and mobile application security, DevSecOps and Machine Learning for AST.

User Comments
Add Comment

High-Tech Bridge on Facebook High-Tech Bridge on Twitter High-Tech Bridge on LinkedIn High-Tech Bridge RSS Feeds Send by Email