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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
WebAuthn, FIDO2 Infuse Browsers, Platforms with Strong Authentication
John Fontana, Standards & Identity Analyst, Yubico,  9/19/2018
NSS Labs Files Antitrust Suit Against Symantec, CrowdStrike, ESET, AMTSO
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/19/2018
Turn the NIST Cybersecurity Framework into Reality: 5 Steps
Mukul Kumar & Anupam Sahai, CISO & VP of Cyber Practice and VP Product Management, Cavirin Systems,  9/20/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Are you sure this is how we get our data into the cloud?
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-8298
PUBLISHED: 2018-09-24
Multiple SQL injection vulnerabilities in the login page in RXTEC RXAdmin UPDATE 06 / 2012 allow remote attackers to execute arbitrary SQL commands via the (1) loginpassword, (2) loginusername, (3) zusatzlicher, or (4) groupid parameter to index.htm, or the (5) rxtec cookie to index.htm.
CVE-2018-14825
PUBLISHED: 2018-09-24
A skilled attacker with advanced knowledge of the target system could exploit this vulnerability by creating an application that would successfully bind to the service and gain elevated system privileges. This could enable the attacker to obtain access to keystrokes, passwords, personal identifiable...
CVE-2018-17437
PUBLISHED: 2018-09-24
Memory leak in the H5O_dtype_decode_helper() function in H5Odtype.c in the HDF HDF5 through 1.10.3 library allows attackers to cause a denial of service (memory consumption) via a crafted HDF5 file.
CVE-2018-17438
PUBLISHED: 2018-09-24
A SIGFPE signal is raised in the function H5D__select_io() of H5Dselect.c in the HDF HDF5 through 1.10.3 library during an attempted parse of a crafted HDF file, because of incorrect protection against division by zero. It could allow a remote denial of service attack.
CVE-2018-17439
PUBLISHED: 2018-09-24
An issue was discovered in the HDF HDF5 1.10.3 library. There is a stack-based buffer overflow in the function H5S_extent_get_dims() in H5S.c. Specifically, this issue occurs while converting an HDF5 file to a GIF file.