Background OWASP Top Ten 2004 Project - Revision history

Vanderaj: Background OWASP Top Ten Project moved to Background OWASP Top Ten 2004 Project: Top 10 2004 Changes

2007-06-05T19:53:53Z

Background OWASP Top Ten Project moved to Background OWASP Top Ten 2004 Project: Top 10 2004 Changes

Scott@duchin.com at 22:54, 29 August 2006

2006-08-29T22:54:29Z

Jeremy Ferragamo at 18:14, 19 May 2006

2006-05-19T18:14:55Z

Jeremy Ferragamo at 18:13, 19 May 2006

2006-05-19T18:13:43Z

New page

==Background==

The challenge of identifying the “top” web application vulnerabilitiesis a virtually impossible task. There is not even widespread agreement on exactlywhat is included in the term “web application security.” Some haveargued that we should focus only on security issues that affect developers writingcustom web application code. Others have argued for a more expansive definitionthat covers the entire application layer, including libraries, server configuration,and application layer protocols. In the hopes of addressing the most seriousrisks facing organizations, we have decided to give a relatively broad interpretationto web application security, while still keeping clear of network and infrastructuresecurity issues.

Another challenge to this effort is that each specific vulnerability is uniqueto a particular organization’s website. There would be little point incalling out specific vulnerabilities in the web applications of individual organizations,especially since they are hopefully fixed soon after a large audience knows oftheir existence. Therefore, we have chosen to focus on the top classes, types,or categories of web application vulnerabilities.

In the first version of this document, we decided to classify a wide range ofweb application problems into meaningful categories. We studied a variety ofvulnerability classification schemes and came up with a set of categories. Factorsthat characterize a good vulnerability category include whether the flaws areclosely related, can be addressed with similar countermeasures, and frequentlyoccur in typical web application architectures. In this version we are introducinga refined scheme. This has been developed with our continued work on the OASISWAS technical committee in which we will be describing a Thesaurus of issuesfrom which security researchers can describe signatures in an XML format.

To choose the top ten from a large list of candidates has its own set of difficulties.There are simply no reliable sources of statistics about web application securityproblems. In the future, we would like to gather statistics about the frequencyof certain flaws in web application code and use those metrics to help prioritizethe top ten. However, for a number of reasons, this sort of measurement is notlikely to occur in the near future.

We recognize that there is no “right” answer for which vulnerabilitycategories should be in the top ten. Each organization will have to think aboutthe risk to their organization based on the likelihood of having one of theseflaws and the specific consequences to their enterprise. In the meantime, weput this list forward as a set of problems that represent a significant amountof risk to a broad array of organizations. The top ten themselves are not inany particular order, as it would be almost impossible to determine which ofthem represents the most aggregate risk.

The OWASP Top Ten project is an ongoing effort to make information about keyweb application security flaws available to a wide audience. We expect to updatethis document annually based on discussion on the OWASP mailing lists and feedbackto topten@owasp.org.

[[Category:OWASP Top Ten Project]]

__NOEDITSECTION__

@@ Line 1: / Line 1: @@
 ==Background==
-The challenge of identifying the “top” web application vulnerabilitiesis a virtually impossible task. There is not even widespread agreement on exactlywhat is included in the term “web application security.” Some haveargued that we should focus only on security issues that affect developers writingcustom web application code. Others have argued for a more expansive definitionthat covers the entire application layer, including libraries, server configuration,and application layer protocols. In the hopes of addressing the most seriousrisks facing organizations, we have decided to give a relatively broad interpretationto web application security, while still keeping clear of network and infrastructure security issues.
+The challenge of identifying the “top” web application vulnerabilities is a virtually impossible task. There is not even widespread agreement on exactly what is included in the term “web application security.” Some have argued that we should focus only on security issues that affect developers writing custom web application code. Others have argued for a more expansive definition that covers the entire application layer, including libraries, server configuration, and application layer protocols. In the hopes of addressing the most serious risks facing organizations, we have decided to give a relatively broad interpretation to web application security, while still keeping clear of network and infrastructure security issues.
-Another challenge to this effort is that each specific vulnerability is uniqueto a particular organization’s website. There would be little point incalling out specific vulnerabilities in the web applications of individual organizations,especially since they are hopefully fixed soon after a large audience knows oftheir existence. Therefore, we have chosen to focus on the top classes, types,or categories of web application vulnerabilities.
+Another challenge to this effort is that each specific vulnerability is unique to a particular organization’s website. There would be little point in calling out specific vulnerabilities in the web applications of individual organizations, especially since they are hopefully fixed soon after a large audience knows of their existence. Therefore, we have chosen to focus on the top classes, types, or categories of web application vulnerabilities.
-In the first version of this document, we decided to classify a wide range ofweb application problems into meaningful categories. We studied a variety ofvulnerability classification schemes and came up with a set of categories. Factorsthat characterize a good vulnerability category include whether the flaws areclosely related, can be addressed with similar countermeasures, and frequentlyoccur in typical web application architectures. In this version we are introducinga refined scheme. This has been developed with our continued work on the OASISWAS technical committee in which we will be describing a Thesaurus of issuesfrom which security researchers can describe signatures in an XML format.
+In the first version of this document, we decided to classify a wide range of web application problems into meaningful categories. We studied a variety of vulnerability classification schemes and came up with a set of categories. Factors that characterize a good vulnerability category include whether the flaws are closely related, can be addressed with similar countermeasures, and frequently occur in typical web application architectures. In this version we are introducing a refined scheme. This has been developed with our continued work on the OASISWAS technical committee in which we will be describing a Thesaurus of issues from which security researchers can describe signatures in an XML format.
-To choose the top ten from a large list of candidates has its own set of difficulties.There are simply no reliable sources of statistics about web application security problems. In the future, we would like to gather statistics about the frequency of certain flaws in web application code and use those metrics to help prioritizethe top ten. However, for a number of reasons, this sort of measurement is notlikely to occur in the near future.
+To choose the top ten from a large list of candidates has its own set of difficulties. There are simply no reliable sources of statistics about web application security problems. In the future, we would like to gather statistics about the frequency of certain flaws in web application code and use those metrics to help prioritize the top ten. However, for a number of reasons, this sort of measurement is not likely to occur in the near future.
-We recognize that there is no “right” answer for which vulnerability categories should be in the top ten. Each organization will have to think aboutthe risk to their organization based on the likelihood of having one of theseflaws and the specific consequences to their enterprise. In the meantime, weput this list forward as a set of problems that represent a significant amountof risk to a broad array of organizations. The top ten themselves are not inany particular order, as it would be almost impossible to determine which ofthem represents the most aggregate risk.
+We recognize that there is no “right” answer for which vulnerability categories should be in the top ten. Each organization will have to think about the risk to their organization based on the likelihood of having one of these flaws and the specific consequences to their enterprise. In the meantime, we put this list forward as a set of problems that represent a significant amount of risk to a broad array of organizations. The top ten themselves are not in any particular order, as it would be almost impossible to determine which of them represents the most aggregate risk.
-The OWASP Top Ten project is an ongoing effort to make information about keyweb application security flaws available to a wide audience. We expect to updatethis document annually based on discussion on the OWASP mailing lists and feedbackto topten@owasp.org.
+The OWASP Top Ten project is an ongoing effort to make information about key web application security flaws available to a wide audience. We expect to update this document annually based on discussion on the OWASP mailing lists and feedbackto topten@owasp.org.
 [[Category:OWASP Top Ten Project]]
 __NOEDITSECTION__

← Older revision	Revision as of 19:53, 5 June 2007
(No difference)