Dec 5, 2021
Changes in OWASP Top 10: 2017 vs 2021
In an age of cybercrime, hackers seek new ways to exploit the vulnerabilities of software systems every day. Denial-of-service attacks, broken access control and data breaches are normal and we as engineers must deal with them. To avoid these security problems, software development teams must be aware of software security. The OWASP Foundation created the OWASP Top 10. A list of the ten most critical security risks to modern web applications, sorted by their observed importance. They released an updated version, and this blog post will briefly explain what has changed since the last publication of the OWASP Top 10 in 2017.
This is the start of a longer series of blog posts, which deals with how to build a CI/CD Pipeline to scan for the OWASP Top 10 automatically. Several topics will be addressed in future blog posts e.g., which vulnerability scan types are available and which points can be tested automatically. We will also show you various tools and how you could build a CI/CD security pipeline with them.
But in this blog post let us look at the changes in the OWASP Top 10 since 2017.
We will only highlight new categories or categories that have changes in their definitions:
A03:2021-Injections
The first change relates to injections.
Injections are attacks in which an attacker attempts to send data to a web application to execute something that the web application was not actually designed to do.
These can be injection vulnerabilities such as SQL, OS or LDAP injections. The new OWASP Top 10 Update also contains the vulnerability A07:2017-Cross Site Scripting (XSS), because this vulnerability is in principle also an injection.
A04:2021-Insecure Design
A04:2021-Insecure Design is a new category in the OWASP Top 10 and directly started on place four. It covers architectural flaws and design mistakes that result in a missing or useless control design. While an insecure implementation could be easily fixed, fixing an insecure design is more complicated or even impossible.
One of the best-known examples for insecure design is “password recovery based on questions and answers” like “What is the name of your favorite pet?”. Many people know the name of someone else’s pet. Also, the name of someone's mother or favorite TV show is easy to guess. This is especially true in the times of social media, where you can find all this information online.
So even if you implement it perfectly, it is insecure.
You can’t fix this password recovery workflow by only changing the concrete implementation, even if you want to. Your only option is to completely replace it by something more secure.
But that’s not all. A04:2021-Insecure Design also covers error-prone Software Architecture, which lead developers into programming mistakes. Maybe no developer made a mistake yet, the architecture is still error prone. This case is also covered by this OWASP category.
An example of such an error-prone architecture aspect is “CWE-501: Trust Boundary Violation”. This CWE describes the anti-pattern of mixing trusted and untrusted data in your application. Normally you will trust the user information from your authentication system but not the user information transmitted in an HTTP-Request. The latter could be easily manipulated by an attacker and is, therefore, untrusted data. If you store both in the same object, a developer could easily mix things up. Then the manipulated data from the HTTP-Request is used and not the trusted data from the auth-system, which could end in a privilege escalation.
This new category is of massive importance. Many projects start without a real design phase and don’t have security in focus. Even prototypes and proof-of-concept implementations with completely different non-functional requirements for security and maintainability often go into production. Adding these things later is extremely complicated and needs a lot of expensive refactoring time. You can only prevent A04:2021-Insecure Design with a secure development lifecycle, good threat modeling, best practices, and thoughts during the design phase.
A05:2021-Security Misconfiguration
Modern software gets increasingly complex. We moved from simple systems with one webserver and one database to microservice architectures, where we have several services deployed on multiple servers. These are connected to the internet by clusters of reverse proxies and load-balancers. Everything is reusable and needs configuration to fit into different environments and applications. With the increasing amount of configuration options, it’s no wonder that this category moved up in the OWASP Top 10. But since 2021 it also includes A04: 2017-XML External Entities (XXE).
XXE is an attack against an application that processes XML input from a client. An XML-External-Entities-Attack occurs when untrusted XML input, containing references to external entities, is parsed and processed. For example, with XXE an attacker could include the content of the server /etc/passwd file or the content of your application.properties into the input XML. In most applications when a user has the permission to write information into a system, he is also allowed to read the information and could see the included server content containing information about system users or database passwords.
But this attack only works with a weakly or misconfigured XML parser. So A04: 2017-XML External Entities (XXE) is a special form of misconfiguration and is now included in A05:2021-Security Misconfiguration.
A08:2021-Software and Data Integrity Failures
Another newcomer is A08:2021-Software and Data Integrity Failures. These refer to code and infrastructure that are not protected against integrity violations.
This can occur when a web application relies on plugins, libraries, or modules from sources, repositories, and content delivery networks that are not trusted. Then a CI/CD pipeline, that does not validate external resources, can provide the potential for unauthorized access, malicious code, or system compromise.
Another example would be an update without signing. This is currently the case with many home routers, set-top boxes, device firmware and other devices because updates are not checked for a valid signature. If the device now performs an auto-update the attacker can upload, distribute, and execute his own update.
Also included in this category is the former vulnerability A08:2017-Insecure Deserialization. The vulnerability here is that a serialized object can be manipulated. If malicious code or data was introduced into the serialized data, it is later executed during the deserialization with the rights of the application. This can happen if the integrity check for deserialized data and objects is not hardened against attacks (assuming there is an integrity check at all).
A10:2021-Server-Side Request Forgery (SSRF)
Finally, the last change A10:2021-Server-Side Request Forgery (SSRF). An SSRF vulnerability can occur when an attacker has full or partial control over the requests that a web application sends. Therefore, a potential attacker could make the web application send manipulated requests to other destinations or its own resources, so everything the server has access to would be accessible. This would allow an attacker to gain access to information which is normally not accessible from the outside, because of a firewall, VPN or some kind of ACL. These security mechanisms would not work, as the server makes these requests on its behalf.
To provide more clarity, an example of a web application with three services is given, which have ACLs and authorization rules configured to establish trust between them:
In this example the service with sensitive data is protected and only accepts requests from the administration service and the user service.
For security reasons, even administrators cannot directly communicate with the sensitive data service. They can only view, edit, or delete the sensitive data through the administration service. In this case, the administration service sends a request to the server responsible for the sensitive data via APIs. The sensitive data server performs these actions and sends the result back to the administration service.
With SSRF, the protection offered by this separation is bypassed. This is done by getting the administration service or even the user service to execute a manipulated request on behalf of the attacker.
Let’s take a deeper look and assume that the administration service in our example provides an API to retrieve user profile images from other websites. It gets the URL of the profile image via a URL parameter. If this parameter is not carefully validated, the attacker can abuse it and is able to send GET requests to any website on the Internet. However, the attacker is also able to access the protected sensitive data service since it accepts requests from the administration service. Such a query string could look like the following:
GET /user-image?url=https://www.google.com HTTP/1.1
Host: example.comWith the increasing usage of microservice architectures, more web applications will use internal networks to protect their internal services and databases. This clear separation between public and internal brings security advantages. But with the increasing amount of services also the complexity of authorization and ACL handling increases.
SSRF is new in the OWASP Top 10, and it is currently only a small cluster of a single CWE. But with the increasing usage of microservice architectures, this attack will become more common, and we need to focus on it.
Conclusion
The changes in the OWASP Top 10 are quite interesting. The new category A04:2021-Insecure Design is a clear sign that we need to focus on security even in the design phase. The next thing is that microservices bring security advantages over monoliths. But A10:2021-Server-Side Request Forgery (SSRF) shows that they are not bulletproof, and they need more configuration (A05:2021-Security Misconfiguration).
If we look at the top positions, in 2017 Injection and Broken Authentication were the two most common. With the new OWASP Top 10, this has changed, and both moved down. Injections are now on position 3, and Broken Authentication lost five places and is now on position 7. The two most common OWASP Top 10 are now Broken Access Control and Cryptographic Failures.
There are a variety of reasons for this. On the one hand, the OWASP Top 10 focused on them. On the other hand, the tools to detect them are getting better and better. Overall, the list of CWEs that the OWASP Top 10 covers is long, and many things are too big for manual testing. To write secure software, we need automatization and proper tooling.
In our next OWASP blog posts, we will address this problem. We discuss how OWASP related problems could be detected by DAST, SAST and IAST scans in a CI/CD-Pipeline. So, stay tuned and Thanks for reading!
Special thanks also go to my colleague Michael Graf.
If you have any questions, suggestions, or criticism on this topic, please feel free to contact me.
You might be interested in the other posts published in the Digital Frontiers blog, announced on our Twitter account.
