OWASP Common Numbering Project

Introduction

Here is the generally agreed-upon new numbering scheme. Additional explanatory text coming soon. Questions/Comments? Email Mike.

OWASP-06
OWASP-06-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

Category	'''''''Ref. Number'''''''	Test Name				New Common Ref.
Information Gathering	OWASP-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-005	Application Discovery
	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
	Authentication Testing	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
	Session Management	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
	Authorization Testing	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-005	SQL Injection
	OWASP-DV-006	LDAP Injection
	OWASP-DV-007	ORM Injection
	OWASP-DV-008	XML Injection
	OWASP-DV-009	SSI Injection
	OWASP-DV-010	XPath Injection
	OWASP-DV-011	IMAP/SMTP Injection
	OWASP-DV-012	Code Injection
	OWASP-DV-013	OS Commanding
	OWASP-DV-014	Buffer overflow
	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-002	Testing WSDL
	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
	OWASP-WS-007	Replay Testing
	AJAX Testing	OWASP-AJ-001	AJAX Vulnerabilities
	OWASP-AJ-002	AJAX Testing

References

• 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.)