What’s New In The OWASP Top 10 And How TO Use It

As a student of web application security over the last decade, a constant touchstone has been all of the educational tools and projects available from the Open Web Application Security Project (OWASP). OWASP does a phenomenal job of publishing tools, promoting and funding projects, and fostering a community of students and professionals passionate about application security (AppSec). The most visible of these educational projects is the OWASP Top 10 Vulnerabilities.

The first edition of the OWASP Top 10 was published way back in 2004, and has been re-evaluated and re-published every 3 years since then. 2017 marks the fifth edition of the OWASP Top Ten project, and has become more than an educational and awareness-building tool over that time. In many organizations, the OWASP Top 10 is a guiding principal or even a standard. Virtually any application security technology (DAST, RASP, WAF, et al.) references mitigating the Top 10 vulnerabilities as a key benefit. The Top 10 is what many Qualified Security Assessors (QSAs) use when performing PCI compliance audits.

However, contrary to the increasingly prevalent usage of the OWASP Top 10, it is not a standard or a bar that every organization should use to measure their level of application security readiness or effectiveness. The OWASP Top 10 is still an educational tool, designed to help security professionals and developers alike figure out where to start in the application security practice. Many organizations will have a different “Top 10” based on their industry vertical, chosen application platform, software development life cycle (SDLC), and security self-assessments.

For example, Injection Flaws have been the number 1 vulnerability in the Top 10 in every edition except 2004. In 2004, Injection Flaws were number 6 while Unvalidated Input held the top spot. One could argue that unvalidated input underlies many application flaws including Injections, but I digress. Injection Flaws top the list not because they are the most prevalent type of flaw. In fact, most scans shared with me show injection flaws to be very rare. However, injection flaws, including SQL and command injection, have the greatest likelihood of enabling data loss or other critical compromise of systems in the application stack.

Your organization’s web applications may not show injection flaws in scans, and the underlying application frameworks are updated and lack known such flaws. Should Injection Flaws be your infosec and development teams’ top priority? As a result, the OWASP Top 10 is a starting point. Evaluate your own web application infrastructure’s vulnerabilities and threat model before blindly looking to “mitigate the OWASP Top 10” and then checking the AppSec to-do list off as “done”.

In the OWASP Top 10 2017 Release Candidate, there have been a few notable changes based on the evolutions and progress in web app security that have been made since the fourth edition was published in 2013.

• 2017-A4 Broken Access Control (New): This new item actually consolidates two items from the 2013 Top 10. Asserting and guarding the identity of users is among the best methods to provide robust application security. Reliable assertion of identity greatly reduces the risk of unauthorized – and potentially malicious – access to the web application.
• 2017-A7 Insufficient Attack Protection (New): This entry can be summarized by focusing on three areas: Detection, Response, Remediation. Better sensors and controls can detect unauthorized or otherwise malicious attempts to access the application or API. These controls include web application firewalls (WAF), intrusion prevention/detection systems (IPS/IDS), and application logic. Responding to attacks means better logging, alerting, and mitigation actions. Lastly, remediating the application or API to detect and block attacks must be part of both security practice and the SDLC.
• 2017-A10 Underprotected APIs (New): Application Programming Interfaces, or APIs, are often exposed with very little protection beyond a simple network firewall, with very little logic at the application layer. Since APIs are often subject to interacting with other machines, rather than humans with browsers, they can be vulnerable to denial-of-service (DoS) attacks due to insufficient application layer rate-limiting of requests, among other race conditions. APIs are often an afterthought, and lack the same input validation, detection of injection attacks, and other common attacks against browser-based web apps. Consider adding stronger authentication and access control to APIs, as well.
• 2013-A10 Unvalidated Redirects and Forwards (Dropped): The OWASP team found that after adding this category in 2010, the issue seemed to be less prevalent than initially thought. I have seen this issue become top of mind and receive a lot of attention due to the OWASP Top 10 inclusion, and the deployment of various fixes via application code and WAF policy. My take is the OWASP Top 10 did its job here, helping to eradicate a problem.

In conclusion, heed the warnings OWASP includes in the introduction to the Top 10:

• Don’t stop at the top 10.
• Applications and vulnerabilities constantly change.
• Go beyond vulnerabilities, and pursue positive security. The Application Security Verification Standard (ASVS) is available to help.
• Tools are good, but only as good as the human using them. Vulnerability scan results alone may not reveal the full impact of a vulnerability, without analysis by a skilled professional.
• Push to make security part of the organizational culture where you work. The infosec team alone can’t be responsible for application security. Developers need to be invested and management should be treating security as a priority in everything you do.