Overcoming OWASP’s sensitive data exposure risk through application-layer data encryption

Image credit: Unsplash

Developers face a number of challenges and pressures when creating an application—most obviously, the need to meet release deadlines. When approaching a looming deadline, security is sometimes deprioritized, so the Open Web Application Security Project (OWASP) Top Ten list was created as an easy reference for developers to learn about major web application security issues and to use as a starting point when performing security assessments.

OWASP is one of the more well-known and highly regarded organizations in the cybersecurity space. This nonprofit is dedicated to improving the state of web application security by bringing attention to the most common and impactful security issues.

Their Top Ten list, which is updated every few years, highlights the most important types of vulnerabilities. The focus of this post is number three – sensitive data exposure – (which moved up from #6 from the 2017 list) and how poorly implemented cryptography is a common reason for exposure.

OWASP #3: Sensitive data exposure

Data breaches are a growing threat with new leaks occurring on near-daily basis. So, it should come as no surprise that the errors in web applications that facilitate these breaches made the OWASP’s Top Ten List.

As it relates to cryptography, four main reasons sensitive data becomes exposed by an application are: a failure to encrypt the data, poor key management, use of weak encryption algorithms and incorrect scope of encryption. And there is no shortage of real-world examples of companies that have made these mistakes:

• Failure to encrypt sensitive data: A classic example of this is the Marriott data breach discovered in 2018. The hotel chain reported that a cybercriminal managed to steal more than 5 million unencrypted passport numbers, forcing affected guests to replace their passports.
• Key management failures: In 2019, Imperva reported a data breach where a cybercriminal was able to access a copy of the company’s customer database that was stored on AWS with the help of an accidentally exposed API key. Among the leaked data was customers’ TLS encryption keys that could be used to decrypt the customers’ network traffic.
• Use of weak cryptography: In April 2020, Zoom made this mistake, using AES-128 in Electronic Code Book (ECB) mode to encrypt and decrypt audio and video. ECB mode is an insecure block cipher mode of operation that leaks sensitive information about the encrypted data.
• Incorrect scope of encryption: In the recent Capital One data breach, the organization’s entire AWS database was encrypted using a key that their web application firewall (WAF) unnecessarily had access to. The exploitation of a security misconfiguration in the WAF enabled an attacker to access all of the Bank’s data stored in that AWS instance.

These examples only scratch the surface. Any successful data breach is, by definition, a case where a company failed to properly use encryption.

The four most common encryption flaws

So, how does this happen? Encryption algorithms can be very sensitive, and a single, simple flaw can undermine the integrity of the system and destroy the encryption’s effectiveness. Here’s how four common encryption errors occur and can lead to the theft of sensitive data.

1. Lack of encryption

The simplest data encryption error is a failure to apply data encryption at all. Without encryption, any security hole that grants an attacker access to an organization’s system can also grant them access to the company’s sensitive data.

A failure to encrypt sensitive data seems like an unlikely scenario, but it is an extremely common error. In the cloud alone, 43% of databases are unencrypted.

A developer can make this mistake for a number of different reasons. Some common causes include:

• Not knowing the data is sensitive: If the developer isn’t aware of the sensitivity of certain data, he may not think to encrypt it.
• Lack of data flow visibility: A developer might also fail to encrypt data if he doesn’t know that sensitive data is stored or transmitted to an unencrypted location.
• Rushed deadlines and oversights: If a project has a tight development timeline, the data encryption functionality may be accidentally overlooked.

2. Poor key management

Encryption strategies also frequently fail thanks to poor key management. Rarely is a cipher or algorithm flawed and exploited. More often, it’s about an attacker’s access to the encryption key that would allow them to decrypt the data. Kerckhoffs’s Law states that an encryption algorithm is secure if everything except the secret key is publicly known.

Poor key management can take a number of different forms. Common examples include:

• Weak user passwords: If keys are managed for a user at the account level, a weak or compromised password could allow an attacker to gain access to sensitive data.
• Hardcoded keys: The easiest way to implement encryption functionality is to embed the secret key in the code as a variable. However, this makes the encryption algorithm vulnerable to reverse engineering.
• Storing keys alongside code: Often in cloud deployments, encryption keys are stored in a configuration file alongside the encrypted data, so they are easy to change. However, if an attacker has access to the cloud, they can easily swipe the keys and perform decryption offline. A number of Github leaks demonstrates that this is not a secure key management strategy either.

3. Use of weak cryptographic algorithms

Cryptography can be complicated. Most well-known encryption algorithms are secure, but not all are. Some algorithms have weaknesses that have made them unusable or require that they be used in a particular way, like RC4.

Some other well-known cryptographic algorithms, such as DES, SHA1 and MD5, are not secure because they are vulnerable to a brute-force search. Use of a weak cryptographic algorithm, such as a block cipher using Electronic Code Book (ECB) mode, destroys the protection of the data it is designed to secure.

Developers tend to use insecure cryptographic algorithms in the following scenarios:

• Library implementation: Cryptographic libraries may include implementations of insecure algorithms (such as ECB mode), making it easy to use them by mistake.
• Famous names: Some of the most well-known cryptographic algorithms (MD5, SHA1, RC4) are broken or very weak. However, developers may still use them due to name recognition or by pulling sample code from old Stack Overflow threads.

4. Incorrect scope of encryption

Finally, cryptographic algorithms can potentially expose sensitive data if they are applied in the wrong way. An otherwise secure and correctly implemented encryption algorithm may expose sensitive data because it is not being used for its intended purpose.

An example of this is disk-layer encryption, which is commonly used to protect data at rest. Disk-layer encryption is designed to protect against unauthorized users and does so by encrypting the entire drive with a key that’s protected by the user’s password.

Once a user has authenticated, any application run by the user can access the data stored on the drive. As a result, disk-layer security provides no protection against the exploitation of web application vulnerabilities.

Incorrectly scoped encryption typically occurs because of:

• Design oversights: In the planning stage, the different permissions, access levels and potential attack vectors within an application may not be fully explored. This could result in the use of “blanket encryption” when something more granular is needed.
• Ease of implementation: It’s easier to write a single encryption function than several. When writing the code, encrypting everything in the same way with the same key may make sense when under pressure to get an application out the door.

Application-layer encryption mitigates common sensitive data exposures

Sensitive data can be exposed for a variety of reasons, which is why it’s important for companies to implement a robust encryption solution to dramatically decrease their vulnerability to data leaks. (See diagram below).

Application-layer encryption performs data encryption at the application layer, making sensitive data decryptable only via the application that owns it. This enables it to solve many of the issues that lead to sensitive data exposure:

• Sensitive data is encrypted: Applications encrypt their own sensitive data, decreasing the probability that data will “fall through the cracks” with a more general solution.
• Keys are controlled by the application: With application-layer encryption, an application has complete control over its own encryption keys. This enables it to take advantage of secure storage solutions such as hardware security modules (HSMs).
• Strong, modern ciphers are used: A robust application-layer encryption solution should only offer strong encryption algorithms for use. This eliminates the chance that a developer will accidentally use an insecure algorithm.
• The “need-to-know” principle is enforced: With application-layer encryption, access to sensitive data is only possible via the application that owns it. This eliminates the scope issues associated with disk-layer encryption.

Moving toward OWASP compliance with application-layer security

The OWASP Top Ten is a common starting point for web application security testers and cybercriminals alike. An application secure against the attacks outlined in the list is well on its way to being secure—and ignored by cybercriminals looking for “low-hanging fruit.”

Protecting against exposure of sensitive data is one of the most challenging requirements of the OWASP Top Ten. A wide variety of issues can result in a security hole that an attacker can use to access and steal sensitive information. However, by adding a strong application-layer security solution, you can dramatically decrease your organization’s exposure to damaging data breaches.

To learn more about how to take advantage of application-layer encryption, drop us a line.