New OWASP Top 10 List Places Focus on Cryptographic Failures
Writer’s comment: This blog is the first in a multi-part series where we’ll dig into OWASP’s A02:2021 – Cryptographic Failures vulnerability, various prevention measures, and most of the 29 associated CWEs.
The OWASP Top 10 List is an invaluable resource for web developers, providing insight into the most common and dangerous vulnerabilities found in production web applications. The list is updated about every three years, and the latest update was released in late 2021. The release featured a number of significant changes, as summarized in the graphic below.
A Focus on Cryptography
In the previous version of the OWASP list, Sensitive Data Exposure was number three on the list. However, in the update, OWASP acknowledged that this was a symptom rather than the actual root cause of vulnerability itself, and accurately updated its name to A02:2021 – Cryptographic Failures.
In addition to the name change, Cryptographic Failures moved up to second place on the list, behind only A01:2021 – Broken Access Control. With this change, the focus is on the misuse, abuse, or lack of cryptography in web applications that make these data leaks possible.
Additionally, both Broken Access Control and Cryptographic Failures rising to the top are in line with many of the recent security reports produced by vendors such as CrowdStrike and Palo Alto Unit42, as the top methods used by attackers to gain access to environments and either ransom or steal data.
Encrypting Data At Rest and In Transit
When describing the Cryptographic Failures vulnerability, OWASP highlights the fact that encryption should be applied to data both at rest and in transit. Additionally, the encryption algorithms used should be tailored specifically to the potential attack scenarios that they are attempting to prevent. In other words, they should be considered in close alignment with an organization or application’s threat model in mind. For more info on threat modeling, check out OWASP Threat Modeling community page.
Many web applications have strong encryption of data in transit because of the availability and ease of use of the Transport Layer Security (TLS) protocol. Setting up a secure TLS connection is relatively easy in many languages, and a properly configured TLS connection provides robust protection of data in transit. As such, most consider encryption in transit a mostly solved problem.
However, the same cannot be said about data at rest encryption. For many organizations, protecting data at rest is a much harder challenge and its failures generally result in devastating data breaches and loss. While encryption solutions exist for data at rest, the majority that are in use weren’t designed – and aren’t effective against – the modern threats organizations face.
For example, full-disk encryption is a common – but mostly ineffective – solution for securing data at rest. Let’s explore this in a bit more detail using a database example.
Say an organization stores sensitive application data in Amazon RDS. As a standard security measure, they enable encryption on creation, which encrypts all of the data at rest. The beauty of this approach is that it’s easy and the database isn’t aware (and doesn’t even need to be) that the data is encrypted.
Data safe, right? Well, not so fast. This approach protects data from physical theft, but doesn’t protect against an attacker who successfully connects to the database using stolen authorized admin credentials or by exploiting an application vulnerability. Once connected, the database automatically decrypts the data for the attacker, because it can’t tell between the authorized user or someone who stole the authorized user’s credentials.
To mitigate this huge gap, it’s strongly recommended to encrypt data directly within an application, before it leaves the application and is sent to the database, which is known as application-layer encryption. The combination of storage-level encryption and application-layer encryption significantly improves an organization’s security posture and their ability to mitigate the risk of data theft during a breach.
However, before embarking down the path of implementing application-layer encryption, one of the first critical steps is ensuring that the algorithms, protocols, and key management practices being considered align against the anticipated threats of the organization and system (your threat model). And, mostly importantly, implemented by experienced cryptographers.
Exploring Common Cryptographic Weaknesses
Even a properly-designed encryption system can be vulnerable to attack if implemented improperly. Cryptographic algorithms are powerful, but also fragile where a single small mistake can undermine the security of the whole system.
The wide variety of ways in which cryptography can go wrong is underscored by the list of Common Weakness Enumeration (CWE) entries mapped to the Cryptographic Failures vulnerability in the OWASP Top Ten List. The Cryptographic Failures vulnerability has 29 CWEs associated with it.
To help build understanding of how cryptography can go wrong and how to fix it, we’ll dive deep into prevention measures and each of the 29 CWEs in a series of blogs. Each blog will describe the vulnerability, why it happens, a real-world case study, and recommended mitigations. To keep up with this series and our other research and cryptography content, make sure to subscribe to our blog below.