Difference between revisions of "Top 10 2007-Methodology"
|(9 intermediate revisions by 3 users not shown)|
|Line 51:||Line 51:|
== Biases ==
== Biases ==
The methodology described above necessarily biases the Top 10 towards discoveries by the security researcher community. This pattern of discovery is similar to the methods of [http://www.zone-h.org/actual attack], particularly as it relates to entry-level ("script kiddie") attackers. Protecting your software against the Top 10 will provide a modicum of protection against the most common forms of attack, but far more importantly, help set a course for improving the security of your software.
The methodology described above necessarily biases the Top 10 towards discoveries by the security researcher community. This pattern of discovery is similar to the methods of [http://www.zone-h.org/
== Mapping ==
== Mapping ==
|Line 134:||Line 133:|
Latest revision as of 17:53, 12 May 2013
Our methodology for the Top 10 2007 was simple: take the MITRE Vulnerability Trends for 2006, and distill the Top 10 web application security issues. The ranked results are as follows:
Although we tried to preserve a one to one mapping of MITRE raw vulnerability data to our section headings, we have deliberately changed some of the later categories to more closely map to root causes. If you are interested in the final 2006 data from MITRE, we have included an Excel worksheet on the OWASP Top 10 web site.
All of the protection recommendations provide solutions for the three most prevalent web application frameworks: Java EE, ASP.NET, and PHP. Other common web application frameworks, such as Ruby on Rails or Perl can easily adapt the recommendations to suit their specific needs.
Why we have dropped some important issues
Unvalidated input is a major challenge for any development team, and is at the root of many application security problems. In fact, many of the other items in the list recommend validating input as a part of the solution. We still strongly recommend creating a centralized input validation mechanism as a part of your web applications. For more information, read the following data validation articles at OWASP:
Buffer overflows, integer overflows and format string issues are extremely serious vulnerabilities for programs written in languages such as C or C++. Remediation for these issues is covered by the traditional non-web application security community, such as SANS, CERT, and programming language tool vendors. If your code is written in a language that is likely to suffer buffer overflows, we encourage you to read the buffer overflow content on OWASP:
Denial of service is a serious attack that can affect any site written in any language. The ranking of DoS by MITRE is insufficient to make the Top 10 this year. If you have concerns about denial of service, you should consult the OWASP site and Testing Guide:
Insecure configuration management affects all systems to some extent, particularly PHP. However, the ranking by MITRE does not allow us to include this issue this year. When deploying your application, you should consult the latest OWASP Development Guide and the OWASP Testing Guide for detailed information regarding secure configuration management and testing:
Why we have ADDED some important issues
Cross Site Request Forgery (CSRF) is the major new addition to this edition of the OWASP Top 10. Although raw data ranks it at #36, we believe that it is important enough that applications should start protection efforts today, particularly for high value applications and applications which deal with sensitive data. CSRF is more prevalent than its current ranking would indicate, and it can be highly dangerous.
Cryptography The insecure uses of cryptography are not the #8 and #9 web application security issues according to the raw MITRE data, but they do represent a root cause of many privacy leaks and compliance issues (particularly with PCI DSS 1.1 compliance).
Vulnerabilities, not attacks
The previous edition of the Top 10 contained a mixture of attacks, vulnerabilities and countermeasures. This time around, we have focused solely on vulnerabilities, although commonly used terminology sometimes combines vulnerabilities and attacks. If organizations use this document to secure their applications, and reduce the risks to their business, it will lead to a direct reduction in the likelihood of:
- Phishing attacks that can exploit any of these vulnerabilities, particularly XSS, and weak or non-existent authentication or authorization checks (A1, A4, A7, A10)
- Privacy violations from poor validation, business rule and weak authorization checks (A2, A4, A6, A7, A10)
- Identity theft through poor or non-existent cryptographic controls (A8 and A9), remote file include (A3) and authentication, business rule, and authorization checks (A4, A7, A10)
- Systems compromise, data alteration, or data destruction attacks via Injections (A2) and remote file include (A3)
- Financial loss through unauthorized transactions and CSRF attacks (A4, A5, A7, A10)
- Reputation loss through exploitation of any of the above vulnerabilities (A1 - A10)
Once an organization moves away from worrying about reactive controls, and moves forward to proactively reducing risks applicable to their business, they will improve compliance with regulatory regimes, reduce operational costs, and hopefully will have far more robust and secure systems as a result.
The methodology described above necessarily biases the Top 10 towards discoveries by the security researcher community. This pattern of discovery is similar to the methods of actual attack, particularly as it relates to entry-level ("script kiddie") attackers. Protecting your software against the Top 10 will provide a modicum of protection against the most common forms of attack, but far more importantly, help set a course for improving the security of your software.
There have been changes to the headings, even where content maps closely to previous content. We no longer use the WAS XML naming scheme as it has not kept up to date with modern vulnerabilities, attacks, and countermeasures. The table below depicts how this edition maps to the Top 10 2004, and the raw MITRE ranking:
|A1 - Cross Site Scripting (XSS)||A4 - Cross Site Scripting (XSS)||1|
|A2 - Injection Flaws||A6 - Injection Flaws||2|
|A3 - Malicious File Execution (NEW)||3|
|A4 - Insecure Direct Object Reference||A2 - Broken Access Control (split in 2007 T10)||5|
|A5 - Cross Site Request Forgery (CSRF) (NEW)||36|
|A6 - Information Leakage and Improper Error Handling||A7 - Improper Error Handling||6|
|A7 - Broken Authentication and Session Management||A3 - Broken Authentication and Session Management||14|
|A8 - Insecure Cryptographic Storage||A8 - Insecure Storage||8|
|A9 - Insecure Communications (NEW)||Discussed under A10 - Insecure Configuration Management||8|
|A10 - Failure to Restrict URL Access||A2 - Broken Access Control (split in 2007 T10)||14|
|<removed in 2007>||A1 - Unvalidated Input||7|
|<removed in 2007>||A5 - Buffer Overflows||4, 8, and 10|
|<removed in 2007>||A9 - Denial of Service||17|
|<removed in 2007>||A10 - Insecure Configuration Management||29|