What OWASP Got Wrong on the 2017 Top 10 Application Security Risks List

OWASP puts the cart before the horse when it comes to how you keep your data safe

The Open Web Application Security Project (OWASP) finally released the third — and possibly final — version of their much vaunted Top 10 list for 2017 detailing the vulnerabilities that are considered to be the most pernicious throughout the industry.

This marks the group’s fifth report since its first publication in 2004, taking a crowdsourced look at the temperature of where we are at in web app sec, and reminding us of how far we still have to go.

For the past three reports (2010, 2013, and 2010), injection attacks have topped the list, leading many a security professional to bang their head against their desk in frustration that we are still in this place. Having spoken with more than one well-known and experienced CISO or CSO, they are quick to point out that many of these vulnerabilities are the stuff of script kiddies and should have been wiped clean from the list many years ago.

While three new items — XML External Entities (XXE), Insecure Deserialization, and Insufficient Logging & Monitoring — were added to the list, it is safe to say that the first draft missed the mark in describing the reality facing the industry.

Looking at the first version that was published in April, it included very few changes and was apparently rejected quite quickly by the community. Lacking full visibility into all the factors that went into the decisions for this list, understanding some of the grumbling about independence and who was steering the project team, it is difficult to really judge how they produced this initial list which was received with what some are saying was unnecessary vitriol. Let’s remember that even with the best of intentions by the organizers, it is near impossible to make everyone in the web app community happy.

That said, there were two important points in the Top 10 that stuck out to us and how we think about the security landscape.

One of the most glaring points that jumps out is the fact that “Sensitive Data Exposure” leaped to the #3 slot, knocking XXS down to #7, leading to the question of what happened between April and November?

Equifax Changed Everything

Well simply put, Equifax happened, knocking the app sec crowded upside the head and reshuffling the deck.

So while moving Sensitive Data Exposure up the ladder makes sense as data breaches and infiltrations have become the biggest nightmare for companies handling user data, we are curious why using components with known vulnerabilities is left in the same position at #9?

The Equifax breach is arguably the most significant breach in history, taking into account the scale of the 145 million victims affected and the breadth of the personal information that was stolen. Considering the magnitude of the Equifax breach, how could the updated OWASP list still place known vulnerabilities so close to the bottom?

Had the company been more on top of their usage of components with known vulnerabilities, like the one in the Apache Struts2 project, then they could have avoided the breach and exposure of sensitive data that followed, forcing their top level leadership to resign.

Reviewing this list, it feels like OWASP put the end result of the breach, the part after the hackers broke through the perimeter defenses, before the initial flaw which was leaving wide open — and easily solvable — gaps in their walls. To compare this to network security, having good detection protection is very important to catch attackers who have made it inside your system, but you still need to prioritize tools like micro-segmentation and firewalls to prevent them from making it inside in the first place.

Looking to 2020

Assuming that OWASP continues to issue their updates every three years or so, we can look forward to 2020 for the next round of changes to the list.

Our first hope for the future list is that we can finally knock injections off its pedestal, instilling in programmers a smarter way of working to keep stupid attacks like that from being effective.

If the industry continues on its current path towards a dominant DevOps approach, we can predict that more of the issues down the line will relate to how to work safer in this faster paced environment.

Three years is quite a lot of time in the technology space, and automation tools could help to take a lot of the work out of making our products secure. With any luck, a combination of better education on best practices and automation that take a lot of the effort off the minds of developers, helping to reduce this list to the more complex elements that truly demand our attention.