Difference between revisions of "OWASP Common Numbering Project"
|Line 1:||Line 1:|
== Introduction ==
== Introduction ==
is the generally agreed-upon new numbering scheme.
Questions/Comments? Email [mailto:email@example.com Mike] or [mailto:firstname.lastname@example.org Brad].
Revision as of 12:04, 23 January 2010
An exciting development, a new numbering scheme that will be common across OWASP Guides and References has been developed. The numbering is based on the OWASP ASVS section and detailed requirement numbering. The effort to develop the numbering was a team effort, led by Mike Boberski (ASVS project lead and co-author). OWASP Top Ten, Guide, and Reference project leads and contributors as well as the OWASP leadership worked together to develop numbering that would allow for easy mapping between OWASP Guides and References, and that would allow for a period of transition as Guides and References are updated to reflect the new numbering. For more information about the new numbering, please see http://www.owasp.org/index.php?title=Common_OWASP_Numbering A new OWASP project is in the process of being created to manage the new numbering scheme, for example as numbers are retired. The new project will be led by Brad Causey.
Below is the generally agreed-upon new numbering scheme.
OWASP-0600 OWASP-0600-DEPRECATED OWASP-0604 OWASP-0604-DEPRECATED OWASP-0604-DG OWASP-0604-DG-01 OWASP-0604-TG OWASP-0604-TG-DV-005 OWASP-0604-TG-DV-005-DEPRECATED
0123456789012345678901234567890123456789 1 2 3
- 0-4 OWASP
- 6-7 Detailed requirement identifier (major)
- 8-9 Detailed requirement identifier (minor)
- 11-12 Document code (DG=Development Guide, TG=Testing Guide, CG=Code Review Guide, AR, ED, RM, OR, others reserved)
- 14-40 (Optional: DEPRECATED, or # for iterations, or legacy identifiers)
Mapping to Legacy Testing Guide IDs
|OWASP-IG-001||Spiders, Robots and Crawlers||OWASP-<put mapped ASVS 4 digit # here>-TG-IG-001|
|OWASP-IG-002||Search Engine Discovery/Reconnaissance|
|OWASP-IG-003||Identify application entry points|
|OWASP-IG-004||Testing for Web Application Fingerprint|
|OWASP-IG-006||Analysis of Error Codes|
|Configuration Management Testing|
|OWASP-CM-001||SSL/TLS Testing (SSL Version, Algorithms, Key length, Digital Cert. Validity)|
|OWASP-CM-002||DB Listener Testing|
|OWASP-CM-003||Infrastructure Configuration Management Testing|
|OWASP-CM-004||Application Configuration Management Testing|
|OWASP-CM-005||Testing for File Extensions Handling|
|OWASP-CM-006||Old, backup and unreferenced files|
|OWASP-CM-007||Infrastructure and Application Admin Interfaces|
|OWASP-CM-008||Testing for HTTP Methods and XST|
|OWASP-AT-001||Credentials transport over an encrypted channel|
|OWASP-AT-002||Testing for user enumeration|
|OWASP-AT-003||Testing for Guessable (Dictionary) User Account|
|OWASP-AT-004||Brute Force Testing|
|OWASP-AT-005||Testing for bypassing authentication schema|
|OWASP-AT-006||Testing for vulnerable remember password and pwd reset|
|OWASP-AT-007||Testing for Logout and Browser Cache Management|
|OWASP-AT-008||Testing for CAPTCHA|
|OWASP-AT-009||Testing Multiple Factors Authentication|
|OWASP-AT-010||Testing for Race Conditions|
|OWASP-SM-001||Testing for Session Management Schema|
|OWASP-SM-002||Testing for Cookies attributes|
|OWASP-SM-003||Testing for Session Fixation|
|OWASP-SM-004||Testing for Exposed Session Variables|
|OWASP-SM-005||Testing for CSRF|
|OWASP-AZ-001||Testing for Path Traversal|
|OWASP-AZ-002||Testing for bypassing authorization schema|
|OWASP-AZ-003||Testing for Privilege Escalation|
|Business logic testing|
|OWASP-BL-001||Testing for business logic|
|Data Validation Testing|
|OWASP-DV-001||Testing for Reflected Cross Site Scripting|
|OWASP-DV-002||Testing for Stored Cross Site Scripting|
|OWASP-DV-003||Testing for DOM based Cross Site Scripting|
|OWASP-DV-004||Testing for Cross Site Flashing|
|OWASP-DV-015||Incubated vulnerability Testing|
|OWASP-DV-016||Testing for HTTP Splitting/Smuggling|
|Denial of Service Testing|
|OWASP-DS-001||Testing for SQL Wildcard Attacks|
|OWASP-DS-002||Locking Customer Accounts|
|OWASP-DS-003||Testing for DoS Buffer Overflows|
|OWASP-DS-004||User Specified Object Allocation|
|OWASP-DS-005||User Input as a Loop Counter|
|OWASP-DS-006||Writing User Provided Data to Disk|
|OWASP-DS-007||Failure to Release Resources|
|OWASP-DS-008||Storing too Much Data in Session|
|Web Services Testing|
|OWASP-WS-001||WS Information Gathering|
|OWASP-WS-003||XML Structural Testing|
|OWASP-WS-004||XML content-level Testing|
|OWASP-WS-005||HTTP GET parameters/REST Testing|
|OWASP-WS-006||Naughty SOAP attachments|
Mapping to Top 10 2010 IDs
<check that all of these are mapped to ASVS identifiers, not TG>
|A2||Cross Site Scripting|| OWASP-0701
|A3||Broken Authentication and Session Management|| OWASP-0300
|A4||Insecure Direct Object References||OWASP-0502|
|A5||Cross Site Request Forgery||OWASP-0405|
|A6||Security Misconfiguration|| OWASP-0203
|A7||Failure to Restrict URL Access||OWASP-0500|
|A8||Unvalidated Redirects and Forwards||OWASP-0717|
|A9||Insecure Cryptographic Storage||OWASP-0209|
|A10||Insufficient Transport Layer Protection||OWASP-0201|
- adding the (release) year into the numbering scheme can be problematic, because the document has a life cycle that goes over years ....
- One should rather try to accommodate a versioning scheme that is human readable in the reference number as well (e.g. V02, or RevA, or...)
- don't try to encode any information into the ID that is likely to change or be subject to debate. In the olden days of CVE, we used to have "CAN-1999-0067" which would change into "CVE-1999-0067" once the item was considered stable and sufficiently verified. That made the ID hard to use. Right now, OWASP-DV-001 encodes the term "data validation" in the DV acronym, but what happens if in a couple of years, some new and better term occurs, or the focus changes from validation to something else? (As an example, it's only recently that the "data validation" term itself has become popular.)
- carefully consider the range of values that your ID space supports, and if possible, allow it to expand. CVE has a "CVE-10K" problem because we never expected that we would ever come close to tracking 10,000 vulnerabilities a year. Red Hat had to change their advisory numbering scheme a couple years ago. etc.
- don't change the fundamental meaning of the ID once you've assigned it. This causes confusion, and more importantly, it immediately invalidates almost everyone's mappings to that ID - including people who you don't even know are using that ID.
- closely monitor the mappings that get made. Typos and misunderstandings are rarely caught. People may make assumptions about what "the item" really is, based only on a quick scan of a short name or title. Since you're dealing with diverse sources, there are likely to be many-to-many relationships in dealing with mappings.
- determine some kind of procedure for handling duplicates. They're gonna happen.
- the more you distribute the process of creating and assigning IDs between multiple people, the more inconsistencies and duplicates you will wind up with. This may be unavoidable, since the job is usually bigger than one person.
- determine some kind of procedure for deprecating IDs, i.e., "retiring" them and discouraging their use by others. This will probably happen for reasons other than duplicates. There should be some final record, somewhere, of what happened to the deprecated item - i.e., it shouldn't just disappear off the face of the earth.
Much of the discussion surrounding the establishment of "Common OWASP Numbering" can be found on the various OWASP mailing lists. (For your convenience here is a direct link to the OWASP Testing Guide Mailing List Archive.)