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
