New OWASP Top 10 - The ten most critical web application security risks
Article published in SecurAware February 2018 - Insight - by Tom Tervoort, Security Analyst at Secura
Since the previous version of the OWASP Top 10, which dates back to 2013, a lot has changed in the area of web applications. What do these developments mean for security? Do the same problems still exist or do we now have to deal with entirely new risks?
A1:2017 - Injection
The most well-known example is named SQL injection, with which an attacker is able to execute specific queries and by doing so is able to read or modify data that is present in the underlying database. Even though SQL injection has been a widespread and large problem for over 20 years, this risk still occurs, albeit at a less frequent rate during our investigations. Nowadays developers are well aware of the impact that this infamous risk causes and web frameworks are designed to prevent this risk by default. On the contrary this does not hold for other types of injection vulnerabilities: An interesting example of this is NoSQL injection, which executes a similar attack against query languages of alternative, non-relational databases.
A2: 2017 – Broken Authentication
In general, it is a difficult task to prevent an attacker from hijacking user’s accounts. New trends have emerged in this area as well, such as stateless session management, single sign-on and authentication methods that are a good fit for mobile applications. These trends also pose new risks; risks that developers may be less familiar with.
A3:2017 - Sensitive Data Exposure
The third risk is sensitive data exposure caused by, for example, the lack of encryption or (strong) user authentication. Nowadays, sensitive data is frequently disclosed by accident. On the upside, the use of encryption during transport by means of HTTPS has increased drastically.
A4:2017 – XML External Entities (XXE) [NEW]
The fourth risk on the list is a notable newcomer. This is an old issue that allows an attacker to read arbitrary files on the server, as well as on the network behind the firewall. This issue is caused by a feature that is offered in (old) software that reads XML messages.
The risk has made it into the Top 10 because static source code analysis shows that it is very prevalent in practice. Hopefully its listing in the OWASP Top 10 will lead to more widespread knowledge about this obscure but dangerous vulnerability.
A5:2017 – Broken Access Control Risk
number five is a classic issue that is still very widespread, even in modern web technologies that often employ sophisticated means of authentication. The absence of authorization checks typically classes as a vulnerability that is difficult to test for with automatic testing software.
A6:2017 – Security Misconfiguration
Frequently software is configured in a default manner so that it is easy to deploy and use. This however does not guarantee that the configuration is also secure. Ensure that important security features are enabled, you do not make use of default passwords and have disabled debugging functionality within production environments.
A7:2017 – Cross-Site Scripting (XSS)
The seventh risk is cross-site scripting: the hijacking of another user’s browser session by injecting scripts in a web page. This risk has seen a big decline since 2013: it dropped four places from number three in 2013 to number seven last year. This vulnerability can be disastrous nonetheless; however, it is much more difficult to exploit nowadays due to the mitigations employed by web frameworks. These types of security measures are in practice however unfortunately often disabled when they get in the way of development. Furthermore, they do not offer exhaustive protection against all forms of cross-site scripting attacks.
I do hope that we will one day learn to not include user input within instruction languages, causing injection vulnerabilities to be dethroned from the Top 10 of most critical web application security risks
A8: 2017 - Insecure Deserialization [NEW, Community]
Insecure deserialization is the possibility for an attacker to modify a transported programming language object, which allows the hijacking of the server.
A9: 2017 - Using Components with Known Vulnerabilities
Using components with known vulnerabilities is listed because it is relatively easy to use software that detects these vulnerabilities.
A10-2017 – Insufficient Logging & Monitoring [NEW, Community]
Insufficient logging and monitoring is also a newcomer in the Top 10 and relates to the fact that you assume that prevention by itself is sufficient. It is just as important that you are able to detect hacking attempts and respond to it in a just manner, as well as having a contingency plan in case things go south.
It would not come as a surprise if technology-specific issues such as external XML entities and insecure deserialization were to be gone in the next iteration of the Top 10. These types of risks are easily detected, mitigated and prevented. More fundamental issues such as broken authentication and using components with known vulnerabilities however are likely to be featured on the Top 10 for many years to come. The reason for this is that these are examples of risks that cannot simply be mitigated by implementing new or different technologies. They will pose a challenge for developers, just like they have been doing for the past ten to twenty years. I do hope that we will one day learn to not include user input within instruction languages, causing injection vulnerabilities to be dethroned from the Top 10 of most critical web application security risks.
OWASP offers a wealth of information that helps prevent such risks, but also to offer guidelines for testing existing applications through the OWASP Testing Guide (https://www.owasp.org/ images/1/19/OTGv4.pdf).
Would you like to expand your knowledge on this topic? The Secure Programming training on 10 April 2018 is open to join. This course is intended for developers, who want to learn how to program more secure. Programming skills are required and a basic knowledge regarding the OWASP top 10 is needed. Register now: There are only 18 seats available.