OWASP - User contributions [en]

CWE ESAPI

2008-12-11T20:06:32Z

SteveChristey: /* Gap Analysis */

== ESAPI control coverage of CWEs ==

This page covers the relationships between ESAPI controls and the [http://cwe.mitre.org/ CWE] entries that are eliminated or reduced by the application of those controls.

* Validation
** [http://cwe.mitre.org/data/definitions/20.html CWE-20]: Insufficient Input Validation
** [http://cwe.mitre.org/data/definitions/116.html CWE-116]: Insufficient Output Sanitization
** [http://cwe.mitre.org/data/definitions/228.html CWE-228]: Failure to Handle Syntactically Invalid Structure

* Canonicalization
** [http://cwe.mitre.org/data/definitions/22.html CWE-22]: Path Traversal
** [http://cwe.mitre.org/data/definitions/41.html CWE-41]: Failure to Resolve Path Equivalence
** [http://cwe.mitre.org/data/definitions/178.html CWE-178]: Failure to Resolve Case Sensitivity

* Encoding
** [http://cwe.mitre.org/data/definitions/113.html CWE-113]: Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting')
** [http://cwe.mitre.org/data/definitions/79.html CWE-79]: Failure to Sanitize Directives in a Web Page (aka 'Cross-site scripting' (XSS))
** [http://cwe.mitre.org/data/definitions/89.html CWE-89]: Failure to Sanitize Data within SQL Queries (aka 'SQL Injection')

* Authentication
** [http://cwe.mitre.org/data/definitions/287.html CWE-287]: Insufficient Authentication

* Session Management
** [http://cwe.mitre.org/data/definitions/488.html CWE-488]: Data Leak Between Sessions
** [http://cwe.mitre.org/data/definitions/613.html CWE-613]: Insufficient Session Expiration
** [http://cwe.mitre.org/data/definitions/384.html CWE-384]: Session Fixation
** [http://cwe.mitre.org/data/definitions/614.html CWE-614]: Sensitive Cookie in HTTPS Session Without "Secure" Attribute
** [http://cwe.mitre.org/data/definitions/352.html CWE-352]: Cross-Site Request Forgery (CSRF)

* Access Control
** [http://cwe.mitre.org/data/definitions/639.html CWE-639]: Access Control Bypass Through User-Controlled Key
** [http://cwe.mitre.org/data/definitions/285.html CWE-285]: Missing or Inconsistent Access Control
** [http://cwe.mitre.org/data/definitions/647.html CWE-647]: Use of Non-Canonical URL Paths for Authorization Decisions

* Encryption
** [http://cwe.mitre.org/data/definitions/311.html CWE-311]: Failure to Encrypt Sensitive Data
** [http://cwe.mitre.org/data/definitions/649.html CWE-649]: Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking
** [http://cwe.mitre.org/data/definitions/323.html CWE-323]: Reusing a Nonce, Key Pair in Encryption
** [http://cwe.mitre.org/data/definitions/327.html CWE-327]: Use of a Broken or Risky Cryptographic Algorithm

* Randomizer
** [http://cwe.mitre.org/data/definitions/330.html CWE-330]: Use of Insufficiently Random Values

* Error Handling
** [http://cwe.mitre.org/data/definitions/209.html CWE-209]: Error Message Information Leaks
** [http://cwe.mitre.org/data/definitions/392.html CWE-392]: Failure to Report Error in Status Code

* Logging
** [http://cwe.mitre.org/data/definitions/222.html CWE-222]: Truncation of Security-relevant Information
** [http://cwe.mitre.org/data/definitions/117.html CWE-117]: Incorrect Output Sanitization for Logs
** [http://cwe.mitre.org/data/definitions/532.html CWE-532]: Information Leak Through Log Files

* Intrusion Detection

* HTTP Protection

* Utilities

* Filters

== Considerations for the Mapping ==

The mapping is notional; it is not complete.

Just because a feature is mapped to a CWE, does not mean that the feature covers all child nodes of that CWE.

It would be useful to map individual API names, not just features.

== Gap Analysis ==

The CWE team has a capability for providing a "coverage graph" that highlights the location of a subset of CWEs within the context of an entire CWE hierarchy. This could be used to conduct a gap analysis to see which CWEs are not addressed by ESAPI, which would be useful to ESAPI consumers as well as identifying possible future requirements for ESAPI itself. See the graphical depictions of the [http://cwe.mitre.org/data/pdfs.html CWE OWASP Top Ten views] for examples.

== Method ==

Only CWE identifiers associated with weaknesses were reviewed. (Some CWE entries are arbitrary categories that organize weaknesses instead of being weaknesses themselves).
Only the most abstract CWE identifiers were mapped, implying that lower-level variants are also covered (based on the hierarchy imposed by CWE-1000, the research view, which has a different hierarchical structure than CWE-699, the developer view).

As of December 2008, there are two different approaches for conducting mappings: "literal" in which you only map to a CWE if it is specifically mentioned or addressed, and "implied" in which you map to a CWE if it is associated with general concepts. For example, the API functions for output encoding can imply some protection against SQL injection, XSS, and others.
The initial CWE/ESAPI mapping was implied.

CWE ESAPI

2008-12-11T20:05:14Z

SteveChristey: /* Method */

== CWE and ESAPI ==

This page covers the relationships between ESAPI controls and the CWE entries that are eliminated or reduced by the application of those controls.

* Validation
** CWE-20: Insufficient Input Validation
** CWE-116: Insufficient Output Sanitization
** CWE-228: Failure to Handle Syntactically Invalid Structure

* Canonicalization
** CWE-22: Path Traversal
** CWE-41: Failure to Resolve Path Equivalence
** CWE-178: Failure to Resolve Case Sensitivity

* Encoding
** CWE-113: Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting')
** CWE-79: Failure to Sanitize Directives in a Web Page (aka 'Cross-site scripting' (XSS))
** CWE-89: Failure to Sanitize Data within SQL Queries (aka 'SQL Injection')

* Authentication
** CWE-287: Insufficient Authentication

* Session Management
** CWE-488: Data Leak Between Sessions
** CWE-613: Insufficient Session Expiration
** CWE-384: Session Fixation
** CWE-614: Sensitive Cookie in HTTPS Session Without "Secure" Attribute
** CWE-352: Cross-Site Request Forgery (CSRF)

* Access Control
** CWE-639: Access Control Bypass Through User-Controlled Key
** CWE-285: Missing or Inconsistent Access Control
** CWE-647: Use of Non-Canonical URL Paths for Authorization Decisions

* Encryption
** CWE-311: Failure to Encrypt Sensitive Data
** CWE-649: Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking
** CWE-323: Reusing a Nonce, Key Pair in Encryption
** CWE-327: Use of a Broken or Risky Cryptographic Algorithm

* Randomizer
** CWE-330: Use of Insufficiently Random Values

* Error Handling
** CWE-209: Error Message Information Leaks
** CWE-392: Failure to Report Error in Status Code

* Logging
** CWE-222: Truncation of Security-relevant Information
** CWE-117: Incorrect Output Sanitization for Logs
** CWE-532: Information Leak Through Log Files

* Intrusion Detection

* HTTP Protection

* Utilities

* Filters

== Considerations for the Mapping ==

The mapping is notional; it is not complete.

Just because a feature is mapped to a CWE, does not mean that the feature covers all child nodes of that CWE.

It would be useful to map individual API names, not just features.

== Gap Analysis ==

The CWE team has a capability for providing a "coverage graph" that highlights the location of a subset of CWEs within the context of an entire CWE hierarchy. This could be used to conduct a gap analysis to see which CWEs are not addressed by ESAPI, which would be useful to ESAPI consumers as well as identifying possible future requirements for ESAPI itself. See the graphical depictions of the [http://cwe.mitre.org/data/pdfs.html | CWE OWASP views] for examples.

== Method ==

Only CWE identifiers associated with weaknesses were reviewed. (Some CWE entries are arbitrary categories that organize weaknesses instead of being weaknesses themselves).
Only the most abstract CWE identifiers were mapped, implying that lower-level variants are also covered (based on the hierarchy imposed by CWE-1000, the research view, which has a different hierarchical structure than CWE-699, the developer view).

As of December 2008, there are two different approaches for conducting mappings: "literal" in which you only map to a CWE if it is specifically mentioned or addressed, and "implied" in which you map to a CWE if it is associated with general concepts. For example, the API functions for output encoding can imply some protection against SQL injection, XSS, and others.
The initial CWE/ESAPI mapping was implied.

CWE ESAPI

2008-12-11T19:59:22Z

SteveChristey: /* Considerations for the Mapping */

== CWE and ESAPI ==

This page covers the relationships between ESAPI controls and the CWE entries that are eliminated or reduced by the application of those controls.

* Validation
** CWE-20: Insufficient Input Validation
** CWE-116: Insufficient Output Sanitization
** CWE-228: Failure to Handle Syntactically Invalid Structure

* Canonicalization
** CWE-22: Path Traversal
** CWE-41: Failure to Resolve Path Equivalence
** CWE-178: Failure to Resolve Case Sensitivity

* Encoding
** CWE-113: Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting')
** CWE-79: Failure to Sanitize Directives in a Web Page (aka 'Cross-site scripting' (XSS))
** CWE-89: Failure to Sanitize Data within SQL Queries (aka 'SQL Injection')

* Authentication
** CWE-287: Insufficient Authentication

* Session Management
** CWE-488: Data Leak Between Sessions
** CWE-613: Insufficient Session Expiration
** CWE-384: Session Fixation
** CWE-614: Sensitive Cookie in HTTPS Session Without "Secure" Attribute
** CWE-352: Cross-Site Request Forgery (CSRF)

* Access Control
** CWE-639: Access Control Bypass Through User-Controlled Key
** CWE-285: Missing or Inconsistent Access Control
** CWE-647: Use of Non-Canonical URL Paths for Authorization Decisions

* Encryption
** CWE-311: Failure to Encrypt Sensitive Data
** CWE-649: Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking
** CWE-323: Reusing a Nonce, Key Pair in Encryption
** CWE-327: Use of a Broken or Risky Cryptographic Algorithm

* Randomizer
** CWE-330: Use of Insufficiently Random Values

* Error Handling
** CWE-209: Error Message Information Leaks
** CWE-392: Failure to Report Error in Status Code

* Logging
** CWE-222: Truncation of Security-relevant Information
** CWE-117: Incorrect Output Sanitization for Logs
** CWE-532: Information Leak Through Log Files

* Intrusion Detection

* HTTP Protection

* Utilities

* Filters

== Considerations for the Mapping ==

The mapping is notional; it is not complete.

Just because a feature is mapped to a CWE, does not mean that the feature covers all child nodes of that CWE.

It would be useful to map individual API names, not just features.

== Gap Analysis ==

The CWE team has a capability for providing a "coverage graph" that highlights the location of a subset of CWEs within the context of an entire CWE hierarchy. This could be used to conduct a gap analysis to see which CWEs are not addressed by ESAPI, which would be useful to ESAPI consumers as well as identifying possible future requirements for ESAPI itself. See the graphical depictions of the [http://cwe.mitre.org/data/pdfs.html | CWE OWASP views] for examples.

== Method ==

Only CWE identifiers associated with weaknesses were reviewed. (Some CWE entries are arbitrary groupings that organize weaknesses instead of being weaknesses themselves).
Only the most abstract CWE identifiers were mapped, implying that lower-level variants are also covered (based on the hierarchy imposed by CWE-1000, the research view, which has a different hierarchical structure than CWE-699, the developer view).

CWE ESAPI

2008-12-11T19:58:00Z

SteveChristey: /* Considerations for the Mapping */

== CWE and ESAPI ==

This page covers the relationships between ESAPI controls and the CWE entries that are eliminated or reduced by the application of those controls.

* Validation
** CWE-20: Insufficient Input Validation
** CWE-116: Insufficient Output Sanitization
** CWE-228: Failure to Handle Syntactically Invalid Structure

* Canonicalization
** CWE-22: Path Traversal
** CWE-41: Failure to Resolve Path Equivalence
** CWE-178: Failure to Resolve Case Sensitivity

* Encoding
** CWE-113: Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting')
** CWE-79: Failure to Sanitize Directives in a Web Page (aka 'Cross-site scripting' (XSS))
** CWE-89: Failure to Sanitize Data within SQL Queries (aka 'SQL Injection')

* Authentication
** CWE-287: Insufficient Authentication

* Session Management
** CWE-488: Data Leak Between Sessions
** CWE-613: Insufficient Session Expiration
** CWE-384: Session Fixation
** CWE-614: Sensitive Cookie in HTTPS Session Without "Secure" Attribute
** CWE-352: Cross-Site Request Forgery (CSRF)

* Access Control
** CWE-639: Access Control Bypass Through User-Controlled Key
** CWE-285: Missing or Inconsistent Access Control
** CWE-647: Use of Non-Canonical URL Paths for Authorization Decisions

* Encryption
** CWE-311: Failure to Encrypt Sensitive Data
** CWE-649: Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking
** CWE-323: Reusing a Nonce, Key Pair in Encryption
** CWE-327: Use of a Broken or Risky Cryptographic Algorithm

* Randomizer
** CWE-330: Use of Insufficiently Random Values

* Error Handling
** CWE-209: Error Message Information Leaks
** CWE-392: Failure to Report Error in Status Code

* Logging
** CWE-222: Truncation of Security-relevant Information
** CWE-117: Incorrect Output Sanitization for Logs
** CWE-532: Information Leak Through Log Files

* Intrusion Detection

* HTTP Protection

* Utilities

* Filters

== Considerations for the Mapping ==

Just because a feature is mapped to a CWE, does not mean that the feature covers all child nodes of that CWE.

It would be useful to map individual API names, not just features.

== Gap Analysis ==

The CWE team has a capability for providing a "coverage graph" that highlights the location of a subset of CWEs within the context of an entire CWE hierarchy. This could be used to conduct a gap analysis to see which CWEs are not addressed by ESAPI, which would be useful to ESAPI consumers as well as identifying possible future requirements for ESAPI itself. See the graphical depictions of the [http://cwe.mitre.org/data/pdfs.html | CWE OWASP views] for examples.

== Method ==

Only CWE identifiers associated with weaknesses were reviewed. (Some CWE entries are arbitrary groupings that organize weaknesses instead of being weaknesses themselves).
Only the most abstract CWE identifiers were mapped, implying that lower-level variants are also covered (based on the hierarchy imposed by CWE-1000, the research view, which has a different hierarchical structure than CWE-699, the developer view).

CWE ESAPI

2008-12-11T19:54:35Z

SteveChristey: /* CWE and ESAPI */

== CWE and ESAPI ==

This page covers the relationships between ESAPI controls and the CWE entries that are eliminated or reduced by the application of those controls.

* Validation

** CWE-20: Insufficient Input Validation

** CWE-116: Insufficient Output Sanitization

** CWE-228: Failure to Handle Syntactically Invalid Structure

* Canonicalization

** CWE-22: Path Traversal

** CWE-41: Failure to Resolve Path Equivalence

** CWE-178: Failure to Resolve Case Sensitivity

* Encoding

** CWE-113: Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting')

** CWE-79: Failure to Sanitize Directives in a Web Page (aka 'Cross-site scripting' (XSS))

** CWE-89: Failure to Sanitize Data within SQL Queries (aka 'SQL Injection')

* Authentication

** CWE-287: Insufficient Authentication

* Session Management

** CWE-488: Data Leak Between Sessions

** CWE-613: Insufficient Session Expiration

** CWE-384: Session Fixation

** CWE-614: Sensitive Cookie in HTTPS Session Without "Secure" Attribute

** CWE-352: Cross-Site Request Forgery (CSRF)

* Access Control

** CWE-639: Access Control Bypass Through User-Controlled Key

** CWE-285: Missing or Inconsistent Access Control

** CWE-647: Use of Non-Canonical URL Paths for Authorization Decisions

* Encryption

** CWE-311: Failure to Encrypt Sensitive Data

** CWE-649: Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking

** CWE-323: Reusing a Nonce, Key Pair in Encryption

** CWE-327: Use of a Broken or Risky Cryptographic Algorithm

* Randomizer

** CWE-330: Use of Insufficiently Random Values

* Error Handling

** CWE-209: Error Message Information Leaks

** CWE-392: Failure to Report Error in Status Code

* Logging

** CWE-222: Truncation of Security-relevant Information

** CWE-117: Incorrect Output Sanitization for Logs

** CWE-532: Information Leak Through Log Files

* Intrusion Detection

* HTTP Protection

* Utilities

* Filters

== Considerations for the Mapping ==

Just because a feature is mapped to a CWE, does not mean that the feature covers all child nodes of that CWE.

It would be useful to map individual API names, not just features.

The CWE team has a capability for providing a "coverage graph" that highlights the location of a subset of CWEs within the context of an entire CWE hierarchy. This could be used to conduct a gap analysis to see which CWEs are not addressed by ESAPI, which would be useful to ESAPI consumers as well as identifying possible future requirements for ESAPI itself.

== Method ==

Only CWE identifiers associated with weaknesses were reviewed. (Some CWE entries are arbitrary groupings that organize weaknesses instead of being weaknesses themselves).
Only the most abstract CWE identifiers were mapped, implying that lower-level variants are also covered (based on the hierarchy imposed by CWE-1000, the research view, which has a different hierarchical structure than CWE-699, the developer view).

CWE ESAPI

2008-12-11T19:45:09Z

SteveChristey: /* CWE and ESAPI */

CWE ESAPI

2008-12-11T19:30:28Z

SteveChristey: /* CWE and ESAPI */

CWE ESAPI

2008-12-11T19:26:29Z

SteveChristey: /* CWE and ESAPI */

CWE ESAPI

2008-12-11T19:16:50Z

SteveChristey: New page: == CWE and ESAPI == This page covers the relationships between ESAPI controls and the CWE entries that are eliminated or reduced by the application of those controls. * Validation * Can...

== CWE and ESAPI ==

This page covers the relationships between ESAPI controls and the CWE entries that are eliminated or reduced by the application of those controls.

* Validation

* Canonicalization

* Encoding

* Authentication

* Session Management

* Access Control

* Encryption

* Randomizer

* Error Handling

* Logging

* Intrusion Detection

* HTTP Protection

* Utilities

* Filters

ESAPI Static Analysis Support

2008-12-11T19:15:58Z

SteveChristey:

There are a number of activities related to static analysis tools and ESAPI.

* Claim: Use of ESAPI 'should' make it easier to analyze applications for security using analysis tools. To facilitate this we should:
** Develop markup for ESAPI for each of the major static analysis tools (open source AND commercial)
*** This will allow the existing rules provided by the tools to be run against the application, while recognizing what ESAPI does, like validate, encode, etc.
*** If a tool can recognize ESAPI-based validation/encoding and other controls, it might help to reduce the number of false positives
*** If there is a [[CWE_ESAPI | mapping]] from CWE names to associated ESAPI controls, then a tool could use its CWE results to suggest which controls to focus on first.
 
* Fact: There are coding rules we would like developers to follow to build secure apps that are not currently being checked for, possibly because developers don't have the capability to do some of these things today. ESAPI is intended to make it far easier for developers to adopt new secure coding practices and we would like to check to make sure they are following these new best practices
** OWASP should develop its own 'rules' on what it thinks applications should do to use ESAPI correctly, which won't currently be represented in existing tool rulesets
** OWASP should also develop its own 'rules' on what it thinks that applications should do to be secure, that don't necessarily depend on the use of ESAPI. These rules would be applicable to all applications, regardless of whether they are using ESAPI or not.
 
We might want to start with something open source like FindBugs and do the above for it first (if it can handle what we want to do), and then encourage the major static analysis tool vendors to implement equivalent API markup and rules for their tool. There is already precedent for publication of rules for commercial tools
(see CERT C Secure Coding standard pack for Fortify and others)

ESAPI Static Analysis Support

2008-12-11T19:13:26Z

SteveChristey:

There are a number of activities related to static analysis tools and ESAPI.

* Claim: Use of ESAPI 'should' make it easier to analyze applications for security using analysis tools. To facilitate this we should:
** Develop markup for ESAPI for each of the major static analysis tools (open source AND commercial)
*** This will allow the existing rules provided by the tools to be run against the application, while recognizing what ESAPI does, like validate, encode, etc.
*** If a tool can recognize ESAPI-based validation/encoding and other controls, it might help to reduce the number of false positives
*** If there is a mapping from CWE names to associated ESAPI controls, then a tool could use its CWE results to suggest which controls to focus on first.
 
* Fact: There are coding rules we would like developers to follow to build secure apps that are not currently being checked for, possibly because developers don't have the capability to do some of these things today. ESAPI is intended to make it far easier for developers to adopt new secure coding practices and we would like to check to make sure they are following these new best practices
** OWASP should develop its own 'rules' on what it thinks applications should do to use ESAPI correctly, which won't currently be represented in existing tool rulesets
** OWASP should also develop its own 'rules' on what it thinks that applications should do to be secure, that don't necessarily depend on the use of ESAPI. These rules would be applicable to all applications, regardless of whether they are using ESAPI or not.
 
We might want to start with something open source like FindBugs and do the above for it first (if it can handle what we want to do), and then encourage the major static analysis tool vendors to implement equivalent API markup and rules for their tool. There is already precedent for publication of rules for commercial tools
(see CERT C Secure Coding standard pack for Fortify and others)

ESAPI Documentation

2008-12-11T19:11:43Z

SteveChristey: /* Documentation Plan */

== Overview ==

This page documents our current thoughts on the various documents we need to produce for the ESAPI project, and the audience, purpose, and high level outline of each document.

== Documentation Plan ==

* Smaller Documents
** ESAPI Executive Overview
Audience: Executives 
Purpose: To provide executives with an understanding of:
* What ESAPI is? Goals.
* Why an ESAPI is necessary. (App Sec is important/why/standardization)
* The benefits of using an ESAPI? (Cost, ROI)
* The current status of ESAPI? (Maturity, Stability, Licensing, Support)
* Who created it, where it came from, credibility, who is using it?
* How to adopt an ESAPI?
Outline: (See Purpose)
** FAQ (For non-users)
Audience: Potential users of ESAPI 
Purpose: To provide 'quick' hit, information about ESAPI 
Topics: Summary of main points in the Executive Overview 
** FAQ (For people using ESAPI)
Audience (Technical people using ESAPI) 
Purpose: To provide 'quick' hit, information about how to use ESAPI, and how to add ESAPI to or integrate ESAPI with your existing security controls.
Outline:
* How to use it the first time
* Performance
 
* Larger Documents
** Getting Started Guide
** How to Secure an Existing Application with ESAPI
** How to Use ESAPI in a New Application
** How to Create a Custom ESAPI for Your Organization
 
* Web pages
** Revamp the ESAPI Website
** How will the ESAPI be updated and released.
** [[CWE_ESAPI]] CWEs addressed by ESAPI - Assigned to Steve Christey
** Features List
 
* Other
** ESAPI Architecture/Design Guideline
** Assurance Argument [[ESAPI_Assurance]]

ESAPI Static Analysis Support

2008-12-11T18:56:55Z

SteveChristey:

There are a number of activities related to static analysis tools and ESAPI.

* Claim: Use of ESAPI 'should' make it easier to analyze applications for security using analysis tools. To facilitate this we should:
** Develop markup for ESAPI for each of the major static analysis tools (open source AND commercial)
*** This will allow the existing rules provided by the tools to be run against the application, while recognizing what ESAPI does, like validate, encode, etc.
*** If a tool can recognize ESAPI-based validation/encoding and other controls, it might help to reduce the number of false positives
 
* Fact: There are coding rules we would like developers to follow to build secure apps that are not currently being checked for, possibly because developers don't have the capability to do some of these things today. ESAPI is intended to make it far easier for developers to adopt new secure coding practices and we would like to check to make sure they are following these new best practices
** OWASP should develop its own 'rules' on what it thinks applications should do to use ESAPI correctly, which won't currently be represented in existing tool rulesets
** OWASP should also develop its own 'rules' on what it thinks that applications should do to be secure, that don't necessarily depend on the use of ESAPI. These rules would be applicable to all applications, regardless of whether they are using ESAPI or not.
 
We might want to start with something open source like FindBugs and do the above for it first (if it can handle what we want to do), and then encourage the major static analysis tool vendors to implement equivalent API markup and rules for their tool. There is already precedent for publication of rules for commercial tools
(see CERT C Secure Coding standard pack for Fortify and others)

ESAPI Assurance

2008-12-11T18:52:38Z

SteveChristey: /* Building an Assurance Case for ESAPI */

== Building an Assurance Case for ESAPI ==

* [https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/assurance/643-BSI.html Arguing Security - Creating Security Assurance Cases]

* summary: make Claims, provide supporting Evidence, and make Arguments for how the evidence supports the claims

* Highest level claim is "The system is Acceptably Secure" but how to break this down into sub-claims that map to the provided evidence? e.g. absence of specific vulns (as investigated by manual testing or tool scans)

* claims could be summarized using a [http://swaconsortium.org/projects/softwareFacts/softwareFacts.html Software Facts Label]

* each language (Java, ASP, etc.) may need separate claims

* list the third-party software

* discuss coding practices that were followed, skill levels of developers, amount of independent review

* publish scanning tool results. "Tool X, using rule set R on date D, was run against ESAPI version Y using configuration Z, and found this set of results with this amount of code coverage."

== Coding Practices ==

* was OWASP Top Ten followed?

* how was performance and security balanced?

* what is the level of training of the developers? amount of experience in web development?

* were tools part of the whole process or run at the end?

* how was code repository prevented from unauthorized alterations?

* practices for code check-in and independent review - how is introduction of Trojans avoided?

* what threat level is being accounted for (e.g. will this only work against script kiddies)? was threat modeling used?

ESAPI Assurance

2008-12-11T18:48:05Z

SteveChristey: /* Building an Assurance Case for ESAPI */

== Building an Assurance Case for ESAPI ==

* [https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/assurance/643-BSI.html Arguing Security - Creating Security Assurance Cases]

* summary: make Claims, provide supporting Evidence, and make Arguments for how the evidence supports the claims

* Highest level claim is "The system is Acceptably Secure" but how to break this down into sub-claims that map to the provided evidence? e.g. absence of specific vulns (as investigated by manual testing or tool scans)

* claims could be summarized using a [http://swaconsortium.org/projects/softwareFacts/softwareFacts.html Software Facts Label]

* each language (Java, ASP, etc.) may need separate claims

* list the third-party software

* discuss coding practices that were followed, skill levels of developers, amount of independent review

* publish scanning tool results

== Coding Practices ==

* was OWASP Top Ten followed?

* how was performance and security balanced?

* what is the level of training of the developers? amount of experience in web development?

* were tools part of the whole process or run at the end?

* how was code repository prevented from unauthorized alterations?

* practices for code check-in and independent review - how is introduction of Trojans avoided?

* what threat level is being accounted for (e.g. will this only work against script kiddies)? was threat modeling used?

ESAPI Summit

2008-12-11T18:46:41Z

SteveChristey: /* Summit Overview */

== Summit Overview ==

The first OWASP ESAPI Summit was held December 9-11, 2008. It was hosted by Aspect Security in their Columbia, MD office.

The following were the attendees of the Summit:

*[[User:Jeff Williams|Jeff Williams]], Aspect Security - [[ESAPI|ESAPI Project Lead]]
*[[User:Wichers|Dave Wichers]], Aspect Security
*Ron Monzillo, Sun Microsystems - [http://java.sun.com/javaee/security/ Java EE Security Architect]
*[[User:Arshan|Arshan Dabirsiaghi]], Aspect Security - [[:Category:Intrinsic_Security_Working_Group|OWASP Intrisic Security Working Group Chair]]
*[[User:Jerryhoff|Jerry Hoff]], Aspect Security
*Mike Fauzy, Aspect Security
*[[User:Kevin.Fealey|Kevin Fealey]], Aspect Security - [[ESAPI Swingset|ESAPI Swingset Lead]]
*[[User"Jmanico|Jim Manico]], Aspect Security - [http://code.google.com/p/owasp-esapi-java/ ESAPI Java Committer]
*Steve Lavenhar, Booz Allen Hamilton
*Lian Jin, Booz Allen Hamilton
*John Steven, Cigital, Technical Director
*Joel Winstead, Cigital
*Alex Smolen, Foundstone - [[.NET ESAPI | ESAPI .NET Lead]]
*Andy Miller, Lockheed Martin
*John Munsch, Lockheed Martin
*Steve Christey, MITRE - [http://cve.mitre.org CVE]/[http://cwe.mitre.org CWE] Project Lead

The following pages contain our thoughts/results from the summit.

Summary: TODO

== Links ==

* [[ESAPI Installation]]
* [[ESAPI Charter]]
* [[ESAPI Adoption Strategy]]
* [[ESAPI Framework Strategy]]
* [[ESAPI Assurance]]
* [[ESAPI Documentation]]
* [[ESAPI Marketing]]
* [[ESAPI Tooling]]
* [[ESAPI Static Analysis Support]]
* [[ESAPI Performance]]
* [[ESAPI Internationalization]]
* [[ESAPI Roadmap]]

== Design ==

* [[ESAPI API]]

== Features ==

* [[ESAPI Validation]]
* [[ESAPI Canonicalization]]
* [[ESAPI Encoding]]
* [[ESAPI Authentication]]
* [[ESAPI Session Management]]
* [[ESAPI Access Control]]
* [[ESAPI Encryption]]
* [[ESAPI Randomizer]]
* [[ESAPI Error Handling]]
* [[ESAPI Logging]]
* [[ESAPI Intrusion Detection]]
* [[ESAPI HTTP Protection]]
* [[ESAPI Utilities]]
* [[ESAPI Filters]]

__NOTOC__
[[Category:OWASP Enterprise Security API]]

ESAPI Assurance

2008-12-11T18:20:43Z

SteveChristey: /* Building an Assurance Case for ESAPI */

== Building an Assurance Case for ESAPI ==

* summary: make Claims, provide supporting Evidence, and make Arguments for how the evidence supports the claims

* Highest level claim is "The system is Acceptably Secure" but how to break this down into sub-claims that map to the provided evidence? e.g. absence of specific vulns (as investigated by manual testing or tool scans)

* [http://swaconsortium.org/projects/softwareFacts/softwareFacts.html Software Facts Label]

* each language (Java, ASP, etc.) may need separate claims

* list the third-party software

* discuss coding practices that were followed, skill levels of developers, amount of independent review

* publish scanning tool results

* links to DHS web sites and documents

* [https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/assurance/643-BSI.html Arguing Security - Creating Security Assurance Cases]

== Coding Practices ==

* was OWASP Top Ten followed?

* how was performance and security balanced?

* what is the level of training of the developers? amount of experience in web development?

* were tools part of the whole process or run at the end?

* how was code repository prevented from unauthorized alterations?

* practices for code check-in and independent review - how is introduction of Trojans avoided?

* what threat level is being accounted for (e.g. will this only work against script kiddies)? was threat modeling used?

ESAPI Assurance

2008-12-11T17:50:33Z

SteveChristey: /* Coding Practices */

== Building an Assurance Case for ESAPI ==

* summary: make Claims, provide supporting Evidence, and make Arguments for how the evidence supports the claims

* Highest level claim is "The system is Acceptably Secure" but how to break this down into sub-claims that map to the provided evidence? e.g. absence of specific vulns (as investigated by manual testing or tool scans)

* "Software Facts Label"
http://swaconsortium.org/projects/softwareFacts/softwareFacts.html

* each language (Java, ASP, etc.) may need separate claims

* list the third-party software

* discuss coding practices that were followed, skill levels of developers, amount of independent review

* publish scanning tool results

* links to DHS web sites and documents

* "Arguing Security - Creating Security Assurance Cases"
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/assurance/643-BSI.html

== Coding Practices ==

* was OWASP Top Ten followed?

* how was performance and security balanced?

* what is the level of training of the developers? amount of experience in web development?

* were tools part of the whole process or run at the end?

* how was code repository prevented from unauthorized alterations?

* practices for code check-in and independent review - how is introduction of Trojans avoided?

* what threat level is being accounted for (e.g. will this only work against script kiddies)? was threat modeling used?

ESAPI Documentation

2008-12-11T16:07:20Z

SteveChristey: /* Documentation Plan */

== Overview ==

TODO

== Documentation Plan ==

* Getting Started Guide

* How to Create a Custom ESAPI for Your Organization

* How to Secure an Existing Application with ESAPI

* How to Use ESAPI in a New Application

* FAQ

* Revamp the ESAPI Website

* ESAPI Executive Overview

* ESAPI Architecture/Design Guideline

* Features List

* Assurance Argument [[ESAPI_Assurance]]

* How will the ESAPI be updated and released.

* CWEs addressed by ESAPI

ESAPI Assurance

2008-12-11T14:52:36Z

SteveChristey: /* Building an Assurance Case for ESAPI */

== Building an Assurance Case for ESAPI ==

* summary: make Claims, provide supporting Evidence, and make Arguments for how the evidence supports the claims

* Highest level claim is "The system is Acceptably Secure" but how to break this down into sub-claims that map to the provided evidence? e.g. absence of specific vulns (as investigated by manual testing or tool scans)

* "Software Facts Label"
http://swaconsortium.org/projects/softwareFacts/softwareFacts.html

* each language (Java, ASP, etc.) may need separate claims

* list the third-party software

* discuss coding practices that were followed, skill levels of developers, amount of independent review

* publish scanning tool results

* links to DHS web sites and documents

* "Arguing Security - Creating Security Assurance Cases"
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/assurance/643-BSI.html

== Coding Practices ==

* was OWASP Top Ten followed?

* how was performance and security balanced?

* what is the level of training of the developers? amount of experience in web development?

* were tools part of the whole process or run at the end?

* how was code repository prevented from unauthorized alterations?

* practices for code check-in and independent review - how is introduction of Trojans avoided?

ESAPI Assurance

2008-12-11T14:50:58Z

SteveChristey: /* Building an Assurance Case for ESAPI */

== Building an Assurance Case for ESAPI ==

* summary: make Claims, provide supporting Evidence, and make Arguments for how the evidence supports the claims

* Highest level claim is "The system is Acceptably Secure" but how to break this down into sub-claims that map to the provided evidence? e.g. absence of specific vulns (as investigated by manual testing or tool scans)

* "Software Facts Label"
http://swaconsortium.org/projects/softwareFacts/softwareFacts.html

* each language (Java, ASP, etc.) may need separate claims

* list the third-party software

* discuss coding practices that were followed, skill levels of developers, amount of independent review

* publish scanning tool results

* links to DHS web sites and documents

* "Arguing Security - Creating Security Assurance Cases"
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/assurance/643-BSI.html

== Coding Practices ==

* was OWASP Top Ten followed?

* how was performance and security balanced?

* what is the level of training of the developers? amount of experience in web development?

* were tools part of the whole process or run at the end?

* how was code repository prevented from unauthorized alterations?

* practices for code check-in and independent review - how is introduction of Trojans avoided?

ESAPI Assurance

2008-12-11T14:49:53Z

SteveChristey: /* Building an Assurance Case for ESAPI */

== Building an Assurance Case for ESAPI ==

* summary: make Claims, provide supporting Evidence, and make Arguments for how the evidence supports the claims

* Highest level claim is "The system is Acceptably Secure" but how to break this down into sub-claims that map to the provided evidence? e.g. absence of specific vulns (as investigated by manual testing or tool scans)

* consider adopting software facts label
http://swaconsortium.org/projects/softwareFacts/softwareFacts.html

* each language (Java, ASP, etc.) may need separate claims

* list the third-party software

* discuss coding practices that were followed, skill levels of developers, amount of independent review

* publish scanning tool results

* links to DHS web sites and documents

* "Arguing Security - Creating Security Assurance Cases"
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/assurance/643-BSI.html

== Coding Practices ==

* was OWASP Top Ten followed?

* how was performance and security balanced?

* what is the level of training of the developers? amount of experience in web development?

* were tools part of the whole process or run at the end?

* how was code repository prevented from unauthorized alterations?

* practices for code check-in and independent review - how is introduction of Trojans avoided?

ESAPI Assurance

2008-12-11T14:42:23Z

SteveChristey: /* Building an Assurance Case for ESAPI */

== Building an Assurance Case for ESAPI ==

* consider adopting software facts label
http://swaconsortium.org/projects/softwareFacts/softwareFacts.html

* identify third-party software

* discuss coding practices that were followed, skill levels of developers, amount of independent review

* publish scanning tool results

* links to DHS web sites and documents

== Coding Practices ==

* was OWASP Top Ten followed?

* how was performance and security balanced?

* what is the level of training of the developers? amount of experience in web development?

* were tools part of the whole process or run at the end?

* how was code repository prevented from unauthorized alterations?

* practices for code check-in and independent review - how is introduction of Trojans avoided?

ESAPI Assurance

2008-12-11T14:36:37Z

SteveChristey: New page: == Building an Assurance Case for ESAPI == * consider adopting software facts label * identify third-party software * discuss coding practices that were followed, skill levels of develo...

== Building an Assurance Case for ESAPI ==

* consider adopting software facts label

* identify third-party software

* discuss coding practices that were followed, skill levels of developers, amount of independent review

* publish scanning tool results

* links to DHS web sites and documents

ESAPI Documentation

2008-12-11T14:33:48Z

SteveChristey: /* Documentation Plan */

ESAPI Documentation

2008-12-11T14:31:38Z

SteveChristey: /* Documentation Plan */

Top 10 2007-Broken Authentication and Session Management

2008-08-26T05:01:16Z

SteveChristey: /* References */ fixed typo in CWE ID - 301, not 311

{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Insecure Cryptographic Storage|useprev=PrevLink|prev=-Information Leakage and Improper Error Handling|usemain=MainLink|main=}}

Proper authentication and session management is critical to web application security. Flaws in this area most frequently involve the failure to protect credentials and session tokens through their lifecycle. These flaws can lead to the hijacking of user or administrative accounts, undermine authorization and accountability controls, and cause privacy violations.

== Environments Affected ==

All web application frameworks are vulnerable to authentication and session management flaws.

== Vulnerability ==

Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such as logout, password management, timeout, remember me, secret question, and account update.

== Verifying Security ==

The goal is to verify that the application properly authenticates users and properly protects identities and their associated credentials.

Automated approaches: Vulnerability scanning tools have a very difficult time detecting vulnerabilities in custom authentication and session management schemes. Static analysis tools are also not likely to detect authentication and session management problems in custom code.

Manual approaches: Code review and testing, especially in combination, are quite effective at verifying that the authentication, session management, and ancillary functions are all implemented properly.

== Protection ==

Authentication relies on secure communication and credential storage. First ensure that SSL is the only option for all authenticated parts of the application (see A9 – Insecure Communications) and that all credentials are stored in hashed or encrypted form (see A8 – Insecure Cryptographic Storage).

Preventing authentication flaws takes careful planning. Among the most important considerations are:

*'''Only use the inbuilt session management mechanism.''' Do not write or use secondary session handlers under any circumstances.
*'''Do not accept new, preset or invalid session identifiers''' from the URL or in the request. This is called a session fixation attack.
*'''Limit or rid your code of custom cookies for authentication or session management '''purposes, such as "remember me" type functionality or home grown single-sign on functionality. This does not apply to robust, well proven SSO or federated authentication solutions.
*'''Use a single authentication mechanism''' with appropriate strength and number of factors. Make sure that this mechanism is not easily subjected to spoofing or replay attacks. Do not make this mechanism overly complex, which then may become subject to its own attack.
*'''Do not allow the login process to start from an unencrypted page.''' Always start the login process from a second, encrypted page with a fresh or new session token to prevent credential or session stealing, phishing attacks and session fixation attacks.
*Consider '''regenerating a new session upon successful authentication''' or privilege level change.
*'''Ensure that every page has a logout link.''' Logout should destroy all server side session state and client side cookies. Consider human factors: do not ask for confirmation as users will end up just closing the tab or window rather than logging out successfully.
*'''Use a timeout period''' that automatically logs out an inactive session as per the value of the data being protected (shorter is always better).
*'''Use only strong ancillary authentication functions''' (questions and answers, password reset) as these are credentials in the same way usernames and passwords or tokens are credentials. Apply a one-One way hash to answers to prevent disclosure attacks.
*'''Do not expose any session identifiers or any portion of valid credentials in URLs or logs (no session rewriting or storing the user’s password in log files)'''
*'''Check the old password when the user changes to a new password'''
*'''Do not rely upon spoofable credentials as the sole form of authentication''', such as IP addresses or address range masks, DNS or reverse DNS lookups, referrer headers or similar''' '''
*'''Be careful of sending secrets to registered e-mail addresses''' (see RSNAKE02 in the references) as a mechanism for password resets. Use limited time only random numbers to reset access and send a follow up e-mail as soon as the password has been reset. Be careful of allowing self-registered users changing their e-mail address - send a message to the previous e-mail address before enacting the change

== Samples ==

*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6229 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6229]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528]

== Related Articles ==
* [[Guide to Authentication]]
* [[Testing for authentication]]
* [[Reviewing Code for Authentication]]

== References ==

*CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials), CWE-301 (Reflection attack in an authentication protocol), others.
*WASC Threat Classification:
** [http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml]
** [http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml]
** [http://www.webappsec.org/projects/threat/classes/session_fixation.shtml http://www.webappsec.org/projects/threat/classes/session_fixation.shtml]
*RSNAKE01 - http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you
*RSNAKE02 - http://ha.ckers.org/blog/20061109/email-as-half-factor-authentication

{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Insecure Cryptographic Storage|useprev=PrevLink|prev=-Information Leakage and Improper Error Handling|usemain=MainLink|main=}}

Top 10 2007-Failure to Restrict URL Access

2008-08-26T04:52:01Z

SteveChristey: /* References */ fixed CWE typo - 425 not 325

{{Top_10_2007:TopTemplate|usenext=NextLink|next=-Where to Go From Here|useprev=PrevLink|prev=-Insecure Cryptographic Storage|usemain=MainLink|main=}}

Frequently, the only protection for a URL is that links to that page are not presented to unauthorized users. However, a motivated, skilled, or just plain lucky attacker may be able to find and access these pages, invoke functions, and view data. Security by obscurity is not sufficient to protect sensitive functions and data in an application. Access control checks must be performed before a request to a sensitive function is granted, which ensures that the user is authorized to access that function.

== Environments Affected ==

All web application frameworks are vulnerable to failure to restrict URL access.

== Vulnerability ==

The primary attack method for this vulnerability is called "forced browsing", which encompasses guessing links and brute force techniques to find unprotected pages. Applications frequently allow access control code to evolve and spread throughout a codebase, resulting in a complex model that is difficult to understand for developers and security specialists alike. This complexity makes it likely that errors will occur and pages will be missed, leaving them exposed.

Some common examples of these flaws include:

*"Hidden" or "special" URLs, rendered only to administrators or privileged users in the presentation layer, but accessible to all users if they know it exists, such as /admin/adduser.php or /approveTransfer.do. This is particularly prevalent with menu code.
*Applications often allow access to "hidden" files, such as static XML or system generated reports, trusting security through obscurity to hide them.
*Code that enforces an access control policy but is out of date or insufficient. For example, imagine /approveTransfer.do was once available to all users, but since SOX controls were brought in, it is only supposed to be available to approvers. A fix might have been to not present it to unauthorized users, but no access control is actually enforced when requesting that page.
*Code that evaluates privileges on the client but not on the server, as in this [http://grutztopia.jingojango.net/2007/01/your-free-macworld-expo-platinum-pass_11.html attack on MacWorld 2007], which approved "Platinum" passes worth $1700 via JavaScript on the browser rather than on the server.

== Verifying Security ==

The goal is to verify that access control is enforced consistently in the presentation layer and the business logic for all URLs in the application.

Automated approaches: Both vulnerability scanners and static analysis tools have difficulty with verifying URL access control, but for different reasons. Vulnerability scanners have difficulty guessing hidden pages and determining which pages should be allowed for each user, while static analysis engines struggle to identify custom access controls in the code and link the presentation layer with the business logic.

Manual approaches: The most efficient and accurate approach is to use a combination of code review and security testing to verify the access control mechanism. If the mechanism is centralized, the verification can be quite efficient. If the mechanism is distributed across an entire codebase, verification can be more time-consuming. If the mechanism is enforced externally, the configuration must be examined and tested.

== Protection ==

Taking the time to plan authorization by creating a matrix to map the roles and functions of the application is a key step in achieving protection against unrestricted URL access. Web applications must enforce access control on every URL and business function. It is not sufficient to put access control into the presentation layer and leave the business logic unprotected. It is also not sufficient to check once during the process to ensure the user is authorized, and then not check again on subsequent steps. Otherwise, an attacker can simply skip the step where authorization is checked, and forge the parameter values necessary to continue on at the next step.

Enabling URL access control takes some careful planning. Among the most important considerations are:

*'''Ensure the access control matrix is part of the business, architecture, and design of the application'''
*'''Ensure that all URLs and business functions are protected by an effective access control mechanism''' that verifies the user’s role and entitlements prior to any processing taking place. Make sure this is done during every step of the way, not just once towards the beginning of any multi-step process
*'''Perform a penetration test '''prior to deployment or code delivery to ensure that the application cannot be misused by a motivated skilled attacker
*'''Pay close attention to include/library files''', especially if they have an executable extension such as .php. Where feasible, they should be kept outside of the web root. They should verify that they are not being directly accessed, e.g. by checking for a constant that can only be created by the library’s caller
*'''Do not''' '''assume that users will be unaware of special or hidden URLs or APIs'''. Always ensure that administrative and high privilege actions are protected
*'''Block access to all file types that your application should never serve'''. Ideally, this filter would follow the "accept known good" approach and only allow file types that you intend to serve, e.g., .html, .pdf, .php. This would then block any attempts to access log files, xml files, etc. that you never intend to serve directly.
*'''Keep up to date with virus protection and patches''' to components such as XML processors, word processors, image processors, etc., which handle user supplied data

== Samples ==

*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0147 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0147]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0131 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0131]
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1227 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1227]

== References ==

*CWE: CWE-425 (Direct Request), CWE-288 (Authentication Bypass by Alternate Path), CWE-285 (Missing or Inconsistent Access Control)
*WASC Threat Classification: [http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml]
*OWASP, [http://www.owasp.org/index.php/Forced_Browsing http://www.owasp.org/index.php/Forced_Browsing]
*OWASP Guide, [http://www.owasp.org/index.php/Guide_to_Authorization http://www.owasp.org/index.php/Guide_to_Authorization]

{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Where to Go From Here|useprev=PrevLink|prev=-Insecure Cryptographic Storage|usemain=MainLink|main=}}

Category:Vulnerability

2006-06-23T17:53:02Z

SteveChristey: /* Examples of vulnerabilities */

This category is for tagging common types of software vulnerabilities.

==What is a vulnerability?==

A vulnerability is a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application. Stakeholders include the application owner, application users, and other entities that rely on the application. The term "vulnerability" is often used very loosely. However, here we need to distinguish [[:Category:Threat|threats]], [[:Category:Attack|attacks]], and [[:Category:Countermeasure|countermeasures]].

Please '''do not post any actual vulnerabilities''' in products, services, or web applications. Those disclosure reports should be posted to bugtraq or full-disclosure mailing lists.

==Examples of vulnerabilities==
* Lack of input validation on user input
* Lack of sufficient logging mechanism
* Fail-open error handling
* Not closing the database connection properly

For a great overview, check out the [[OWASP Top Ten Project]]. You can read about the top vulnerabilities and download a paper that covers them in detail. Many organizations and agencies use the Top Ten as a way of creating awareness about application security.

{{Template:PutInCategory}}

'''NOTE:''' Before you add a vulnerability, please search and make sure there isn't an equivalent one already. You may want to consider creating a redirect if the topic is the same. Every vulnerability article has a defined structure. Please read the details of [[How To Add a Vulnerability]] before creating a new article.

[[Category:Article Type]]