As part of a radical revamp of its Top 10 list, OWASP has created three new categories, which security teams need to consider when looking to protect against today’s most critical and serious application security risks.
What are these categories and why are they necessary to improve application security?
Insecure Design (A04:2021): Application Vulnerability Starts Here
Although this new category ranks fourth, it is by far the highest value item on the OWASP Top 10 list and will intersect with every other item on the list. It represents a bold move by OWASP and its members, who have traditionally focused more on application security post-production. OWASP suggests that if security is going to see significant improvement, we need to “expand left” not only in the coding of the application, but also in the planning and design phases. After all, a bad design cannot be fixed with a perfect implementation. Companies need to get smarter about building security into their applications sooner, which is a big change in the way the software industry has traditionally worked.
The obvious benefit of improving the design process is that it will minimize future problems in exactly the areas that are so problematic and higher on the list. This is not a small task, but a necessary one to improve application security.
Software and Data Integrity Flaws (A08:2021): Every Plugin, Library, Module, and Supply Chain Matters
Another critical new category on the list for 2021 is software and data integrity. Tangentially related to insecure design, the category highlights issues related to the use of code and infrastructure that do not sufficiently protect against integrity violations. For example, using compromised plugins, libraries, or modules from sources that have not been verified or verified. Think Log4j. This can leave a huge security hole despite all your other preventative measures.
OWASP data shows that this is a growing threat, likely due to the increased CI/CD approach to software development. While CI/CD is a great mechanism for accelerating the delivery of new software and services, the rush for speed often leads to unvalidated code or components, which can leave the door open for associated unauthorized access, code malicious or system compromise.
What can you do to mitigate this? First, make sure your software, including the libraries you use within it, comes from a trusted repository and is secure. The use of digital signatures can help, as can a review process to ensure that no malicious elements have been implanted in your code. Additionally, OWASP strongly recommends using a software supply chain security tool to check all of your software components for known vulnerabilities.
Server-Side Request Forgery (A10:2021): A Trojan Horse
Although not a new attack vector, server-side request forgery (SSRF) it is seen as a serious and worrying attack for security professionals. In fact, OWASP survey results reveal that it’s the number one fear among security professionals. SSRF is predicted to increase as modern web applications make more external data requests on behalf of users.
SSRF allows an attacker to send crafted requests from a vulnerable application’s back-end server. Although a resource may be protected from external access, the request appears to come from a trusted source, an internal server, and the data is freely delivered and transmitted to the attacker, leaving the organization open to many different types of attacks with devastating consequences. . .
When it comes to mitigation, an obvious first step is to minimize the type, scope, and number of requests an application can make. However, applications need to talk, so additional mitigation techniques are also required.
At the network layer:
- Use a firewalls to restrict host connections – Force deny by default
- Whitelisted Allowed Communications – Prevent all requests except essential ones
- Enable inter-host authentication: Consider making this standard practice for all internal host communications
- Log all flows to monitor and audit – understand which hosts need to communicate, why and when
In the application layer:
- Define and enforce strict URL communication protocols for your applications: URL scheme, ports, and ALLOWED destination lists
- Disable HTTP redirection to prevent whitelisting from being bypassed
- Sanitize and validate all input data on the client side: include it in the application or use a WAF
- Always validate that the answers comply with the expected structure and content before sending them to the client
In the next article in this series, we’ll look at some of the areas that have improved since 2017 (yes, there have been some!), along with the categories that urgently need to be addressed.