The OWASP Top 10–2017: What works and what doesn’t…
Its finally here! :) After several arguments, debates, fanfare and some fury, the OWASP Top 10 2017 is finally making its way to a PDF near…
Its finally here! :) After several arguments, debates, fanfare and some fury, the OWASP Top 10 2017 is finally making its way to a PDF near you on November 20 2017. If you are in InfoSec, AppSec or in Security in general, the OWASP Top 10 is very important to you. Like it or not, its the basis of several enterprise security decisions, compliance considerations, application security tools and practices the world over. Revered or reviled, the Top 10 has been an immensely influential document for Application Security, the world over.
I would like to congratulate Andrew van der Stock and the rest of the OWASP Team that has been working on the Top 10 2017. Creating and re-creating this document has not been easy, especially with all the controversies it was recently mired in. I tip my hat to all of you.
Before I go any further, I would like to clarify my view of the OWASP Top 10. A lot of folks make statements like “Top 10? Surely thats a joke. Because there are wayyyy more than 10 vulnerabilities in Application Security” or “Top 10? Its a recipe for Application Security teams to get lazy and focus only on some flaws, while attackers make hay with the thousands of others that lie unidentified”. I find this viewpoint a little myopic for several reasons.
For me, the OWASP Top 10 is an easy way of classifying and categorizing the most common attacks that affect applications at any given point in time. I believe that, the Top 10 has successfully been able to encapsulate most of what we see out there in terms of breaches, pentest results (personal experience, and not industry statistics and reports) and security problems that clients often have to deal with. So, when I see an OWASP Top 10 entry called “Injection”, I see this as any application vulnerability where crafted, malicious, user input intermingles with a datasource/runtime component, causing Remote Code Execution, that could result in breach of confidentiality, integrity or availability depending on the intent and attack vector utilized. So, just as I see “SQL Injection”, I also see “Server-Side Template Injection”, “LDAP Injection”, “XPath Injection”, and “Command Injection”. With more expansive Top 10 entries like “Broken Authentication”, one would categorize a large number of authentication, session and token based attacks as attacks that leverage “Broken Authentication”
So, with that out of the way…. Onto our main course; The OWASP Top 10 2017.
These are the changes from the previous, OWASP Top 10 2013 and today’s “Golden Master” version of the OWASP Top 10 2017
Let’s start with….
“What’s good with the OWASP Top 10 2017”
The OWASP Top 10 2017 is actually quite a solid list. Noticeably, there have been some key changes between the 2013 Top 10 and the 2017 Top 10. IMHO, it captures most of what we are seeing today, but I see some items that are missing here. But more on that later. These are the things I specifically like:
Merging the Access Control Flaws: I feel that this is a good move by the creators of the OWASP Top 10. The two categories of flaws “Insecure Direct Object References” and the “Missing Functional Level Access Control” flaws have been merged into a single category “Broken Access Control”. This makes sense because both these flaws typically relate to Authorization Flaws in most manifestations. And merging Authentication flaws, would dilute the prominence that should be given to Authorization flaws. With the rise of Web Services, Micro-services and Functions as a Service, Authorization Flaws are very prevalent and very pernicious. In fact, in most of the penetration-tests, application assessments that my team is involved in, we see a large number of Direct Object Reference and other Authorization flaws
Insecure Deserialization: Deserialization flaws really came to the fore with several Java libraries, especially the more famous (or infamous) Apache Struts2 being vulnerable to deserialization flaws. However, even beyond Java, deserialization flaws can be deadly with Python’s `pickle` and `cPickle` components, or PHP or Ruby (see YAML deserialization flaw) or ASP.NET even. In addition, Developers also incorrectly assume that use of YAML or JSON (especially JSON) renders them free of deserialization flaws. However, earlier this year we saw real examples of JSON Deserialization Attacks against several Java and .NET JSON parsers (Friday the 13th JSON Attacks). The recent Remote Code Execution with HTTP Param Pollution payload on CouchDB was also an attack that demonstrates the falliability of JSON parsers with reference to deserialization flaws (CouchDB RCE Flaw). With JSON, YAML, Protocol Buffers/gRPC implementations rising the world over, deserialization flaws seem to be here to stay.
Insufficient Logging and Monitoring: For those who have been following the OWASP Top 10. This one definitely seems like the “odd-one-out”. Most of the other flaws are application specific flaws, that people would have a natural tend to “prevent”, rather than focus on the other types of controls. However, with this entry into the Top 10, I feel there is a greater focus on the “Detect” aspect of security controls. Logging practices in most engineering teams is abominable from a security perspective. Several teams really fly blind when it comes to ongoing attacks against their application and end up cleaning up a massive mess that is identified, usually, months after the initial incursion. In fact, even during my trainings on AppSec, I have specific section dedicated to Logging practices for this very reason. Logging is a very important detective control and it needs a lot more respect from both the Engineering and the Security Communities.
The other aspect of “Insufficient Logging and Monitoring” that I liked is that there is a clear indication and preference towards detecting issues earlier in the SDLC, rather than after the application is deployed in production. With DevOps becoming a more concrete reality for rapid-release applications, Continuous Application Security testing with DevSecOps is a very important consideration.
Now that I have covered everything that I specifically liked. Let’s talk about some of the things that I didn’t. Namely….
No SSRF: Server-Side Request Forgery is becoming a powerful attack vector. In fact, in some ways, I see it as a natural extension to “Unvalidated Requests and Forwards”. In an SSRF attack, the attacker is able to manipulate a poorly validated/configured URL parser to give the attacker access to internal network components including ElasticSearch DBs, Redis DBs, Memcached Caches and other services. In fact, earlier this year at DEFCON, it was quite eye-opening to see Orange Tsai’s research on SSRF against popular parsers and implementations that could lead to Remote Code Execution and unauthorized access to several internal components behind the firewall (Presentation). I feel that SSRF will be a more pernicious attack vector in days to come 1. Because several protocols rely on HTTP (Redis, MongoDB, ElasticSearch, CouchDB) which makes these exploits lethal and 2. Developers really need to be trained extensively on preventing SSRF in their applications, which also plays into the ways that parsers handle code. In addition, previously dormant attack vectors like HTTP CRLF Injection can be used extensively to perform SSRF attacks.
Honestly, that’s the only beef I have with the Top 10 2017. I largely agree with the list, with this notable exception. Let me reiterate that I have immense respect and regard for the organizations and individuals that contributed to the Top 10.