I love Top 10s. They’re everywhere and about everything: Top 10 Fascinating Facts About Neanderthals, Top 10 Crazy Bridal Preparation Customs, Top 10 Alleged Battles Between Humans And Aliens, etc.
But my question was always: why 10? Why not 11? Or 9. Or whatever else? I guess 10 sounds more important than 11 or 9. It’s the decimal system, 10 fingers, easy to visualize. What would you trust more, a Top 11 or a Top 10? Then the pressure is on the top creator to add, eliminate or combine elements to end up with 10 for a credible list.
Let’s get back to our InfoSec sheep. I prefer simplification and that’s why I started a quest to see if I can end up with a shorter version of the OWASP Top 10.
"The OWASP Top Ten is a powerful awareness document for web application security [...] represents a broad consensus about what the most critical web application security flaws are. [...] Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code." [link]
The OWASP Top 10 is a versatile project and can be used in multiple ways. But as you work with it, you realize that it is a little bit bloated.
Let’s start with A1-Injection: "Injection flaws occur when an application sends untrusted data [...]" This to me sounds very similar to the definition of A3-Cross-Site Scripting (XSS): "XSS flaws occur whenever an application takes untrusted data and sends it [...]". But enough with definitions, rationalizing XSS is JavaScript injection. In my opinion, A1 and A3 are separated by the location of the untrusted data parser, server vs client side. But in terms of mitigation, they’re both addressed on the server side (if you’re security conscious), so why keep them separate, A1 + A3 = NEW1.
And while we’re at it, isn’t CSRF another form of injection? The attacker injects a command to be executed by the victim in a valid session.
OK, one more and I promise we’ll move on. Otherwise we might end up with Top 1 security vulnerabilities. A10-Unvalidated Redirects and Forwards. The attack mechanism is similar to XSS and CSRF, tricking the victim through phishing. What’s the injection here? Malicious URLs.
So…
A1 + A3 + A8 + A10 = NEW1 – Injections of all kinds
Moving on to other categories. Now, talking about A2-Broken Authentication and Session Management, isn’t authentication part of the bigger concept, authentication and authorization? If so, A4-Insecure Direct Object References deals with flawed authorization and would fall under the same umbrella.
But wait a minute, isn’t A7-Missing Function Level Access Control dealing with access control aka authorization? The definition says:
Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget.
Let’s leave the part that is managed via configuration out of the question for a second (it will be incorporated in the next category). The rest of the problem is at the code level generated by the developer who doesn’t introduce proper checks and thus allows a malicious user to execute functions without authorization.
We have our second category:
A2 + A4 + A7 = NEW2 – Flawed authentication and authorization
What’s left? Ah, yes, the all mighty configuration issues. Let’s start with A5-Security Misconfiguration. If I had a penny for each vulnerability I’ve seen which was classified as A5, I wouldn’t probably write this article. What I’ve noticed is the tendency that most pentesters have to drop vulnerabilities that they think can’t be classified otherwise in this category. Sometimes it’s because issues are complex and there’s no other category for them, other times it’s just easy to drop them somewhere and forget about it, even though the vulnerabilities can easily fit in one of the other 9.
About A6-Sensitive Data Exposure, this is mainly related to infrastructure configuration. The main point here is related to the protection of data in transit and at rest. While developers can introduce vulnerabilities by using weak (if at all) cryptographic functions, this can be enforced by other security controls and with proper management of the development life-cycle. The focus has been lately on using old or poorly configured SSL versions and not encrypting data at rest. To me, A6 is just a different set of configuration issues.
Last but not least, A9-Using Components with Known Vulnerabilities. This is a no brainer, if you configure your systems properly and have a good change management process, you would you introduce or continue using old components, right? Depending on weather this is an infrastructure problem or using old vulnerable libraries in the code, the responsibility can be shared between SecOps and DevOps.
Thus we have our bronze medalist:
A5 + A6 + A9 = NEW3 – Configuration Vulnerabilities
Without further ado, I give you my heavily revised and compressed OWASP Top 3 Web Application Vulnerabilities
- NEW1 – Injections of all kinds
- NEW2 – Flawed authentication and authorization
- NEW3 – Configuration Vulnerabilities
Is it usable? It depends. On a higher and less technical level it makes things easier to explain. It might be useful to map the identified vulnerabilities on this top in order to identify the developers security training needs.
If you managed to read this far, you should know that I use the OWASP Top 10 on a daily basis in more than one way, I find it very practical and I prefer it over other web vulnerability classifications like CWE/SANS Top 25 due to its simplicity. There are certain cases where others are better, it all depends on how you plan to use them and the maturity of the organization where you try to implement.