NOTE: Since this article, a new OWASP Top 10 has already been published in 2021. Moreover, the initial draft that this blog post discusses about, was modified quite a lot before final version.
OWASP published a draft of Top 10 Application Security Risks 2017. It has already caused a lot of controversy among web security folks. So here is my viewpoint.
New vulnerabilities
OWASP has introduced two new items in their new OWASP Top 10 list. These are “A7 - Insufficient Attack Protection” and “A10 - Unprotected APIs”.
A7 suggests that every web application should be able to “detect, respond and block attacks”. A10 basically says that there should be no vulnerabilities in APIs. I thought that A1 - A9 also cover APIs, but apparently it wasn’t that obvious since they needed an item on the list to hilight that.
The controversy
The greatest attention have been around the item A7. The main cause for the controversy is that the item have been lobbied to the list by an unnamed web security company (Contrast Security), which just happens to provide a product that resolves this issue. Article at http://www.skeletonscribe.net/2017/04/abusing-owasp.html by James Kettle describes the case comprehensively.
People have questioned the independency of OWASP. OWASP Top 10 is still a “de facto” standard of web application security. Companies around the world benchmark security of their web services against OWASP Top 10 (which may not always be the best approach). Being able to provide a solution to a OWASP Top 10 vulnerability - which suddenly pops up everywhere - is obviously a great business opportunity to Contrast Security and others that are on WAF business. Thus, in my opinion questions regarding the independency of OWASP are justified.
Lack of WAF, a vuln?
While the role of Contrast Security is controversial for sure, I also find it weird that “lack of firewall” should be classified a vulnerability at all.
OWASP Top 10 is supposed to be list of top security risks for web applications. In the best case, WAF is a risk mitigation technique that prevents exploitation of the vulnerabilities that should be fixed anyway. People should not rely on WAFs. These mechanisms provide defence-in-depth, they are not a solution.
Let’s consider a static web page with no dynamic content or any other server side processing but HTTP daemon handling the requests and responding with corresponding static HTML file. Only way to exploit the service is via vulnerability in the web server software (Apache / nginx etc.) or some other service running on the same host. In this scenario, value of deploying a WAF, is nonexistent. Quite opposite actually, WAF wouble be just another part of software to potentially fail, extending the attack surface.
By definition, a vulnerability is something you can exploit in order to compromise confidentiality, integrity or availability of the target. Lack of application-level firewall does not make any target exploitable - you also need real vulnerabilities. And those vulnerabilities should be fixed anyway. People shouldn’t just rely on WAFs and write shitty code.
Other notes about Top 10 RC1
A10 “Unprotected APIs”, while important, is also an interesting choice. Most points mentioned on the draft, are already covered in other items of the list. It is also undermined that security testing of APIs can be difficult, since they are meant to be used by machines, not by humans. I don’t agree with this claim. Pentesting APIs isn’t technically difficult. It’s just boring, and automating it may require some scripting.
Summary
Since OWASP Top 10 is often used as a benchmark or even requirement, defining “insufficient attack protection” a security risk is not logical. It depends on the context whether WAF or similar solutions actually improve the security. Protection mechaninsms do have their place, but it is not the list of Top 10 risks.
My intention is not to bash firewalls, WAFs, IPS or IDS systems or any other security mechanisms. I acknowledge their importance, and agree with OWASP in that proper security mechanisms would indeed improve the security of many services. However, as pointed out earlier, lack of WAF does not necessarily pose any security threat. In my opinion, OWASP’s statement that lack of WAF is a vulnerability or a security risk, is simply wrong. The root cause of the actual risk (vulnerability) is always somewhere else.