The OWASP Top Ten 2017 Release Candidate 2 is out (bringing in a new approach)
A couple of days ago the Open Web Application Security Project published the Release Candidate 2 of the OWASP Top 10 2017 with a significantly new approach in the enumeration of security issues. Let’s take a closer look at the changes – both in the methodology and the list itself – as well as the implications.
About OWASP
In the last decade OWASP (founded in 2001) became a de facto reference point for Web application security – not just among application security engineers, but also on the management level. Its membership spans a wide variety of internationally recognized security experts to share their knowledge of threats, vulnerabilities, attacks and countermeasures. OWASP also operates a knowledge base accumulating documentation, articles, methodologies and tools that connect and integrate software development with information security – giving organizations a hand in security issues and best practices.
The Top Ten Project is the best-known publication of OWASP, enumerating the 10 most critical Web application security problems to be addressed. The list is updated every three years or so – the last list was published in 2013. In addition to just naming the issues themselves, it also gives examples of the vulnerabilities in practice, as well as attack scenarios and best practices about how to avoid them, along with a list of references for further reading.
All in all, the OWASP Top 10 – as its name suggests – is a compilation of the top 10 threats, and should be treated as such: a good starting point for dealing with Web application security, but definitely not an exhaustive checklist you can or should be compliant with. This is also well reflected in the “What’s next” sections in the document itself; those sections detail next steps to follow for various stakeholders in order to secure the software development process.
About the new release
Previous iterations of the OWASP Top 10 were built purely by measuring the prevalence of individual vulnerabilities in the datasets provided by evaluators and vendors in order to come up with the ten most common issues, and then ranking those ten according to exploitability, detectability and impact. This process has significantly changed this year: according to the new approach, 8 items are chosen objectively, based on the prevalence values in the datasets (quantitative data) while 2 items are chosen based on a survey of security professionals (qualitative data). This allows the Top Ten Project to cover some ‘forward looking’ vulnerability types as well: ones that may not be specifically prevalent now, but have the potential to become critical issues in the upcoming years, according to experts.
In parallel with this, the calculation of vulnerability prevalence values themselves has changed: instead of measuring the frequency of a particular security issue (the total number of times a particular vulnerability was found), it used the incidence rate of security issues, i.e. the percentage of applications that had at least one instance of a particular vulnerability. This combined approach has the advantage of reducing potential bias in the selection process that’d favor easier-to-find vulnerabilities – both by tools and penetration testers.
The new methodology – as well as the details of the survey for selecting the 2 ‘forward looking’ issues – is described in the new Methodology and Data section within the Top 10 document.
As for the new list itself, the observed quantitative data comprised security issues observed in over 114000 applications, while the qualitative data was based on a survey of over 500 application security experts. This resulted in quite a few changes as compared to the previous 2013 edition:
Broken Authentication and Session Management (A2) was renamed to Broken Authentication.
Cross-Site Scripting (XSS) (former A3) dropped down to A7.
Insecure Direct Object References (former A4) was merged into Missing Function Level Access Control (former A7), forming the new item named Broken Access Control (A5).
Security Misconfiguration (former A5) dropped down a bit, to A6.
Sensitive Data Exposure (former A6) rose significantly, to A3.
Cross-Site Request Forgery (CSRF) (former A8) was dropped.
Unvalidated Redirects and Forwards (former A10) was dropped.
Three new issues were added: XML External Entity (XXE) (A4), Insecure Deserialization (A8) and Insufficient Logging & Monitoring (A10)
As we can see, RC2 represents a significant evolution compared to OWASP Top 10 2013 – and even compared to the OWASP Top 10 2017 RC1 released this April. Is this only due to the new methodology applied, or can we observe some new trends in Web application security? The answer is: both!
The merging of Insecure Direct Object References and Missing Function Level Access Control is just bookkeeping – Broken Access Control was the original OWASP category for these two vulnerability types anyway, so they both remain as important as ever.
Some items changed their position within the list as a result of evaluating the dataset – most notable is Cross-Site Scripting (XSS) dropping from A3 to A7 due to the rise of presentation frameworks that prevent it, such as React and Angular. Similarly, Sensitive Data Exposure rose from A6 to A3 – in today’s world of large-scale data breaches and regulations such as GDPR, sending and storing confidential information unprotected became an extremely critical issue. Note, however, that sensitive data exposure is a possible consequence of various vulnerabilities rather than a vulnerability (or a vulnerability category) itself.
Dropping Unvalidated Redirects and Forwards was a straightforlward decision – it was a somewhat common problem some years ago, but only made it to the 10th position on the list both in 2010 and 2013, arriving to the #25 spot based on the dataset in 2017. Dropping Cross-Site Request Forgery (CSRF) – only reaching #13 in incidence rate – isn’t a surprise either; most Web frameworks (such as Angular, JSF, ASP.NET MVC, Ruby on Rails and Laravel) already included effective countermeasures, typically applied by default. The only mistake one can commit is to disable these solutions. Broken Authentication and Session Management became just Broken Authentication, reflecting the fact that many former session-related weaknesses (e.g. session fixation or insecure session ID generation) became de-emphasized due to standardized solutions in modern Web frameworks and browsers. Session management is a typical example of “don’t do this at home” after all.
The most interesting change – as we see it – is the addition of the three new entries: XML External Entity (XXE) (A4), Insecure Deserialization (A8) and Insufficient Logging & Monitoring (A10). XXE was added based on the incidence rate as well as trends in discovery over the last few years – its prominent initial position is justified by the high risk posed by XXE attacks. Insecure Deserialization was added based on community input in light of several hard-to-exploit, yet critical weaknesses in distributed applications deserializing JSON data as well as Java or .NET classes (see e.g. this presentation). Insufficient Logging & Monitoring is another issue added based on community input, connecting the application security domain to incident response and forensics – insufficient or nonexistent logging in the application can cause significant damage to the infrastructure or the company indirectly.
An interesting trend in the new OWASP Top 10 is an emphasis on detection and exploitability of security issues with automated tools instead of focusing on ease of detection from the penetration tester’s (human) point of view; it is expected that attackers will be using such tools as their main way of revealing vulnerabilities instead of relying on manual discovery. There is also some more weight placed on infrastructure security and incident response, though not as heavily as in RC1 (this aspect, by the way, generated most of the criticism).
The OWASP Top 10 2017 is on track to be released by the end of this year, and it is unlikely to change much compared to the RC2. This is a good time to get familiar with the new list – especially with the new items that appeared in it!
We are, of course, updating our courses to reflect the new Top 10 list when discussing Web application security.