OWASP Top 10 2017 — What should be there?
Having made my long term thoughts on the OWASP Top 10 process clear, I want to talk about the list as it stands at the moment and how I think it should be for 2017.
But first…
Before I start on that, I think it is important to acknowledge the enormous amount work which Jeff Williams, Dave Wichers and others have put into the OWASP Top 10. Their efforts have made it into the best known OWASP project and certainly the one thing that anyone in technology knows about Application Security. The current controversy and discussion has only arisen due to the project’s high profile and it is important to give credit to those who made that happen.
My background
I have a decade of IT Risk experience with the last few years mostly focussed on Application Security testing. In this time I have seen, tested and found vulnerabilities in web applications of many different sizes, types and technologies. At the same time I have also had experience explaining these vulnerabilities to client contacts and helping developers with practical mitigations. As such, whilst I cannot provide detailed statistics, I think I can provide a fair assessment of the key issues that web application developers are struggling with today.
More importantly, I work as a security consultant and have no actual or perceived allegience to any solution or service. My interest is that we have effective tools and materials to help clients better understand application security risk overall.
So what should the Top 10 look like?
I have seen at least one criticism of the OWASP Top 10 which states that most of the categories should no longer be relevant. Unfortunately, recent experience has shown that many companies are still struggling with the basics and therefore many of the existing categories which have stayed in the OWASP Top 10 should remain. Here are my thoughts about the changes.
The Good: Removal of 2013 A10 — Unvalidated Redirects and Forwards
A good change in my opinion. This is clearly still a risk but is probably not serious enough to be in the Top 10. I had a call with a client not long ago where I was trying to mentally run through the Top 10 to guide the conversation and this one didn’t come to mind at all.
The Good con’t: 2017 A4 — Broken Access Control
This is a great change that makes explaining the list a lot easier. 2013 A4 and 2013 A7 were just too similar for such a short list and it made explaining things difficult.
The Bad(ish): 2017 A10 — Underprotected APIs
I can appreciate that this is a big enough issue that merits its own item even though fundamentally the security risks of APIs will include many of the other items in the Top 10.
Currently the text of 2017 A10 just talks about standard vulnerabilities that can affect all application types. I think that maybe this item should be a little more focussed on issues which are more specific to APIs or “AJAX” style applications which use APIs for populating their web pages.
For example, it should specifically talk about Mass Assignment style vulnerabilities where the API framework blindly accepts parameters and updates the database without checking them against a whitelist or the opposite issue where it provides too many data items in a response, e.g. the password field from the database.
It should also highlight the perils of mis-configuring Cross Origin Resource Sharing headers which can effectively disable the same origin policy. Maybe also risks of JSONP.
I would rename it to simply “API Vulnerabilities”
The Ugly: 2017 A7 — Insufficient Attack Protection
Lets set aside the independence issues that I have previously discussed.
I have spent a long time wrestling with defining IT Risk and IT Security Risk and one of the key principles I have found is that a risk cannot just be the absence of a control.
This new item is describing the absence of a controls in an application. Other items in the list describe broken controls but this is the only one which actually talks about the absence of a new set of controls.
I 100% agree that the future of application security is applications which can better protect themselves. Clearly this is a widely-held view which is why OWASP already has OWASP Top 10 Proactive Controls which has “Implement Logging and Intrusion Detection” control as its #8. This seems like the correct place for explaining what attack protection measures should be implemented.
I therefore think that this item should not appear in the list at all but rather the “Implement Logging and Intrusion Detection” control should be enhanced with the content leaving the Top 10 Risks containing only actual risks.
One spot left
So I have one spot currently untaken on the Top 10, what will I choose?
Ironically, I agree with one of Contrast Security’s suggestions. Deserialisation Vulnerabilities should have their own spot on the Top 10.
I have the following reasons for this:
- These issues have been around for a long time and have never received enough attention. They only really came to light in 2015 and are still poorly understood.
- I think one of the reasons for this is that they are hard to understand and hard to casually exploit, especially within the confined time-frame of security testing.
- They clearly affect a number of heavily used languages.
- The severity is often critical leading to full Remote Code Execution on the web server, usually from the external Internet.
- There are plenty of off-the-shelf products which are vulnerable to this. Some of them have been patched to fix it, the older ones have not.
- Fixing the issue is not always straightforward or trivial.
In conclusion
I have already said previously that I think the OWASP Top 10 risks concept needs revamping and I stand by that.
However, in the short term, I think that the keeping the focus on actual security risks, especially those which are poorly understood will add the most value to the OWASP Top 10 2017. The Top 10 is a key tool for helping companies to understand and focus their application security efforts but this will only remain the case if the list remains internally consistent and relevant.