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: 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?”
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.”

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