As part of a sweeping 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 severe application security risks.
What are these categories and why are they necessary to enhance application security?
Insecure Design (A04:2021): Application Vulnerability Starts Here
Although this new category ranks fourth, it is, without doubt, the biggest-ticket item on the OWASP top 10 list and will cut across all other elements on the list. It represents a bold move by OWASP, and its members, who have traditionally put more focus on application security post-production. OWASP is suggesting that if security is to see major improvement, we need to “expand left” not just in application coding but also in the planning and design phases as well. After all, poor design cannot be fixed by a perfect implementation. Businesses need to get smarter about designing security into their applications earlier, which is a big change in how the software industry has traditionally worked.
The obvious benefit to improving the design process is that it will minimize issues down the road in exactly the areas that are so problematic and higher on the list. This is not a small undertaking but a necessary one to improve application security.
Software and Data Integrity Failures (A08:2021): Every Plugin, Library, Module and Supply Chain Matters
Another new critical category on the list for 2021 is software and data integrity. Tangentially related to insecure design, the category highlights the issues related to using 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 checked or verified. Think Log4j. This can leave a gaping security hole despite all your other preventative measures.
The OWASP data show this to be a growing threat, likely because of the increase in the CI/CD approach to software development. While CI/CD is a great mechanism to speed 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, malicious code or system compromise.
What can you do to mitigate this? First, ensure that your software – including the libraries you use within it – is from a trusted repository and is secure. The use of digital signatures can help, as can a review process to ensure that malicious elements have not been implanted in your code. Further, OWASP highly recommends using a software supply chain security tool to check all your components for known vulnerabilities.
Server-side Request Forgery (A10:2021): A Trojan horse
Although not a new attack vector, server-side request forgery (SSRF) is viewed as a serious and worrying attack for security professionals. In fact, OWASP survey results reveal it is the number one fear among security professionals. It is predicted that SSRF will increase as modern web applications make more calls for external data on behalf of users.
SSRF lets an attacker send crafted requests from the back-end server of a vulnerable application. Even though a resource may be protected from outside access, the request appears to come from a trusted source – an internal server – and the data is freely given and relayed to the attacker, leaving an organization open to many different kinds 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. Yet, applications need to talk, so additional mitigation techniques are also required.
At the network layer:
- Use a firewall to restrict host connections - Enforce deny by default
- Whitelist permitted communications - prevent all but essential requests
- Enable authentication between hosts - consider making this standard practice for all internal host communications
- Log all flows for monitoring and auditing - understand which hosts need to communicate, why and when
At the application layer:
- Define and enforce strict URL communications protocols for your applications – URL schema, ports and destination ALLOW lists
- Disable HTTP redirection to prevent whitelists from being bypassed
- Sanitise and validate all client-side input data – either include this in the application or use a WAF
- Always validate that responses meet the expected structure and content before sending them to the client
In the next article in this series, we will look at some of the areas that have improved since 2017 (yes, there have been some!), along with categories that need to be addressed urgently.
