Difference between revisions of "CWE ESAPI"

Latest revision as of 20:06, 11 December 2008

ESAPI control coverage of CWEs

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