Interested in formal OWASP Top 10 Training? Check out our  OWASP Top 10 Training course OWASP Top 10 Training

The OWASP Top 10 list publicizes the most critical web application security flaws as determined by Open Web Application Security Project (OWASP), a nonprofit, vendor-independent IT security organization formed in 2001. In this article, we preview the 2013 edition of this popular security resource. (This review is based on the 2013 release candidate.)

The OWASP Top 10 Is Revised Every Three Years

OWASP aims to update the Top 10 once every three years as IT security threats evolve over time, and the OWASP Top 10 for 2013 will be released in May 2013. The original Top 10 release occurred in 2003, and was followed by the 2004, 2007 and 2010 editions.

OWASP board member Dave Wichers explained the three-year update cycle in a March 3, 2013 post to an OWASP newsletter. “The 3 year cycle has worked well in the past for several reasons. The field does evolve pretty quick but I don’t think the Top 10 Risks substantially change every single year. It takes a lot of work to produce an update to the Top 10, and so spacing it out balances between the effort to produce and the amount of change you’d see when it’s updated.”

The OWASP Top 10 Is Loosely Affiliated with PCI-DSS

The OWASP Top 10 rose to prominence in part due to references in the Payment Card Industry Security Standards Council’s Data Security Standards, better known as the PCI-DSS. For years, the 2004 edition of the OWASP Top 10 list was regarded as a gold standard, with PCI-DSS 1.1 referring to it even though a 2007 edition of the Top 10 was available. In recent versions, there has been tighter coordination between the two bodies, with PCI-DSS 2.0 referring to the 2010 edition of the OWASP Top 10.

Changes to the OWASP Top 10 between 2010 and 2013

Added: “Using Known Vulnerable Components”

The only new item in the 2013 edition of the OWASP Top 10 was the addition of “Using Known Vulnerable Components.” Listed at #9, it highlights a hazard that was previously an element of “Security Misconfiguration.”

Many, if not most, web application developers depend on technology built by other developers, including web toolkits, widgets, runtime engines, web servers, and operating systems. All of these components may contain their own flaws, many of which are never considered by web application developers. Furthermore, OWASP notes that many components that have fixed their vulnerabilities are never properly reincorporated into the applications that depend on them.

OWASP writes, “Some vulnerable components (e.g., framework libraries) can be identified and exploited with automated tools, expanding the threat agent pool beyond targeted attackers to include chaotic actors. (An) attacker (may) identify a weak component through scanning or manual analysis, (then) customize the exploit as needed, and execute the attack. It gets more difficult if the used component is deep in the application.”

OWASP continues, “Virtually every application has these issues because most development teams don’t focus on ensuring their components stay up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse. The full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact could be minimal, up to complete host takeover and data compromise.”

Removed: Nothing

OWASP removed nothing from the 2010 Top 10 in the 2013 Top 10. To fit in its only new entry, two 2010 entries (#7 Insecure Cryptographic Storage and #9 Insufficient Transport Layer Protection) were merged into a new, higher-priority item: #6 Sensitive Data Exposure.

Promoted: Insecure Cryptographic Storage and Insufficient Transport Layer Protection

See “Removed: Nothing” above.

Promoted: Broken Authentication and Session Management

2010 Top 10′s #3 item, Broken Authentication and Session Management, was promoted to #2 in the 2013 edition of the OWASP Top 10. OWASP lists this flaw as “widespread,” having a “severe” impact, and was worried enough about it to permit it to vault Cross-Site Scripting (XSS) in priority.

OWASP writes: “Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users. Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc.”

OWASP continues, “Finding such flaws can sometimes be difficult, as each implementation is unique. Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted. (Watch out for) anonymous external attackers, as well as users with their own accounts, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions.”

Promoted: Security Misconfiguration

The #6 item from 2010, Security Misconfiguration, moved up one slot to #5 in the 2013 edition as the previous #5, Cross-Site Request Forgery moved down to #8. OWASP lists this flaw with only a “moderate” impact, but lists its exploitability as “easy” and prevalence as “common.”

OWASP writes, “Attacker accesses default accounts, unused pages, unpatched flaws, unprotected files and directories, etc. to gain unauthorized access to or knowledge of the system. Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, framework, and custom code. Developers and network administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.”

OWASP continues, “Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise. The system could be completely compromised without you knowing it. All your data could be stolen or modified slowly over time. Recovery costs could be expensive.”

Promoted and Renamed: Failure to Restrict URL Access

Failure to Restrict URL Access, the #8 item from 2010, was renamed as “Missing Function Level Access Control” and promoted to #7 in 2013. This item was promoted because its prevalence was increased from “uncommon” to “common” between 2010 and 2013.

OWASP writes, “Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget. Detecting such flaws is easy. The hardest part is identifying which pages (URLs) or functions exist to attack.”

While OWASP’s examples continue to show how different URLs could be exploited, they now also provide examples that demonstrated how a single URL could be exploited with different input parameters. OWASP now also explicitly recommends enforcing access controls in an application’s “controller or business logic” layer rather than its presentation layers.

Demoted: Cross-Site Scripting and Cross-Site Request Forgery

In 2013 OWASP dropped the priority of both Cross-Site Scripting (down to #3 from #2 in 2010) and Cross-Site Request Forgery (down to #8 from #5).

OWASP continues to list the prevalence of Cross-Site Scripting as “very widespread” and has left the exploitability (“average”), detectability (“easy”) and impact (“moderate”) unchanged. However, the 2013 guidance includes a reference to “safe JavaScript APIs” that was not present in 2010. If this guidance persists, it would be a clear signal to web developers to adopt those APIs or at least the principals behind them in their applications.

The methodology behind OWASP’s demotion of Cross-Site Request Forgery (CSRF) is easier to follow. In 2010, OWASP listed the prevalence of CSRF as “widespread,” but in 2013 OWASP now lists it as merely “common.”

Almost Made It: Application DoS

If there was one vulnerability that just missed the OWASP Top 10 it would have been web application denial-of-service attacks (“DoS”). The debate over whether or not to include this item was frequent and heavy on newsgroups debating the draft Top 10 list.

OWASP board member Dave Wichers started one such discussion on March 14, 2013 when he referenced an article about six banks getting hit by a DDOS attack on the same and then asked for, “any stats/metrics on how many DDOS attacks are at the application level vs. the network level?”

Want to learn more?? The InfoSec Institute Web Application Penetration Testing Boot Camp focuses on preparing you for the real world of Web App Pen Testing through extensive lab exercises, thought provoking lectures led by an expert instructor. We review of the entire body of knowledge as it pertains to web application pen testing through a high-energy seminar approach.

The Web Application Penetration Testing course from InfoSec Institute is a totally hands-on learning experience. From the first day to the last day, you will learn the ins and outs of Web App Pen Testing by attending thought provoking lectures led by an expert instructor. Every lecture is directly followed up by a comprehensive lab exercise (we also set up and provide lab workstations so you don't waste valuable class time installing tools and apps). Benefits to you are:

  • Get CWAPT Certified
  • Learn the Secrets of Web App Pen Testing in a totally hands-on classroom environment
  • Learn how to exploit and defend real-world web apps: not just silly sample code
  • Complete the 83 Step "Web App Pen Test Methodology", and bring a copy back to work with you
  • Learn how perform OWASP Top 10 Assessments: for PCI DSS compliance

Wichers clarified his inquiry by stating, “The OWASP Top 10 is about web applications, not network security. And I know if they DDOS the server and take out an application, then it’s an application problem, but is there anything the application itself can do about the most common DDOS attacks?”

After several posters responded negatively to the idea, Steven Christey from MITRE Corporation (the non-profit organization behind CVE) jumped in on March 20, 2013. “Regarding application DoS – I don’t know if we should be so dismissive of it. The (negative) commentary I’ve seen on application DoS is concentrating on network-based attacks. (However,) there are other resource-consumption vulnerabilities that are gaining popularity in CVE, such as unrestricted XML entity expansion, a.k.a. “billion laughs” (CWE-776) (that causes a DoS due to) memory consumption. Another example is algorithmic complexity involving hash collisions that slow down hash-table lookups, which was all the rage about a year ago, (that causes a DoS due to) CPU consumption. More recently, Ruby and/or Ruby-based applications have been getting hit with a number of other resource-consumption issues, such as a memory DoS by forcing the creation of a large number of symbols.”

Christey continued, “While I don’t know how often these are exploited, and they may be difficult to detect, or how often they’ll be exploited in the future, these kinds of application DoS issues are becoming popular. As code-execution vulnerabilities get harder to find, I suspect we will see more of these. This might not be enough to merit inclusion in the OWASP Top Ten, but is definitely something to watch out for.”

Also Considered: Web Service Vulnerabilities

In the OWASP Top 10 newsgroups, there was some discussion of whether or not the current advice provided sufficient guidance on web applications that mainly function as APIs – i.e., web services.

On March 20, 2013 OWASP board member Dave Wichers noted that, “the web services Top 10 really hasn’t gone anywhere unfortunately,” and suggested that the OWASP Top 10 could, “include XML issues” if it was broadened to include issues like “application level DOS” and “lack of anti-automation.”

The OWASP Top 10 – Current and Previous

OWASP Top 10 – 2013 Edition

A1 Injection
A2 Broken Authentication and Session Management
A3 Cross-Site Scripting (XSS)
A4 Insecure Direct Object References
A5 Security Misconfiguration
A6 Sensitive Data Exposure
A7 Missing Function Level Access Control
A8 Cross-Site Request Forgery (CSRF)
A9 Using Known Vulnerable Components – New (previously part of “Security Misconfiguration”)
A10 Unvalidated Redirects and Forwards

OWASP Top 10 – 2010 Edition

Changes, if any, in the 2013 edition are listed behind each entry.

A1: Injection
A2: Cross-Site Scripting (XSS) – demoted to A3 in 2013
A3: Broken Authentication and Session Management – promoted to A2 in 2013
A4: Insecure Direct Object References
A5: Cross-Site Request Forgery (CSRF) – demoted to A8 in 2013
A6: Security Misconfiguration – promoted to A5 in 2013
A7: Insecure Cryptographic Storage – combined then promoted to A6 in 2013
A8: Failure to Restrict URL Access – renamed as “Missing Function Level Access Control” then promoted to A7 in 2013
A9: Insufficient Transport Layer Protection – combined then promoted to A6 in 2013
A10: Unvalidated Redirects and Forwards

Additional Information and Similar Projects

The official OWASP Top 10 lists, including complete breakouts of each vulnerability listed in the top ten, can be found at the following URL: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

In addition to the Top 10 list, OWASP sponsors more than a dozen other mature security projects, including the OWASP Enterprise Security API (a.k.a., the “ESAPI” security library), the OWASP WebGoat Project (used as a honeypot or training target), and the OWASP Secure Coding Practices – Quick Reference Guide. OWASP is also investing in the development of a new lists and resources, such as the OWASP Top 10 Mobile Risks, a new list which is expected to be released at any time.