Application Security

OWASP Top 10 for 2013 Released

The Open Web Application Security Project (OWASP) released an update to its Top 10 list of risks facing developers. As in previous years, injection remained the top application security risk.

<p><span><span><strong>The Open Web Application Security Project (OWASP) released an update to its Top 10 list of risks facing developers. As in previous years, injection remained the top application security risk. </strong></span></span></p>

The Open Web Application Security Project (OWASP) released an update to its Top 10 list of risks facing developers. As in previous years, injection remained the top application security risk.

Injection attacks, which includes SQL injection and other code injection, was rated the top application security risk in the updated Top 10 list for 2013, Dave Wichers, the project lead for OWASP Top 10, wrote on the OWASP Top 10 mailing list Wednesday. Broken authentication and session management, which can lead to password, key, and session compromises, was the second on the list, followed by cross-site scripting errors. Attackers can take advantage of XSS flaws to inject their own code into sites not under their control.

The remaining items on the top 10 list, in order, are: Insecure Direct Object References, Security Misconfiguration, Sensitive Data Exposure, Missing Function Level Access Control, Cross-Site Request Forgery (CSRF), Using Known Vulnerable Components, and Unvalidated Redirects and Forwards.

The rankings are intended to “raise awareness about application security by identifying some of the most critical risks facing organizations,” OWASP said on its wiki. The goal of this Top 10 list is to manage risk and not just avoiding vulnerabilities.

“We need to encourage organizations to get off the penetrate and patch mentality,” the team wrote. Organizations need an application risk management program to manage these risks, and not just rely on awareness training, application testing, and remediation, the team said.

The top three categories remain the same from the previous list, except for the fact that broken authentication and cross-site scripting switched places. Along with cross-site scripting, cross-site request forgery attacks went down in importance in this year’s list.

The Top 10 list first came out in 2003. The newest report was compiled based on over 500,000 vulnerabilities found in several thousand applications from hundreds of companies.

OWASP began seeking feedback for this year’s list several months ago. While most of the categories have remained the same, entries for insecure cryptographic storage and insufficient transport layer protection were merged into a new category “sensitive data exposure.” This new category deals with security problems related to data leaks in general. The “failure to restrict URL access” was expanded to be a more general category for problems with function-level access control.

A new category for administrators who use known vulnerable components such as libraries, frameworks, and modules, was also added to the report.

Advertisement. Scroll to continue reading.

“We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code,” the team wrote.

While the list is generally well-received and referenced by standards bodies such as Payment Card Industry (PCI) and by federal government agencies, some security experts warn that the list is not intended to be a prescriptive list of how to build secure software.

The Top 10 list includes a number of broad categories of threats with large subsets, making it hard to use in any meaningful manner. While the cross-site scripting category is pretty clear on what the developer needs to look for, not all categories are that clear. Take sensitive data exposure—which is very open-ended and could mean several things, making it harder for developers to check their code.

Related: Three Ingredients to Maintaining Application Performance and Security at Scale

Related: 71 Percent of Applications Use Components w/ Severe or Critical Security Flaws

Related: Web Applications Remain Vulnerable to Basic Flaws

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version