The OWASP Top 10: 2021 in the front lines
By: Harold Rodriguez
The OWASP Top 10:2021 was officially released on September 24, 2021. This update sees new categories being added to the list, as well as other categories shifting in position, or getting merged into other categories. It aims to focus on identifying the root cause of a vulnerability, to provide better identification and remediation.
The OWASP website does a fantastic job of documenting the changes. To summarize:
- Injection, which used to be the #1 ranking, dropped to #3.
- Sensitive Data Exposure was renamed to Cryptographic Failures and moved from rank #3 to #2.
- Broken Authentication, which was previously ranked #2, is now #1.
- Cross-Site Scripting has been merged into Injection.
- Insecure Deserialization has been merged into Software and Data Integrity Failures.
- Using Components with Known Vulnerabilities has been renamed to Vulnerable and Outdated Components, and has moved from rank #9 to #6.
- Insufficient Logging & Monitoring has been renamed to Security Logging and Monitoring Failures, and has moved from rank #10 to #9.
- New categories A04:2021 Insecure Design, A08:2021 Software and Data Integrity Failures, and A10:2021 Server-Side Request Forgery were added.
At Cycura, our cybersecurity researchers are heavily engaged in vulnerability assessments and penetration testing against various kinds of web applications and technologies within different industries.
So how well do these updates in the OWASP Top 10 reflect what we’re seeing in the field?
The Top Three
Let’s start with A01:2021 Broken Access Control and A03:2021 Injection. Broken Access Control is at the #1 spot, knocking Injection down to #3. Injection was at the #1 spot for OWASP Top 10:2010, 2013, and 2017. This change in ranking makes sense from what we’re seeing in our engagements. Injection vulnerabilities have taken a backseat—not because they no longer exist, but because better controls are in place to mitigate and reduce the impact of exploitation. When these controls are missing, however, injection vulnerabilities continue to be devastating—often resulting in account takeover or remote code execution.
On the other hand, we’re seeing an alarmingly large number of instances where we’ve been able to access customer or employee Personally Identifiable Information (PII), and patient Protected Health Information (PHI) in our engagements. In many cases, exploiting these vulnerabilities have been trivial—such as changing a value in a HTTP POST request to “true”, force browsing to a page only available to administrators, or discovering SQL backups in a server with directory listing enabled. The theft and release of this data would be extremely damaging to the organization and the people associated with the data. For the people affected, the data could be used in identity theft and phishing attacks.
At the #2 spot is A02:2021 Cryptographic Failures. Previously referred to as A03:2017 Sensitive Data Exposure, it has been renamed to focus on failures in implementing cryptography. It’s uncommon these days to encounter a website that doesn’t use TLS, or an application that doesn’t hash user credentials in the database.
What we are seeing, however, are applications using deprecated hashing algorithms such as SHA-1—and in some cases, not using a random salt in the hashing process. We’ve also had success in discovering secrets in application source code repositories. These may have been accidentally checked in early in the application’s development and later deleted, but the developers neglected to change the secret. These have allowed us to access administrator features in web applications and decrypt data and credentials.
The New Categories
At #4 is A04:2021 Insecure Design, a new category that calls for integrating security into the development life cycle. This includes threat modeling, utilizing secure design patterns, secure code reviews, and penetration tests to identify and remediate issues at every step of the development workflow.
We’ve encountered business logic errors in custom-built shopping carts that allow us to purchase products for free, or at a heavily discounted price. We’ve even seen password reset functionality that generates guessable 4-digit passwords, or brute-forceable two-factor authentication codes. In other cases, we’ve been able to abuse an application’s trust boundary where it validates user-submitted data when sent through the web application, but trusts it without validation when sent directly via an API.
Many of these issues could have been detected and remediated early on. Depending on the vulnerability, fixing it may be trivial, or may require a costly redesign of the affected component. If the component is a critical piece of the application, the organization may be forced to shut the entire application down for a period of time until it can be properly fixed.
A08:2021 Software and Data Integrity Failures at #8 highlights the dangers in trusting software updates and changes in the CI/CD pipeline without verifying its integrity. Threat actors have started showing an interest in compromising CI/CD pipelines and code repositories to poison applications with malware. The Solar Winds, Codecov, and Kaseya incidents are prime examples of the rise in supply-chain attacks.
In our engagements, we’ve gained write access to code repositories hosting source code for mobile applications, and repositories hosting applications used in the imaging process of employee computers. Adding malware into the code or applications can go unnoticed if no integrity checking is in place to detect tampering.
The third new category is A10:2021 Server-Side Request Forgery (SSRF). Applications that are designed to fetch URLs may be abused into fetching local files, or resources from attacker-controlled servers. While not something we encounter often, most cases where we’ve exploited SSRF have been through applications hosted on cloud services. Cloud services typically have metadata storage at http://169.254.169.254, which can contain valuable information that may assist a threat actor in their attacks. We should expect to see a rise in SSRF vulnerabilities as more applications migrate to cloud services, and the potential for this category to go up in rank.
The Contenders
A06:2021 Vulnerable and Outdated Components is a category that rose significantly in rank. This was previously A09:2017 Using Components with Known Vulnerabilities. Without a software Bill of Materials (SBOM), it can be challenging to keep track of what dependencies an application uses, and whether those dependencies have any known vulnerabilities. A great example of this is Log4Shell (CVE-2021-44228), which led organizations to scramble and determine whether their applications, or their application’s dependencies using Log4j, were vulnerable.
The majority of outdated components we encounter are applications or devices in an organization’s Intranet that aren’t accessible from the Internet. In some cases, these applications or devices are no longer being maintained, and any vulnerabilities that are published remain exploitable until the applications or devices are replaced.
On the other hand, A07:2021 Identification and Authentication Failures fell significantly in rank. This was previously A02:2017 Broken Authentication. In our experience, this continues to be an ongoing issue, and perhaps the drop in rank is simply because other vulnerabilities are more prevalent. We’ve had varying degrees of success attacking authentication flows, particularly when no mitigating controls are in place to slow down or halt automated attacks. Credential stuffing and password spraying attacks are often an easy way to gain access to an application or system when password policies are non-existent, or not enforced.
A05:2021 Security Misconfiguration rose to #5 from #6. OWASP attributes its rise to organizations shifting into more configurable software and technologies. In some cases, these are deployed without security features being enabled. We’ve seen this in the form of S3 buckets containing configuration files with hardcoded passwords, applications using default credentials, and applications running with debugging enabled. Like A06, most security misconfigurations we’ve found tend to be more prevalent in applications and devices that aren’t exposed to the Internet but are accessible to employees or applications within the organization’s Intranet (for instance, web application management dashboards for IoT devices, IP cameras, printers, routers, and SMB shares).
Finally, A09:2021 Security Logging and Monitoring Failures shifted up a rank. This was previously A10:2017 Insufficient Logging & Monitoring. We don’t usually have visibility into what kind of logging and monitoring systems an organization has in play during a web application engagement. Often, we’re only made aware of it when the organization notifies us that we’ve triggered an alert with our payloads. Otherwise, we can assume that either no alerts were triggered, or no one has acted upon the alerts.
Our Final Thoughts
The updated OWASP Top 10:2021 list seems to closely reflect what we’re seeing in our engagements, particularly with the top three categories. While other categories have shifted around in position, the most notable changes are the new categories that directly address recent high-profile attacks and the need to integrate security early into the development life cycle. We would encourage organizations to take steps in assessing the vulnerabilities described within the OWASP Top 10:2021, in order to harden their applications and reduce the risk of compromise.