Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

4/27/2017
02:31 PM
By Chris Eng
By Chris Eng
Commentary
100%
0%

OWASP Top 10 Update: Is It Helping to Create More Secure Applications?

What has not been updated in the new Top 10 list is almost more significant than what has.

The OWASP Top 10 list of the most critical web application security risks has finally been updated for the first time since 2013. This list, created by the Open Web Application Security Project (an open community dedicated to enabling organizations to create secure applications), often forms the basis of application security programs and frequently informs AppSec priorities.

The release candidate was published on April 10th, and OWASP plans to release the final version in July or August after a public comment period ending June 30th.

How Companies Actually Use the Top 10
I’ve been specializing in application security – first as a breaker and now as a defender – since long before the OWASP Top 10 list existed. When the first iterations of the lists were released, they were helpful to both me and my customers in the sense that they provided independent, vendor-agnostic advice on real-world application security risks. Later, the Top 10 was incorporated into the PCI DSS, which elevated the list’s importance in a way that never could have happened organically. Suddenly, many companies were required to invest in these very specific elements of application security – and they did. They look to this list to understand how to avoid and remediate a range of vulnerabilities.

Over the past decade, companies large and small have continued to adopt the Top 10 list as a guideline. They know it’s not the be-all and end-all of application security risks, but it’s a useful list to baseline against as they scale application security testing to hundreds – often thousands – of applications, built using development methodologies ranging from waterfall to Agile to DevOps.

Regardless of how the Top 10 list was originally intended to be used, helping to move the industry forward requires acknowledging how the list is actually used in the real world. Building and maintaining a comprehensive application security program is complex and time-consuming, so it’s important to consider the business impact of moving the goalposts.

Reading between the Lines
What has not been updated in the new Top 10 list is almost more significant than what has. It’s the first update in four years, and there are only two significant changes, and none to the top vulnerabilities. This highlights that we are continuing to see the same (often easily remediated) vulnerabilities plaguing our code. We clearly have a long way to go in terms of getting developers to understand secure coding best practices and actually implement them.

Even A4 (Broken Access Control) is simply a combination and reframing of A4 and A7 from the 2013 Top 10 list. Broken Access Control was actually category A2 from the 2004 Top 10 list. The vulnerabilities aren’t changing; they’re just being shuffled around, demonstrating that while companies are recognizing the need for application security, not enough has changed to eliminate these common threats.

A Questionable Direction
So if nothing much is new, why is OWASP releasing an update? The only significant updates to the list are the addition of API security, and a recommendation to focus on runtime protection. But the inclusion of API security isn’t much of an update; in fact, A10 (Underprotected APIs) is redundant with other categories that already exist. For example, A1 covers Injection vulnerabilities, and A10 essentially says “injection vulnerabilities can exist in APIs too!” It’s like if you had a residential building code comprised of nine rules, and the tenth item was “all of these rules also apply to blue houses.”

The addition of A7 (Insufficient Attack Protection) is even more confusing. From the working draft: “The majority of applications and APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks. Attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, and even blocking exploit attempts. Application owners also need to be able to deploy patches quickly to protect against attacks.” With this addition, I think the list is now straying from its mission.

In fact, A7 (Insufficient Attack Protection) feels more like a move to elevate certain technologies than guidance on improving security. And I make this statement despite being part of a company that offers RASP technology, an attack protection technology that would certainly fall under the proposed A7. Runtime protection is an interesting and important technology, and with today’s rapid development cycles is becoming an increasingly critical component of application security programs. But protection is orthogonal to the purpose of this list, which is to highlight the most important security risks.

It muddies the mission of the OWASP Top 10 to stray from vulnerabilities to a focus on technologies. Why does insufficient protection belong on the list, but not insufficient testing, insufficient code coverage, insufficient threat modeling, or insufficient developer education? All of these activities occur during the application lifecycle and improve application security.

Get back on track
Application security goes beyond any specific technology; there is no application security silver bullet. Securing applications requires a combination of people, process, and technology – both automated and manual – throughout the software development lifecycle. The new list seems to focus on changes that are either cosmetic or misaligned from the views of many application security experts. What’s the value in releasing an updated list compared to the disruption it will create for companies measuring against it? Failing to account for impact is neither visionary nor productive. Perhaps we need a little more empathy for the developers and end users instead of being excited to shake things up.

[Read an opposing view from Jeff Williams in New OWASP Top 10 Reveals Critical Weakness in Application Defenses.]

Related Content:

 

Chris Eng (@chriseng) is vice president of research at Veracode. Throughout his career, he has led projects breaking, building, and defending software for some of the world's largest companies. He is an unabashed supporter of the Oxford comma and hates it when you use the ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-17448
PUBLISHED: 2020-08-11
Telegram Desktop through 2.1.13 allows a spoofed file type to bypass the Dangerous File Type Execution protection mechanism, as demonstrated by use of the chat window with a filename that lacks an extension.
CVE-2020-17466
PUBLISHED: 2020-08-11
Turcom TRCwifiZone through 2020-08-10 allows authentication bypass by visiting manage/control.php and ignoring 302 Redirect responses.
CVE-2020-11552
PUBLISHED: 2020-08-11
An elevation of privilege vulnerability exists in ManageEngine ADSelfService Plus before build 6003 because it does not properly enforce user privileges associated with a Certificate dialog. This vulnerability could allow an unauthenticated attacker to escalate privileges on a Windows host. An attac...
CVE-2020-13124
PUBLISHED: 2020-08-11
SABnzbd 2.3.9 and 3.0.0Alpha2 has a command injection vulnerability in the web configuration interface that permits an authenticated user to execute arbitrary Python commands on the underlying operating system.
CVE-2020-15597
PUBLISHED: 2020-08-11
SOPlanning 1.46.01 allows persistent XSS via the Project Name, Statutes Comment, Places Comment, or Resources Comment field.