The following post, is a guest blog from Jonathan Lampe, from InfoSec Institute. 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 review 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.”
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
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.”
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. By: Jonathan Lampe - InfoSec Institute