Back in May 2017, I reviewed the release candidate (RC1) version of OWASP (Open Web Application Security Project) Top Ten Web Vulnerabilities for 2017, which as stated within the previous blog entry, has been eventually rejected.To quote my previous OWASP introductory description for new readers:
OWASP has been founded back in 2001 and since then it has grown significantly to become a well-recognised reference for web application security. OWASP in simple words is an accumulation of articles, methodologies, documentation and tools that aims to fill the gap between information security and software development. OWASP provides a road map to aid organisations’ understanding of security issues. More importantly it lends credence to penetration testing reports allowing security consultants to promote security best practices.
It’s worth reviewing the final release of the OWASP Top 10 2017 document as it has dramatically changed since the release candidate (RC1) version. After all they say “better late, than never”. In this release the information security community played an important role in selecting two of the new OWASP Top 10 2017 categories. Further data analysis was carried out in an attempt to include key security issues, while providing a balance between issues that can be identified with automated tools and issues that require manual testing. Additionally, OWASP statistical data is now available on the official GitHub repository at https://github.com/OWASP/Top10. This means that any organisation can run fine-grained analysis on these to suit their own needs.
The image below, from the OWASP Top 10 document, depicts the new changes that took place in the final release of the OWASP Top 10 2017.
The merging of “A4-Insecure Direct Object References” and “A7-Missing Function Level Access Control” categories from OWASP Top 10 2013 into a single category “A5-Broken Access Control”, and removal of the “A10-Unvalidated Redirects and Forwards” category, are changes that have been applied on the OWASP Top 10 2017 RC1 version and discussed in my previous blog entry. It is worthwhile noting that “A3 – Cross-Site Scripting (XSS)”, a very common web application vulnerability has been moved from A3 position to A7. The model behind the ordering of the OWASP Top 10 categories changed and it is now risk based. XSS attacks however are a subclass of “A1 – Injection” and therefore this order change should not affect business decisions. Category positions in OWASP Top 10 indicate interesting trends. It is my opinion that OWASP Top 10 ordering should not be taken into consideration by organisations while making business decisions on prioritising the resolution of security issues, as it could yield a false sense of security. Every security issue is unique and depends on many factors per organisation. Hence, risk levels should be assessed separately in each case while considering all possible variables.
The rest of the core changes are discussed in the following sections.
Removal of Cross-Site Request Forgery (CSRF)
Same as the “A10-Unvalidated Redirects and Forwards” category, the “A8 – Cross-Site Request Forgery (CSRF)” category was removed from the OWASP Top 10 2017 list, as the statistical data was not strong enough to justify its place. With the increased use of well-known frameworks or content management systems (CMS), this issue is easily eliminated, as in most of the cases the frameworks or CMS’s will take care of the anti-CSRF tokens and automatically protect the web applications from such attacks. However, developers should not become complacent and rely on the automatic CSFR protection, as the framework or CMS in use may be vulnerable. Misconfigurations or customisations could also lead to a lack of CSRF protection in specific web pages. At the time of writing, one of my colleagues found an interesting CSRF flaw that would allow attackers to modify website pages in order to carry out social engineering attacks against the victims, for example by creating a fake login page. The website was running the latest version of WordPress, but one of the installed plugins was not following the best security practises to ensure CSRF protection.
Having said the above, we still identify CSRF flaws quite often, however most of the time they reside in not so interesting pages, which generally introduce lower risk. Attackers looking to exploit CSRF vulnerabilities would be highly motivated by CSRF vulnerable pages that allow them to takeover, or create, user or administrative accounts, and generally allow them to trick users into performing actions unwillingly yielding monetary profits or allowing them to obtain sensitive information. For example, a page vulnerable to CSRF that only allows users to update their language preference within the application, would not be an interesting target for attackers.
Addition of XML External Entities Category
Out of all the OWASP Top 10 2017 changes, the addition of the category “A4 – XML External Entities (XXE)” to OWASP Top 10 is the most important one in my opinion. Note that XXE also falls under “A1 – Injection”, as attackers in this case can inject in XML structures with aim to trick the parser on the server-side so that it carries out unwanted operations, such as disclosing the contents of a local configuration file. In the same fashion with XSS, XXE is now part of the new OWASP Top 10, as it has become a more critical vulnerability over time and its addition stresses this security flaw further. Researchers, security consultants, and attackers have been aware of this flaw for long time. See for example the XXE vulnerability page here which has been written back in 2002. OWASP researchers have also presented about XXE back in 2010.
As XML offers many advantages in web development, and due to the rise of XML based web services in the previous years, OWASP’s emphasising the importance of XXE should aid into increasing awareness and help eliminate, or reduce, the instances of this vulnerability in the wild. From our testing experience, although we identify XXE flaws regularly, due to application configuration and time restrictions it is not always possible to fully exploit these flaws in order to compromise the vulnerable server. The drawback of this is that we are unable to demonstrate the impact of such a flaw at its fullest, which could mislead organisations into not prioritising this flaw. In such cases, being able to support XXE security findings with OWASP references can further help organisations realise the criticality of this security issue. The following pages from OWASP provide further information on testing and preventing XXE attacks:
https://www.owasp.org/index.php/Testing_for_XML_Injection_(OTG-INPVAL-008) https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
As a last note for this category, since fully exploiting XXE is not always possible and does not always justify a vulnerability of a critical risk level, the “A4 – XML External Entities (XXE)” could be lower in the OWASP Top 10 2017 list. However, in my opinion, this should not have any implications, as organisations should not rely on the OWASP Top 10 ordering, and should consider each common web vulnerability equally.
Addition of Insecure Deserialization
As said before, the information security community was part of the addition of two categories in the final release of the OWASP Top 10 2017, one of which is the “A8 – Insecure Deserialization”. By exploiting insecure deserialisation attackers may try to inject in serialised objects taking advantage of how application objects are being deserialised by the server-side application, with the goal of achieving code execution on the server remotely. Researchers have been releasing information regarding this flaw for several years, but this was not a very noisy vulnerability class in the field of web application penetration testing until 2015. In 2015, researchers paid closer attention to pre-existent deserialisation vulnerabilities and demonstrated the critical impact behind these flaws by creating working proof of concept exploits for a number of well-known software, such as JBoss. For more information on this, see the article here.
The addition of this category in OWASP Top 10 2017 is quite an interesting topic. From our internal web application penetration testing experience, we often get to exploit publicly known deserialisation vulnerabilities existent within Java libraries that the developers leverage. However, we rarely see web applications implementing custom serialisation/deserialisation. This is usually handled by the frameworks in place, or the libraries. Therefore, most of the times we could attribute insecure deserialisation to the use of vulnerable versions of software components, which would fall under “A9 – Using Components with Known Vulnerabilities”.
All in all, insecure deserialisation is a complicated topic and if the OWASP Top 10 2017 list can afford a slot for this, it is beneficial having it there, especially since this was selected according to the community’s survey results. Apart from raising developers’ awareness, I believe the addition of this category in OWASP Top 10 2017 will help to: 1) stress the importance of manual web application testing, especially when it comes non-static complicated applications, and 2) ensure penetration testers pay closer attention to object serialisation/deserialisation.
Addition of Insufficient Logging & Monitoring
Monitoring and logging of system events is an important security control which aims to alert organisations into responding to an attack quickly and minimising the impact, or guaranteeing that enough evidence can be collected in a digital investigation following a security incident. This has earned its own place in the OWASP Top 10 2017 as “A10 – Insufficient Logging & Monitoring”, and it was the second category selected by the community.
Security consultants have argued a lot on whether this should be part of the OWASP Top 10 web app vulnerabilities list or not. Statistical data shows that organisations are failing to successfully detect breaches on time and respond. Within Dionach, sometimes we are in the unfortunate position of informing clients that they may have been compromised. Although the lack of this control usually falls under other types of security assessments and guidelines, I do not see a problem with having it as a reminder within the OWASP Top 10 2017.
Conclusion
Looking forward to OWASP Top 10 2020 and having summarised my thoughts about the modern OWASP Top 10 in the previous blog, I’ll keep this closing short with the following points.
- OWASP is not a panacea, it was never meant to be. Organisations, consultants and developers should use it as a reference wisely, but never solely rely on it. Risk levels and ordering of security issues are subjective and should always be tailored to the case.
- There have been dramatic changes in the final release of OWASP Top 10 2017, a lot of work has been put into it and the community is now a bigger part of it; which is great.