The OWASP Top 10 is a list of common and critical security vulnerabilities that could affect applications. The first version was released back in 2003, which was updated in 2013. However, as OWASP puts it, “change has accelerated over the last four years, and the OWASP Top 10 needed to change.” Using feedback from firms specializing in application security and data from surveys filled by over 500 individuals, OWASP issued a new release candidate in April 2017. The first release was controversial and pushed back by the AppSec community, so OWASP had to make new changes and issued a new draft in August. The latter was finally adopted and published in November 2017. This article clarifies the new web security risks as defined by OWASP, and draws a comparison between 2013 and 2017 versions by listing all the changes that have taken place.

Comparative table of 2013 and 2017 OWASP Top 10 Lists (Image from OWASP)

OWASP 2013 vs 2017: What has remained the same?

The A1 – Injection class of vulnerabilities tops both lists as the risk will remain present as long as applications blindly trust user input and do not have a proper sanitization mechanism in place. SQL injection, for instance, is still hackers all-time favorite attack vector, and according to Verizon, SQL injection is involved in nearly a quarter of incidents where card details are compromised.

OWASP 2013 vs 2017: What has changed?

A2 – Broken authentication and Session Management was shortened and renamed Broken Authentication which makes sense since the latter is more general and includes sessions-related issues. A3 – Cross-Site Scripting (XSS) has dropped in ranking to hold the 7th position after it was the 3rd in 2013 list. Although XSS is still a severe risk that would lead to session hijacking, remote code execution in the victim’s browser, etc., most frameworks are now automatically escaping XSS by design, such as the latest Ruby on Rails, React JS, etc. A4 – Insecure Direct Object References was merged with A7 – Missing Function Level Access Control into a new category called A5 – Broken Access Control. Both categories were relatively similar and share the same root cause, which is missing control access. It all boils down to a simple question: Am I supposed to have access to this data when logged in? As a result, merging both categories is logical and expected based on the AppSec community feedback over the past years. A5 – Security Misconfiguration is still a relevant issue, but dropped in the list by one ranking to settle in the 6th position. Sensitive Data Exposure was listed as A6 in OWASP 2013. In 2017, it moves up to the A3 position. Sensitive data exposure has been a huge issue in the past few years, which resulted in very alarming security breaches at Uber, Deloitte, Equifax and other large companies. This is especially concerning with GDPR on the horizon.

OWASP 2013 vs 2017: What risks were retired?

A8 – Cross-Site Request Forgery (CSRF) was retired and dropped from the 2017 list. This does not mean the risk doesn’t exist anymore. According to OWASP, the reason behind this is “many frameworks include CSRF defenses, [CSRF] was found in only 5% of applications.” Similarly, A10 – Unvalidated Redirects and Forwards was retired from the list. According to OWASP, “while found in approximately in 8% of applications, it was edged out overall by XXE.” Open redirect itself is a relatively low severity issue. It is usually exploited for phishing purposes but is still a weakness attackers abuse and chain with other vulnerabilities in order to achieve a higher security impact. It is important to keep in mind just because these have slipped outside the OWASP Top 10, it does not mean they should be ignored. Rather, organizations must continue to ensure the coding practices they use are mitigating these well-documented vulnerabilities, as well as those in the current OWASP Top 10.

OWASP 2013 vs 2017: What new risks were added?

Based on the community insights and supported data, OWASP added three new classes of security risks to the list:

1. A4 – XML External Entities (XXE)

This is a class of attacks that target applications using XML parsers. The attack takes place when an XML user input contains a reference to an external entity, which then is processed by a misconfigured XML parser. A successful exploitation leads to disastrous consequences, such as accessing web server resources, conducting an SSRF attack to scan ports and enumerate internal network, denial of service when chained with billion laughs attack, etc. This particular attack has been around for decades, but it has only recently received attention as high-profile companies such as Facebook, Twitter and Google are also finding themselves vulnerable via bug bounty programs. Most XML parsers are vulnerable to XXE by default, but the proper way to mitigate XXE is to completely disable DTDs (external entities).

2. A8 – Insecure deserialization

This attack takes advantage of how applications make use of serialization and deserialization. Serialization is the process of converting objects into data format, commonly JSON and XML, to store them or use them in communications. Deserialization is the opposite process which takes formatted data and structures it into objects. The attack, however, targets the deserialization process through untrusted user input. Attackers abuse deserialization features when the application is deserializing untrusted user input. A successful exploitation allows it to carry out denial of service (DoS) attacks, bypass access controls and eventually remote code execution.

3. A10 – Insufficient logging & monitoring

This is more of a lack of control than a vulnerability. It’s nevertheless very important to have proper mechanisms in place to log and monitor all kinds of events and activities, whether operational or security related. These logs are indispensable to detect malicious activity or unauthorized breaches in a timely manner; the lack of this control only benefits attackers, giving them a persistence access or pivot to others’ systems. According to OWASP, a lack of proper logging and monitoring carries the following risks:

Auditable events, such as logins, failed logins and high-value transactions are not logged. Warnings and errors generate no, inadequate or unclear log messages. Logs of applications and APIs are not monitored for suspicious activity. Logs are only stored locally without any Cloud backup. Appropriate alerting thresholds and response escalation processes are not in place or effective. Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts. The application is unable to detect, escalate or alert for active attacks in real time or near real time.

Source

OWASP Top 10 – 2017, OWASP