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-1133: Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java (3.2)  
ID

CWE VIEW: Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java

View ID: 1133
Type: Graph
Status: Stable
Downloads: Booklet | CSV | XML
+ Objective
CWE entries in this view (graph) are fully or partially eliminated by following the guidance presented in the online wiki that reflects that current rules and recommendations of the SEI CERT Oracle Coding Standard for Java.
+ Audience
StakeholderDescription
Software DevelopersBy following the SEI CERT Oracle Coding Standard for Java, developers will be able to fully or partially prevent the weaknesses that are identified in this view. In addition, developers can use a CWE coverage graph to determine which weaknesses are not directly addressed by the standard, which will help identify and resolve remaining gaps in training, tool acquisition, or other approaches for reducing weaknesses.
Software CustomersIf a software developer claims to be following the SEI CERT Oracle Secure Coding Standard for Java, then customers can search for the weaknesses in this view in order to formulate independent evidence of that claim.
EducatorsEducators can use this view in multiple ways. For example, if there is a focus on teaching weaknesses, the educator could link them to the relevant Secure Coding Standard.
+ 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:
1133 - Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS) - (1134)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS))
Weaknesses in this category are related to the rules and recommendations in the Input Validation and Data Sanitization (IDS) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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 Encoding or Escaping of Output - (116)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)) > 116 (Improper Encoding or Escaping of Output)
The software prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.Output SanitizationOutput ValidationOutput Encoding
*BaseBase - a weakness that is 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.Incorrect Behavior Order: Validate Before Canonicalize - (180)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)) > 180 (Incorrect Behavior Order: Validate Before Canonicalize)
The software validates input before it is canonicalized, which prevents the software from detecting data that becomes invalid after the canonicalization step.
*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.Authentication Bypass by Alternate Name - (289)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)) > 289 (Authentication Bypass by Alternate Name)
The software performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
*BaseBase - a weakness that is 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 Output Neutralization for Logs - (117)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)) > 117 (Improper Output Neutralization for Logs)
The software does not neutralize or incorrectly neutralizes output that is written to logs.
*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.Improper Neutralization of Line Delimiters - (144)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)) > 144 (Improper Neutralization of Line Delimiters)
The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as line delimiters when they are sent to a downstream component.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Improper Neutralization of Escape, Meta, or Control Sequences - (150)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)) > 150 (Improper Neutralization of Escape, Meta, or Control Sequences)
The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.
*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 Handling of Highly Compressed Data (Data Amplification) - (409)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)) > 409 (Improper Handling of Highly Compressed Data (Data Amplification))
The software does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
*BaseBase - a weakness that is 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)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)) > 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.Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)) > 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.Collapse of Data into Unsafe Value - (182)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1134 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)) > 182 (Collapse of Data into Unsafe Value)
The software filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 01. Declarations and Initialization (DCL) - (1135)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1135 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 01. Declarations and Initialization (DCL))
Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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 Initialization - (665)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1135 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 01. Declarations and Initialization (DCL)) > 665 (Improper Initialization)
The software does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP) - (1136)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1136 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP))
Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1136 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP)) > 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.NULL Pointer Dereference - (476)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1136 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP)) > 476 (NULL Pointer Dereference)
A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.
*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.Use of Wrong Operator in String Comparison - (597)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1136 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP)) > 597 (Use of Wrong Operator in String Comparison)
The product uses the wrong operator when comparing a string, such as using "==" when the equals() method should be used instead.
*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.Comparison of Object References Instead of Object Contents - (595)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1136 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP)) > 595 (Comparison of Object References Instead of Object Contents)
The program compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM) - (1137)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1137 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM))
Weaknesses in this category are related to the rules and recommendations in the Numeric Types and Operations (NUM) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Integer Overflow or Wraparound - (190)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1137 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)) > 190 (Integer Overflow or Wraparound)
The software performs a calculation that can produce an integer overflow or wraparound, when the logic assumes that the resulting value will always be larger than the original value. This can introduce other weaknesses when the calculation is used for resource management or execution control.
*BaseBase - a weakness that is 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.Integer Underflow (Wrap or Wraparound) - (191)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1137 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)) > 191 (Integer Underflow (Wrap or Wraparound))
The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.Integer underflow
*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.Numeric Truncation Error - (197)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1137 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)) > 197 (Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
*BaseBase - a weakness that is 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.Divide By Zero - (369)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1137 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)) > 369 (Divide By Zero)
The product divides a value by zero.
*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)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1137 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)) > 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.
*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 Calculation - (682)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1137 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)) > 682 (Incorrect Calculation)
The software performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 04. Characters and Strings (STR) - (1138)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1138 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 04. Characters and Strings (STR))
Weaknesses in this category are related to the rules and recommendations in the Characters and Strings (STR) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Inappropriate Encoding for Output Context - (838)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1138 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 04. Characters and Strings (STR)) > 838 (Inappropriate Encoding for Output Context)
The software uses or specifies an encoding when generating output to a downstream component, but the specified encoding is not the same as the encoding that is expected by the downstream component.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ) - (1139)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1139 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ))
Weaknesses in this category are related to the rules and recommendations in the Object Orientation (OBJ) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Passing Mutable Objects to an Untrusted Method - (374)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1139 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)) > 374 (Passing Mutable Objects to an Untrusted Method)
The program sends non-cloned mutable data as an argument to a method or function.
*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.Returning a Mutable Object to an Untrusted Caller - (375)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1139 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)) > 375 (Returning a Mutable Object to an Untrusted Caller)
Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.
*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.Comparison of Classes by Name - (486)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1139 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)) > 486 (Comparison of Classes by Name)
The program compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.
*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.Public cloneable() Method Without Final ('Object Hijack') - (491)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1139 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)) > 491 (Public cloneable() Method Without Final ('Object Hijack'))
A class has a cloneable() method that is not declared final, which allows an object to be created without calling the constructor. This can cause the object to be in an unexpected state.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Use of Inner Class Containing Sensitive Data - (492)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1139 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)) > 492 (Use of Inner Class Containing Sensitive Data)
Inner classes are translated into classes that are accessible at package scope and may expose code that the programmer intended to keep private to attackers.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Cloneable Class Containing Sensitive Information - (498)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1139 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)) > 498 (Cloneable Class Containing Sensitive Information)
The code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Public Static Field Not Marked Final - (500)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1139 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)) > 500 (Public Static Field Not Marked Final)
An object contains a public static field that is not marked final, which might allow it to be modified in unexpected ways.
*VariantVariant - a weakness that is 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)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1139 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)) > 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET) - (1140)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1140 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET))
Weaknesses in this category are related to the rules and recommendations in the Methods (MET) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Reachable Assertion - (617)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1140 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)) > 617 (Reachable Assertion)
The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
*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.Call to Non-ubiquitous API - (589)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1140 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)) > 589 (Call to Non-ubiquitous API)
The software uses an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.
*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 Comparison - (697)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1140 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)) > 697 (Incorrect Comparison)
The software compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.
*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.Object Model Violation: Just One of Equals and Hashcode Defined - (581)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1140 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)) > 581 (Object Model Violation: Just One of Equals and Hashcode Defined)
The software does not maintain equal hashcodes for equal objects.
*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 Following of Specification by Caller - (573)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1140 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)) > 573 (Improper Following of Specification by Caller)
The software does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.
*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.Explicit Call to Finalize() - (586)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1140 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)) > 586 (Explicit Call to Finalize())
The software makes an explicit call to the finalize() method from outside the finalizer.
*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.finalize() Method Declared Public - (583)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1140 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)) > 583 (finalize() Method Declared Public)
The program violates secure coding principles for mobile code by declaring a finalize() method public.
*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.finalize() Method Without super.finalize() - (568)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1140 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)) > 568 (finalize() Method Without super.finalize())
The software contains a finalize() method that does not call super.finalize().
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR) - (1141)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1141 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR))
Weaknesses in this category are related to the rules and recommendations in the Exceptional Behavior (ERR) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Improper Cleanup on Thrown Exception - (460)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1141 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)) > 460 (Improper Cleanup on Thrown Exception)
The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
*BaseBase - a weakness that is 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.Return Inside Finally Block - (584)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1141 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)) > 584 (Return Inside Finally Block)
The code has a return statement inside a finally block, which will cause any thrown exception in the try block to be discarded.
*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.Incomplete Cleanup - (459)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1141 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)) > 459 (Incomplete Cleanup)
The software does not properly "clean up" and remove temporary or supporting resources after they have been used.Insufficient Cleanup
*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.Uncaught Exception - (248)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1141 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)) > 248 (Uncaught Exception)
An exception is thrown from a function, but it is not caught.
*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 Control Flow Scoping - (705)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1141 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)) > 705 (Incorrect Control Flow Scoping)
The software does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
*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 Check for Unusual or Exceptional Conditions - (754)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1141 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)) > 754 (Improper Check for Unusual or Exceptional Conditions)
The software does not check or improperly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation 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 Check or Handling of Exceptional Conditions - (703)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1141 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)) > 703 (Improper Check or Handling of Exceptional Conditions)
The software does not properly anticipate or handle exceptional conditions that rarely occur during normal operation 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.Declaration of Throws for Generic Exception - (397)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1141 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)) > 397 (Declaration of Throws for Generic Exception)
Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
*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.J2EE Bad Practices: Use of System.exit() - (382)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1141 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)) > 382 (J2EE Bad Practices: Use of System.exit())
A J2EE application uses System.exit(), which also shuts down its container.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA) - (1142)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1142 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA))
Weaknesses in this category are related to the rules and recommendations in the Visibility and Atomicity (VNA) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1142 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
*BaseBase - a weakness that is 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.Race Condition within a Thread - (366)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1142 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)) > 366 (Race Condition within a Thread)
If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.
*BaseBase - a weakness that is 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 Resource Locking - (413)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1142 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)) > 413 (Improper Resource Locking)
The software does not lock or does not correctly lock a resource when the software must have exclusive access to the 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.Unsynchronized Access to Shared Data in a Multithreaded Context - (567)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1142 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)) > 567 (Unsynchronized Access to Shared Data in a Multithreaded Context)
The product does not properly synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes.
*BaseBase - a weakness that is 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 Synchronization - (662)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1142 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)) > 662 (Improper Synchronization)
The software attempts to use a shared resource in an exclusive manner, but does not prevent or incorrectly prevents use of the resource by another thread or process.
*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)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1142 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)) > 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.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK) - (1143)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1143 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK))
Weaknesses in this category are related to the rules and recommendations in the Locking (LCK) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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 Externally Accessible Lock - (412)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1143 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK)) > 412 (Unrestricted Externally Accessible Lock)
The software properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control.
*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.Double-Checked Locking - (609)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1143 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK)) > 609 (Double-Checked Locking)
The program uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.
*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)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1143 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK)) > 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.Missing Synchronization - (820)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1143 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK)) > 820 (Missing Synchronization)
The software utilizes a shared resource in a concurrent manner but does not attempt to synchronize access to the resource.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 10. Thread APIs (THI) - (1144)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1144 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 10. Thread APIs (THI))
Weaknesses in this category are related to the rules and recommendations in the Thread APIs (THI) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Call to Thread run() instead of start() - (572)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1144 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 10. Thread APIs (THI)) > 572 (Call to Thread run() instead of start())
The program calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS) - (1145)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1145 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS))
Weaknesses in this category are related to the rules and recommendations in the Thread Pools (TPS) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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 Report of Error Condition - (392)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1145 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)) > 392 (Missing Report of Error Condition)
The software encounters an error but does not provide a status code or return value to indicate that an error has occurred.
*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.Asymmetric Resource Consumption (Amplification) - (405)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1145 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)) > 405 (Asymmetric Resource Consumption (Amplification))
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
*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.Insufficient Resource Pool - (410)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1145 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)) > 410 (Insufficient Resource Pool)
The software's resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources.
*CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 12. Thread-Safety Miscellaneous (TSM) - (1146)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1146 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 12. Thread-Safety Miscellaneous (TSM))
Weaknesses in this category are related to the rules and recommendations in the Thread-Safety Miscellaneous (TSM) section of the SEI CERT Oracle Secure Coding Standard for Java.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO) - (1147)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO))
Weaknesses in this category are related to the rules and recommendations in the Input Output (FIO) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Improper Handling of Windows Device Names - (67)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 67 (Improper Handling of Windows Device Names)
The software constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.
*CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.Cleansing, Canonicalization, and Comparison Errors - (171)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 171 (Cleansing, Canonicalization, and Comparison Errors)
Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform neutralization for untrusted 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.Use of Incorrect Byte Ordering - (198)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 198 (Use of Incorrect Byte Ordering)
The software receives input from an upstream component, but it does not account for byte ordering (e.g. big-endian and little-endian) when processing the input, causing an incorrect number or value to be used.
*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.Incorrect Default Permissions - (276)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 276 (Incorrect Default Permissions)
The software, upon installation, sets incorrect permissions for an object that exposes it to an unintended actor.
*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.Incorrect Execution-Assigned Permissions - (279)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 279 (Incorrect Execution-Assigned Permissions)
While it is executing, the software sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
*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.Exposure of Private Information ('Privacy Violation') - (359)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 359 (Exposure of Private Information ('Privacy Violation'))
The software does not properly prevent private data (such as credit card numbers) from being accessed by actors who either (1) are not explicitly authorized to access the data or (2) do not have the implicit consent of the people to which the data is related.Privacy leakPrivacy leakage
*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.Insecure Temporary File - (377)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 377 (Insecure Temporary File)
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
*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 Resource Shutdown or Release - (404)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 404 (Improper Resource Shutdown or Release)
The program does not release or incorrectly releases a resource before it is made available for re-use.
*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.Asymmetric Resource Consumption (Amplification) - (405)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 405 (Asymmetric Resource Consumption (Amplification))
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
*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.Incomplete Cleanup - (459)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 459 (Incomplete Cleanup)
The software does not properly "clean up" and remove temporary or supporting resources after they have been used.Insufficient Cleanup
*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.Information Exposure Through Log Files - (532)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 532 (Information Exposure Through Log Files)
Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Use of Non-Canonical URL Paths for Authorization Decisions - (647)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 647 (Use of Non-Canonical URL Paths for Authorization Decisions)
The software defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.
*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 Control Flow Scoping - (705)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 705 (Incorrect Control Flow Scoping)
The software does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
*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 Permission Assignment for Critical Resource - (732)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
*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.Allocation of Resources Without Limits or Throttling - (770)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1147 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)) > 770 (Allocation of Resources Without Limits or Throttling)
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER) - (1148)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1148 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER))
Weaknesses in this category are related to the rules and recommendations in the Serialization (SER) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Cleartext Transmission of Sensitive Information - (319)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1148 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)) > 319 (Cleartext Transmission of Sensitive Information)
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
*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.Uncontrolled Resource Consumption - (400)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1148 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)) > 400 (Uncontrolled Resource Consumption)
The software does not properly control the allocation and maintence of a limited resource thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.Resource Exhaustion
*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.Serializable Class Containing Sensitive Data - (499)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1148 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)) > 499 (Serializable Class Containing Sensitive Data)
The code contains a class with sensitive data, but the class does not explicitly deny serialization. The data can be accessed by serializing the class through another class.
*VariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.Deserialization of Untrusted Data - (502)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1148 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)) > 502 (Deserialization of Untrusted Data)
The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.Marshaling, UnmarshalingPickling, Unpickling
*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.Allocation of Resources Without Limits or Throttling - (770)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1148 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)) > 770 (Allocation of Resources Without Limits or Throttling)
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 15. Platform Security (SEC) - (1149)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1149 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 15. Platform Security (SEC))
Weaknesses in this category are related to the rules and recommendations in the Platform Security (SEC) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Incorrect Privilege Assignment - (266)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1149 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 15. Platform Security (SEC)) > 266 (Incorrect Privilege Assignment)
A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.
*BaseBase - a weakness that is 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.Least Privilege Violation - (272)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1149 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 15. Platform Security (SEC)) > 272 (Least Privilege Violation)
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
*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 Permission Assignment for Critical Resource - (732)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1149 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 15. Platform Security (SEC)) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV) - (1150)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1150 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV))
Weaknesses in this category are related to the rules and recommendations in the Runtime Environment (ENV) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Acceptance of Extraneous Untrusted Data With Trusted Data - (349)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1150 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV)) > 349 (Acceptance of Extraneous Untrusted Data With Trusted Data)
The software, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
*ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.Incorrect Permission Assignment for Critical Resource - (732)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1150 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV)) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 17. Java Native Interface (JNI) - (1151)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1151 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 17. Java Native Interface (JNI))
Weaknesses in this category are related to the rules and recommendations in the Java Native Interface (JNI) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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.Direct Use of Unsafe JNI - (111)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1151 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 17. Java Native Interface (JNI)) > 111 (Direct Use of Unsafe JNI)
When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.
+CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC) - (1152)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC))
Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) section of the SEI CERT Oracle Secure Coding Standard for Java.
*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 Password - (259)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 259 (Use of Hard-coded Password)
The software contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
*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 Encryption of Sensitive Data - (311)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 311 (Missing Encryption of Sensitive Data)
The software does not encrypt sensitive or critical information before storage or transmission.
*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)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 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.
*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.Use of Insufficiently Random Values - (330)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 330 (Use of Insufficiently Random Values)
The software may use insufficiently random numbers or values in a security context that depends on unpredictable numbers.
*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.Insufficient Entropy in PRNG - (332)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 332 (Insufficient Entropy in PRNG)
The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.
*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.Same Seed in Pseudo-Random Number Generator (PRNG) - (336)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 336 (Same Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.
*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.Predictable Seed in Pseudo-Random Number Generator (PRNG) - (337)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 337 (Predictable Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
*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.Uncontrolled Resource Consumption - (400)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 400 (Uncontrolled Resource Consumption)
The software does not properly control the allocation and maintence of a limited resource thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.Resource Exhaustion
*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.Improper Release of Memory Before Removing Last Reference - (401)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 401 (Improper Release of Memory Before Removing Last Reference)
The software does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.Memory Leak
*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.Allocation of Resources Without Limits or Throttling - (770)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 770 (Allocation of Resources Without Limits or Throttling)
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
*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)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1152 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)) > 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.
*CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 50. Android (DRD) - (1153)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1153 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 50. Android (DRD))
Weaknesses in this category are related to the rules and recommendations in the Platform Security (SEC) section of the SEI CERT Oracle Secure Coding Standard for Java.
*CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.SEI CERT Oracle Secure Coding Standard for Java - Guidelines 18. Concurrency (CON) - (1175)
1133 (Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java) > 1175 (SEI CERT Oracle Secure Coding Standard for Java - Guidelines 18. Concurrency (CON))
Weaknesses in this category are related to the rules and recommendations in the Platform Security (SEC) section of the SEI CERT Oracle Secure Coding Standard for Java.
+ Notes

Relationship

The relationships in this view were determined based on specific statements within the rules from the standard. Not all rules have direct relationships to individual weaknesses, although they likely have chaining relationships in specific circumstances.
+ References
[REF-970] The Software Engineering Institute. "SEI CERT Oracle Coding Standard for Java". <https://wiki.sei.cmu.edu/confluence/display/java/SEI+CERT+Oracle+Coding+Standard+for+Java>.
+ View Metrics
CWEs in this viewTotal CWEs
Weaknesses88out of 806
Categories22out of 289
Views0out of 36
Total110out of1131
+ Content History
Submissions
Submission DateSubmitterOrganization
2018-12-11CWE Content TeamMITRE

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-349: Acceptance of Extraneous Untrusted Data With Trusted Data

Weakness ID: 349
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
+ Relationships

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.345Insufficient Verification of Data Authenticity
+ 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.345Insufficient Verification of Data Authenticity
+ 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 DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
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
Access Control
Integrity

Technical Impact: Bypass Protection Mechanism; Modify Application Data

An attacker could package untrusted data with trusted data to bypass protection mechanisms to gain access to and possibly modify sensitive data.
+ Observed Examples
ReferenceDescription
Does not verify that trusted entity is authoritative for all entities in its response.
+ 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.860The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1150SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUntrusted Data Appended with Trusted Data
The CERT Oracle Secure Coding Standard for Java (2011)ENV01-JPlace all security-sensitive code in a single JAR and sign and seal it
+ Content History
Submissions
Submission DateSubmitterOrganization
PLOVER
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Untrusted Data Appended with Trusted Data

CWE-770: Allocation of Resources Without Limits or Throttling

Weakness ID: 770
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
+ 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.400Uncontrolled Resource Consumption
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
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.774Allocation of File Descriptors or Handles Without Limits or Throttling
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.789Uncontrolled Memory Allocation
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
+ 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.840Business Logic 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.400Uncontrolled Resource Consumption
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.774Allocation of File Descriptors or Handles Without Limits or Throttling
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.789Uncontrolled Memory Allocation
+ 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 DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
System Configuration
+ 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
Availability

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

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

Example 1

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

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

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

Example 2

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

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

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

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

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

Example 3

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

(bad code)
Example Language:

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

int length = getMessageLength(message[0]);

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

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

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

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

Example 4

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

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


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

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

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

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

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


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

Example 5

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

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

Example 6

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

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

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

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

endConnection(foo)
}
+ Observed Examples
ReferenceDescription
Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
Large integer value for a length property in an object causes a large amount of memory allocation.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
+ Potential Mitigations

Phase: Requirements

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a 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.

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

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

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

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

Phase: Architecture and Design

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

Phases: Architecture and Design; Implementation

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

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

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

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

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

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

+ Detection Methods

Manual Static Analysis

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

Fuzzing

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

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

Effectiveness: Opportunistic

Automated Dynamic Analysis

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

Automated Static Analysis

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

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

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

+ Memberships
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.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.861The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.985SFP Secondary Cluster: Unrestricted Consumption
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1148SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1152SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
+ Notes

Maintenance

"Resource exhaustion" (CWE-400) is currently treated as a weakness, although it is more like a category of weaknesses that all have the same type of consequence. While this entry treats CWE-400 as a parent in view 1000, the relationship is probably more appropriately described as a chain.

Theoretical

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

CWE-405: Asymmetric Resource Consumption (Amplification)

Weakness ID: 405
Abstraction: Class
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
+ Extended Description
This situation is amplified if the software allows malicious users or attackers to consume more resources than their access level permits. Exploiting such a weakness can lead to asymmetric resource consumption, aiding in amplification attacks against the system or the network.
+ 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.664Improper Control of a Resource Through its Lifetime
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.406Insufficient Control of Network Message Volume (Network Amplification)
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.407Algorithmic Complexity
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.408Incorrect Behavior Order: Early Amplification
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.409Improper Handling of Highly Compressed Data (Data Amplification)
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.1050Excessive Platform Resource Consumption within a Loop
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.1072Data Resource Access without Use of Connection Pooling
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.1073Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses
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.1084Invokable Control Element with Excessive File or Data Access Operations
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.1089Large Data Table with Excessive Number of Indices
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.1094Excessive Index Range Scan for a Data Resource
ParentOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1176Inefficient CPU Computation
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.404Improper Resource Shutdown or Release
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
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.407Algorithmic Complexity
+ 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.399Resource Management 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.406Insufficient Control of Network Message Volume (Network Amplification)
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.407Algorithmic Complexity
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.408Incorrect Behavior Order: Early Amplification
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.409Improper Handling of Highly Compressed Data (Data Amplification)
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.1050Excessive Platform Resource Consumption within a Loop
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.1072Data Resource Access without Use of Connection Pooling
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.1073Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses
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.1084Invokable Control Element with Excessive File or Data Access Operations
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.1089Large Data Table with Excessive Number of Indices
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.1094Excessive Index Range Scan for a Data Resource
ParentOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.1176Inefficient CPU Computation
+ 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
Operation
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
Availability

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

Sometimes this is a factor in "flood" attacks, but other types of amplification exist.
+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Architecture and Design

An application must, at all times, keep track of allocated resources and meter their usage appropriately.
+ 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.399Resource Management Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.855The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1145SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAsymmetric resource consumption (amplification)
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
WASC41XML Attribute Blowup
The CERT Oracle Secure Coding Standard for Java (2011)TPS00-JUse thread pools to enable graceful degradation of service during traffic bursts
The CERT Oracle Secure Coding Standard for Java (2011)FIO04-JRelease resources when they are no longer needed
+ Content History
Submissions
Submission DateSubmitterOrganization
PLOVER
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Functional_Areas
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings

CWE-289: Authentication Bypass by Alternate Name

Weakness ID: 289
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
+ Relationships

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.287Improper Authentication
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.46Path Equivalence: 'filename ' (Trailing Space)
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.52Path Equivalence: '/multiple/trailing/slash//'
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.173Improper Handling of Alternate Encoding
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.178Improper Handling of Case Sensitivity
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1010Authenticate Actors
+ 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.287Improper Authentication
+ 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 DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
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
Access Control

Technical Impact: Bypass Protection Mechanism

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

Phase: Architecture and Design

Strategy: Input Validation

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

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a 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: 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.
+ 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.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.947SFP Secondary Cluster: Authentication Bypass
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
+ Notes

Relationship

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

Theoretical

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

CWE-589: Call to Non-ubiquitous API

Weakness ID: 589
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software uses an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.
+ Extended Description
Some functions that offer security features supported by the OS are not available on all versions of the OS in common use. Likewise, functions are often deprecated or made obsolete for security reasons and should not be used.
+ Relationships

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.474Use of Function with Inconsistent Implementations
+ 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.474Use of Function with Inconsistent Implementations
+ 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
Other

Technical Impact: Quality Degradation

+ Potential Mitigations

Phase: Implementation

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

Phase: Testing

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

Phase: Testing

Develop a system to test for API functions that are not portable.
+ Weakness Ordinalities
OrdinalityDescription
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ 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.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET02-JDo not use deprecated or obsolete classes or methods
The CERT Oracle Secure Coding Standard for Java (2011)SER00-JMaintain serialization compatibility during class evolution
Software Fault PatternsSFP3Use of an improper API
+ Content History
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Call to Limited API

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

Weakness ID: 572
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The program calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee.
+ Extended Description
In most cases a direct call to a Thread object's run() method is a bug. The programmer intended to begin a new thread of control, but accidentally called run() instead of start(), so the run() method will execute in the caller's thread of control.
+ Relationships

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.821Incorrect Synchronization
+ 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.557Concurrency Issues
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.821Incorrect Synchronization
+ 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

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
Other

Technical Impact: Quality Degradation; Varies by Context

+ Demonstrative Examples

Example 1

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

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

thr.run();
+ Potential Mitigations

Phase: Implementation

Use the start() method instead of the run() method.
+ Affected Resources
  • System Process
+ 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.854The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - Thread APIs (THI)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1144SEI CERT Oracle Secure Coding Standard for Java - Guidelines 10. Thread APIs (THI)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)THI00-JDo not invoke Thread.run()
Software Fault PatternsSFP3Use of an improper API
+ Content History
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Call to Thread.run()

CWE CATEGORY: Cleansing, Canonicalization, and Comparison Errors

Category ID: 171
Status: Draft
+ Summary
Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform neutralization for untrusted data.
+ Membership
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Representation Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.137Representation Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
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.172Encoding Error
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.178Improper Handling of Case Sensitivity
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.179Incorrect Behavior Order: Early Validation
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.180Incorrect Behavior Order: Validate Before Canonicalize
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.181Incorrect Behavior Order: Validate Before Filter
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.182Collapse of Data into Unsafe 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.183Permissive Whitelist
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.184Incomplete Blacklist
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.185Incorrect Regular Expression
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.187Partial String Comparison
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.478Missing Default Case in Switch Statement
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.486Comparison of Classes by Name
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.595Comparison of Object References Instead of Object Contents
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.697Incorrect Comparison
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.707Improper Enforcement of Message or Data Structure
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.768Incorrect Short Circuit Evaluation
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
+ Content History
Submissions
Submission DateSubmitterOrganization
PLOVER
Modifications
Modification DateModifierOrganization
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms
2011-06-01CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References, Related_Attack_Patterns, Relationships
2018-03-27CWE Content TeamMITRE
updated References, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings

CWE-319: Cleartext Transmission of Sensitive Information

Weakness ID: 319
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
+ Extended Description
Many communication channels can be "sniffed" by attackers during data transmission. For example, network traffic can often be sniffed by any attacker who has access to a network interface. This significantly lowers the difficulty of exploitation by attackers.
+ 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.311Missing Encryption of Sensitive Data
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.5J2EE Misconfiguration: Data Transmission Without Encryption
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1013Encrypt Data
+ 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.311Missing Encryption of Sensitive Data
+ 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 DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Operation
System Configuration
+ 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

Mobile (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 Files or Directories

Anyone can read the information by gaining access to the channel being used for communication.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

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

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

//...
}

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

+ Observed Examples
ReferenceDescription
Passwords transmitted in cleartext.
Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
Product sends password hash in cleartext in violation of intended policy.
Remote management feature sends sensitive information including passwords in cleartext.
Backup routine sends password in cleartext in email.
Product transmits Blowfish encryption key in cleartext.
Printer sends configuration information, including administrative password, in cleartext.
Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
Product sends passwords in cleartext to a log server.
Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
+ Potential Mitigations

Phase: Architecture and Design

Encrypt the data with a reliable encryption scheme before transmitting.

Phase: Implementation

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

Phase: Testing

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

Phase: Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.
+ Detection Methods

Black Box

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

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

+ 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.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.818OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1148SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Transmission of Sensitive Information
The CERT Oracle Secure Coding Standard for Java (2011)SEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
The CERT Oracle Secure Coding Standard for Java (2011)SER02-JSign then seal sensitive objects before sending them outside a trust boundary
Software Fault PatternsSFP23Exposed Data
+ References
[REF-271] OWASP. "Top 10 2007-Insecure Communications". 2007. <http://www.owasp.org/index.php/Top_10_2007-A9>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
PLOVER
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated References
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Relationships
2010-12-13CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, References
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-01-23CWE Content TeamMITRE
updated Abstraction
2018-03-27CWE Content TeamMITRE
updated References, Relationships, Type
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Plaintext Transmission of Sensitive Information

CWE-498: Cloneable Class Containing Sensitive Information

Weakness ID: 498
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class.
+ Extended Description
Cloneable classes are effectively open classes, since data cannot be hidden in them. Classes that do not explicitly deny cloning can be cloned by any other class without running the constructor.
+ Relationships

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.664Improper Control of a Resource Through its Lifetime
CanPrecedeClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.200Information Exposure
+ 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.490Mobile Code Issues
CanPrecedeClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.200Information Exposure
+ 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)

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
Access Control

Technical Impact: Bypass Protection Mechanism

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

Example 1

The following example demonstrates the weakness.

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

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

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

public Object clone() {

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

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

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

Make classes uncloneable by defining a clone function like:

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

Phase: Implementation

If you do make your classes clonable, ensure that your clone method is final and throw super.clone().
+ Memberships
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)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPInformation leak through class cloning
The CERT Oracle Secure Coding Standard for Java (2011)OBJ07-JSensitive classes must not let themselves be copied
Software Fault PatternsSFP23Exposed Data
+ Content History
Submissions
Submission DateSubmitterOrganization
CLASP
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Other_Notes
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak through Class Cloning

CWE-182: Collapse of Data into Unsafe Value

Weakness ID: 182
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
+ 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.693Protection Mechanism Failure
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.185Incorrect Regular Expression
CanPrecedeVariantVariant - 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.33Path Traversal: '....' (Multiple Dot)
CanPrecedeVariantVariant - 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.34Path Traversal: '....//'
CanPrecedeVariantVariant - 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.35Path Traversal: '.../...//'
+ 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.171Cleansing, Canonicalization, and Comparison Errors
+ 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

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
Access Control

Technical Impact: Bypass Protection Mechanism

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

Phase: Architecture and Design

Strategy: Input Validation

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

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a 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: 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.
Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function).
+ 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.845The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.992SFP Secondary Cluster: Faulty Input Transformation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
+ Notes

Relationship

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

CWE-486: Comparison of Classes by Name

Weakness ID: 486
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The program compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.
+ Extended Description
If the decision to trust the methods and data of an object is based on the name of a class, it is possible for malicious users to send objects of the same name as trusted classes and thereby gain the trust afforded to known classes and types.
+ Relationships

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.1025Comparison Using Wrong Factors
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.386Symbolic Name not Mapping to Correct Object
+ 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.171Cleansing, Canonicalization, and Comparison Errors
+ 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

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
Availability

Technical Impact: Execute Unauthorized Code or Commands

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

Example 1

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

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

// Do something assuming you trust inputClass

// ...
}

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

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

// Do something assuming you trust inputClass

// ...
}

Example 2

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

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

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

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

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

return isEquals;
}

...
}

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

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

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

...
}
+ Potential Mitigations

Phase: Implementation

Use class equivalency to determine type. Rather than use the class name to determine if an object is of a given type, use the getClass() method, and == operator.
+ 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.4857PK - Encapsulation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.849The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1139SEI CERT Oracle Secure Coding Standard for Java - Guidelines 05. Object Orientation (OBJ)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsComparing Classes by Name
CLASPComparing classes by name
The CERT Oracle Secure Coding Standard for Java (2011)OBJ09-JCompare classes and not class names
Software Fault PatternsSFP1Glitch in computation
+ 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 Common_Consequences, Description, Relationships, Other_Notes, Relevant_Properties, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Other_Notes
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Relevant_Properties
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Comparing Classes by Name

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

Weakness ID: 595
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The program compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
+ Extended Description
For example, in Java, comparing objects using == usually produces deceptive results, since the == operator compares object references rather than values; often, this means that using == for strings is actually comparing the strings' references, not their values.
+ Relationships

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.1025Comparison Using Wrong Factors
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.597Use of Wrong Operator in String 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.171Cleansing, Canonicalization, and Comparison Errors
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.569Expression Issues
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.597Use of Wrong Operator in String Comparison
+ 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

Java (Undetermined Prevalence)

JavaScript (Undetermined Prevalence)

PHP (Undetermined Prevalence)

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
Other

Technical Impact: Varies by Context

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

Example 1

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

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

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

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

Example 2

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

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

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

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

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

Phase: Implementation

In Java, use the equals() method to compare objects instead of the == operator. If using ==, it is important for performance reasons that your objects are created by a static factory, not by a constructor.
+ 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.847The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.977SFP Secondary Cluster: Design
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1136SEI CERT Oracle Secure Coding Standard for Java - Guidelines 02. Expressions (EXP)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)EXP02-JUse the two-argument Arrays.equals() method to compare the contents of arrays
The CERT Oracle Secure Coding Standard for Java (2011)EXP02-JUse the two-argument Arrays.equals() method to compare the contents of arrays
The CERT Oracle Secure Coding Standard for Java (2011)EXP03-JDo not use the equality operators when comparing values of boxed primitives
+ References
[REF-954] Mozilla MDN. "Equality comparisons and sameness". 2017-11-17. <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness>.
+ Content History
Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Name
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences
2014-07-30CWE Content TeamMITRE
updated Relationships
2018-03-27CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Other_Notes, Potential_Mitigations, References, Relationships, Type
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Incorrect Object Comparison: Syntactic
2009-05-27Incorrect Syntactic Object Comparison

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

Weakness ID: 362
Abstraction: Class
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
+ Extended Description

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

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

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

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

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

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

+ 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.691Insufficient Control Flow Management
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.364Signal Handler Race Condition
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.366Race Condition within a Thread
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.367Time-of-check Time-of-use (TOCTOU) Race Condition
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.368Context Switching Race Condition
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.421Race Condition During Access to Alternate Channel
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.662Improper Synchronization
+ 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.3617PK - Time and State
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.364Signal Handler Race Condition
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.366Race Condition within a Thread
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.367Time-of-check Time-of-use (TOCTOU) Race Condition
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.368Context Switching Race Condition
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.421Race Condition During Access to Alternate Channel
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.662Improper Synchronization
+ 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 (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Java (Sometimes Prevalent)

Class: Language-Independent (Undetermined Prevalence)

Paradigms

Concurrent Systems Operating on Shared Resources (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
Availability

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

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

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

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

Technical Impact: Read Files or Directories; Read Application Data

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

Example 1

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

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

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

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

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

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

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

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

Example 2

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

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

/* access shared resource */


pthread_mutex_unlock(mutex);
}

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

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting 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);
}
+ Observed Examples
ReferenceDescription
Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
Race condition during initialization triggers a buffer overflow.
Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
chain: race condition triggers NULL pointer dereference
Race condition in library function could cause data to be sent to the wrong process.
Race condition in file parser leads to heap corruption.
chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
chain: race condition for an argument value, possibly resulting in NULL dereference
chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Black Box

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

White Box

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

Automated Dynamic Analysis

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

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

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

Effectiveness: Moderate

Automated Static Analysis - Binary or Bytecode

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

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

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

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

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

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

Highly cost effective:
  • Framework-based Fuzzer
Cost effective for partial coverage:
  • Fuzz Tester
  • Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: High

Manual Static Analysis - Source Code

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

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

Effectiveness: High

Automated Static Analysis - Source Code

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

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

Effectiveness: High

Architecture or Design Review

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

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

Effectiveness: High

+ Memberships
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.3617PK - Time and State
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).635Weaknesses Originally Used by NVD from 2008 to 2016
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.743CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.7512009 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8012010 Top 25 - Insecure Interaction Between Components
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.877CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.882CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.988SFP Secondary Cluster: Race Condition Window
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)
+ Notes

Maintenance

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.

Research Gap

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

Research Gap

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

Research Gap

From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERRace Conditions
The CERT Oracle Secure Coding Standard for Java (2011)VNA03-JDo not assume that a group of calls to independently atomic methods is atomic
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-349] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <http://www.ddj.com/cpp/184403766>.
[REF-350] Steven Devijver. "Thread-safe webapps using Spring". <http://www.javalobby.org/articles/thread-safe/index.jsp>.
[REF-351] David Wheeler. "Prevent race conditions". 2007-10-04. <http://www.ibm.com/developerworks/library/l-sprace.html>.
[REF-352] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <http://www.cs.ucdavis.edu/research/tech-reports/1995/CSE-95-9.pdf>.
[REF-353] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>.
[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <http://www.blakewatts.com/namedpipepaper.html>.
[REF-355] Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications". <http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.
[REF-356] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>.
[REF-357] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <http://blogs.sans.org/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
+ Content History
Submissions
Submission DateSubmitterOrganization
PLOVER
Contributions
Contribution DateContributorOrganization
2010-04-30Martin SeborCisco Systems, Inc.
Provided Demonstrative Example
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Detection_Factors, References, Relationships
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Observed_Examples, Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Race Conditions
2010-12-13Race Condition

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-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-502: Deserialization of Untrusted Data

Weakness ID: 502
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.
+ Extended Description

It is often convenient to serialize objects for communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security -- which is a dangerous security assumption.

Data that is untrusted can not be trusted to be well-formed.

When developers place no restrictions on "gadget chains," or series of instances and method invocations that can self-execute during the deserialization process (i.e., before the object is returned to the caller), it is sometimes possible for attackers to leverage them to perform unauthorized actions, like generating a shell.

+ Alternate Terms
Marshaling, Unmarshaling:
Marshaling and unmarshaling are effectively synonyms for serialization and deserialization, respectively.
Pickling, Unpickling:
In Python, the "pickle" functionality is used to perform serialization and deserialization.
+ 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.913Improper Control of Dynamically-Managed Code Resources
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.915Improperly Controlled Modification of Dynamically-Determined Object Attributes
+ 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.913Improper Control of Dynamically-Managed Code Resources
+ 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.913Improper Control of Dynamically-Managed Code Resources
+ Background Details
Serialization and deserialization refer to the process of taking program-internal object-related data, packaging it in a way that allows the data to be externally stored or transferred ("serialization"), then extracting the serialized data to reconstruct the original object ("deserialization").
+ Modes Of Introduction

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 DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
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

Java (Undetermined Prevalence)

Ruby (Undetermined Prevalence)

PHP (Undetermined Prevalence)

Python (Undetermined Prevalence)

JavaScript (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

Technical Impact: Modify Application Data; Unexpected State

Attackers can modify unexpected objects or data that was assumed to be safe from modification.
Availability

Technical Impact: DoS: Resource Consumption (CPU)

If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.
Other

Technical Impact: Varies by Context

The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This code snippet deserializes an object from a file and uses it as a UI button:

(bad code)
Example Language: Java 
try {
File file = new File("object.obj");
ObjectInputStream in = new ObjectInputStream(new FileInputStream(file));
javax.swing.JButton button = (javax.swing.JButton) in.readObject();
in.close();
}

This code does not attempt to verify the source or contents of the file before deserializing it. An attacker may be able to replace the intended file with a file that contains arbitrary malicious code which will be executed when the button is pressed.

To mitigate this, explicitly define final readObject() to prevent deserialization. An example of this is:

(good code)
Example Language: Java 
private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized"); }

Example 2

In Python, the Pickle library handles the serialization and deserialization processes. In this example derived from [R.502.7], the code receives and parses data, and afterwards tries to authenticate a user based on validating a token.

(bad code)
Example Language: Python 
try {
class ExampleProtocol(protocol.Protocol):
def dataReceived(self, data):

# Code that would be here would parse the incoming data
# After receiving headers, call confirmAuth() to authenticate

def confirmAuth(self, headers):
try:
token = cPickle.loads(base64.b64decode(headers['AuthToken']))
if not check_hmac(token['signature'], token['data'], getSecretKey()):
raise AuthFail
self.secure_data = token['data']
except:
raise AuthFail
}

Unfortunately, the code does not verify that the incoming data is legitimate. An attacker can construct a illegitimate, serialized object "AuthToken" that instantiates one of Python's subprocesses to execute arbitrary commands. For instance,the attacker could construct a pickle that leverages Python's subprocess module, which spawns new processes and includes a number of arguments for various uses. Since Pickle allows objects to define the process for how they should be unpickled, the attacker can direct the unpickle process to call Popen in the subprocess module and execute /bin/sh.

+ Observed Examples
ReferenceDescription
Deserialization issue in commonly-used Java library allows remote execution.
Deserialization issue in commonly-used Java library allows remote execution.
Use of PHP unserialize function on untrusted input allows attacker to modify application configuration.
Use of PHP unserialize function on untrusted input in content management system might allow code execution.
Use of PHP unserialize function on untrusted input in content management system allows code execution using a crafted cookie value.
Content management system written in PHP allows unserialize of arbitrary objects, possibly allowing code execution.
Python script allows local users to execute code via pickled data.
Unsafe deserialization using pickle in a Python script.
Web browser allows execution of native methods via a crafted string to a JavaScript function that deserializes the string.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.

Phase: Implementation

When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Phase: Implementation

Explicitly define a final object() to prevent deserialization.

Phases: Architecture and Design; Implementation

Make fields transient to protect them from deserialization.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

Phase: Implementation

Avoid having unnecessary types or gadgets available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Whitelist acceptable classes. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
+ 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.858The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.994SFP Secondary Cluster: Tainted Input to Variable
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1034OWASP Top Ten 2017 Category A8 - Insecure Deserialization
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1148SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
+ Notes

Maintenance

The relationships between CWE-502 and CWE-915 need further exploration. CWE-915 is more narrowly scoped to object modification, and is not necessarily used for deserialization.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPDeserialization of untrusted data
The CERT Oracle Secure Coding Standard for Java (2011)SER01-JDo not deviate from the proper signatures of serialization methods
The CERT Oracle Secure Coding Standard for Java (2011)SER03-JDo not serialize unencrypted, sensitive data
The CERT Oracle Secure Coding Standard for Java (2011)SER06-JMake defensive copies of private mutable components during deserialization
The CERT Oracle Secure Coding Standard for Java (2011)SER08-JDo not use the default serialized form for implementation defined invariants
Software Fault PatternsSFP25Tainted input to variable
+ References
[REF-461] Matthias Kaiser. "Exploiting Deserialization Vulnerabilities in Java". 2015-10-28. <http://www.slideshare.net/codewhitesec/exploiting-deserialization-vulnerabilities-in-java-54707478>.
[REF-462] Sam Thomas. "PHP unserialization vulnerabilities: What are we missing?". 2015-08-27. <http://www.slideshare.net/_s_n_t/php-unserialization-vulnerabilities-what-are-we-missing>.
[REF-463] Gabriel Lawrence and Chris Frohoff. "Marshalling Pickles: How deserializing objects can ruin your day". 2015-01-28. <http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles>.
[REF-464] Heine Deelstra. "Unserializing user-supplied data, a bad idea". 2010-08-25. <http://heine.familiedeelstra.com/security/unserialize>.
[REF-465] Manish S. Saindane. "Black Hat EU 2010 - Attacking Java Serialized Communication". 2010-04-26. <http://www.slideshare.net/msaindane/black-hat-eu-2010-attacking-java-serialized-communication>.
[REF-466] Nadia Alramli. "Why Python Pickle is Insecure". 2009-09-09. <http://nadiana.com/python-pickle-insecure>.
[REF-467] Nelson Elhage. "Exploiting misuse of Python's "pickle"". 2011-03-20. <https://blog.nelhage.com/2011/03/exploiting-pickle/>.
[REF-468] Chris Frohoff. "Deserialize My Shorts: Or How I Learned to Start Worrying and Hate Java Object Deserialization". 2016-03-21. <https://www.slideshare.net/frohoff1/deserialize-my-shorts-or-how-i-learned-to-start-worrying-and-hate-java-object-deserialization>.
+ Content History
Submissions
Submission DateSubmitterOrganization
CLASP
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Observed_Examples, References, Relationships
2017-05-03CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Potential_Mitigations, References
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Modes_of_Introduction, Potential_Mitigations, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings

CWE-111: Direct Use of Unsafe JNI

Weakness ID: 111
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.
+ Extended Description
Many safety features that programmers may take for granted simply do not apply for native code, so you must carefully review all such code for potential problems. The languages used to implement native code may be more susceptible to buffer overflows and other attacks. Native code is unprotected by the security features enforced by the runtime environment, such as strong typing and array bounds checking.
+ Relationships

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.695Use of Low-Level Functionality
+ 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.20Improper Input Validation
+ 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

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
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The following code defines a class named Echo. The class declares one native method (defined below), which uses C to echo commands entered on the console back to the user. The following C code defines the native method implemented in the Echo class:

(bad code)
Example Language: Java 
class Echo {

public native void runEcho();
static {

System.loadLibrary("echo");
}
public static void main(String[] args) {

new Echo().runEcho();
}
}
(bad code)
Example Language:
#include <jni.h>
#include "Echo.h"//the java class above compiled with javah
#include <stdio.h>

JNIEXPORT void JNICALL
Java_Echo_runEcho(JNIEnv *env, jobject obj)
{
char buf[64];
gets(buf);
printf(buf);
}

Because the example is implemented in Java, it may appear that it is immune to memory issues like buffer overflow vulnerabilities. Although Java does do a good job of making memory operations safe, this protection does not extend to vulnerabilities occurring in source code written in other languages that are accessed using the Java Native Interface. Despite the memory protections offered in Java, the C code in this example is vulnerable to a buffer overflow because it makes use of gets(), which does not check the length of its input.

The Sun Java(TM) Tutorial provides the following description of JNI [See Reference]: The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them.

The vulnerability in the example above could easily be detected through a source code audit of the native method implementation. This may not be practical or possible depending on the availability of the C source code and the way the project is built, but in many cases it may suffice. However, the ability to share objects between Java and native methods expands the potential risk to much more insidious cases where improper data handling in Java may lead to unexpected vulnerabilities in native code or unsafe operations in native code corrupt data structures in Java. Vulnerabilities in native code accessed through a Java application are typically exploited in the same manner as they are in applications written in the native language. The only challenge to such an attack is for the attacker to identify that the Java application uses native code to perform certain operations. This can be accomplished in a variety of ways, including identifying specific behaviors that are often implemented with native code or by exploiting a system information exposure in the Java application that reveals its use of JNI [See Reference].

+ Potential Mitigations

Phase: Implementation

Implement error handling around the JNI call.

Phase: Implementation

Strategy: Refactoring

Do not use JNI calls if you don't trust the native library.

Phase: Implementation

Strategy: Refactoring

Be reluctant to use JNI calls. A Java API equivalent may exist.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.859The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1151SEI CERT Oracle Secure Coding Standard for Java - Guidelines 17. Java Native Interface (JNI)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsUnsafe JNI
The CERT Oracle Secure Coding Standard for Java (2011)SEC08-JDefine wrappers around native methods
SEI CERT Oracle Coding Standard for JavaJNI01-JSafely invoke standard APIs that perform tasks using the immediate caller's class loader instance (loadLibrary)
SEI CERT Oracle Coding Standard for JavaJNI00-JImpreciseDefine wrappers around native methods
Software Fault PatternsSFP3Use of an improper API
+ References
[REF-41] Fortify Software. "Fortify Descriptions". <http://vulncat.fortifysoftware.com>.
[REF-42] Beth Stearns. "The Java(TM) Tutorial: The Java Native Interface". Sun Microsystems. 2005. <http://www.eg.bucknell.edu/~mead/Java-tutorial/native1.1/index.html>.
+ Content History
Submissions
Submission DateSubmitterOrganization
7 Pernicious Kingdoms
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, References, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Description, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Potential_Mitigations, References
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unsafe JNI

CWE-369: Divide By Zero

Weakness ID: 369
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product divides a value by zero.
+ Extended Description
This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.
+ Relationships

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.682Incorrect Calculation
+ 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.682Incorrect Calculation
+ 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.682Incorrect Calculation
+ 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
Availability

Technical Impact: DoS: Crash, Exit, or Restart

A Divide by Zero results in a crash.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following Java example contains a function to compute an average but does not validate that the input value used as the denominator is not zero. This will create an exception for attempting to divide by zero. If this error is not handled by Java exception handling, unexpected results can occur.

(bad code)
Example Language: Java 
public int computeAverageResponseTime (int totalTime, int numRequests) {
return totalTime / numRequests;
}

By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. The following Java code example will validate the input value, output an error message, and throw an exception.

(good code)
 
public int computeAverageResponseTime (int totalTime, int numRequests) throws ArithmeticException {
if (numRequests == 0) {
System.out.println("Division by zero attempted!");
throw ArithmeticException;
}
return totalTime / numRequests;
}

Example 2

The following C/C++ example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.

(bad code)
Example Language:
double divide(double x, double y){
return x/y;
}

By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. If the method is called and a zero is passed as the second argument a DivideByZero error will be thrown and should be caught by the calling block with an output message indicating the error.

(good code)
 
const int DivideByZero = 10;
double divide(double x, double y){
if ( 0 == y ){
throw DivideByZero;
}
return x/y;
}
...
try{
divide(10, 0);
}
catch( int i ){
if(i==DivideByZero) {
cerr<<"Divide by zero error";
}
}
Example 2 References:
[REF-371] Alex Allain. "Handling Errors Exceptionally Well in C++". <http://www.cprogramming.com/tutorial/exceptions.html>.

Example 3

The following C# example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.

(bad code)
Example Language: C# 
int Division(int x, int y){
return (x / y);
}

The method can be modified to raise, catch and handle the DivideByZeroException if the input value used as the denominator is zero.

(good code)
 
int SafeDivision(int x, int y){
try{
return (x / y);
}
catch (System.DivideByZeroException dbz){
System.Console.WriteLine("Division by zero attempted!");
return 0;
}
}
Example 3 References:
[REF-372] Microsoft. "Exceptions and Exception Handling (C# Programming Guide)". <https://msdn.microsoft.com/pl-pl/library/ms173160(v=vs.100).aspx>.
+ Observed Examples
ReferenceDescription
Invalid size value leads to divide by zero.
"Empty" content triggers divide by zero.
Height value of 0 triggers divide by zero.
+ 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.730OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.738CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.739CERT C Secure Coding Standard (2008) Chapter 6 - Floating Point (FLP)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.848The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.872CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.873CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.998SFP Secondary Cluster: Glitch in Computation
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1137SEI CERT Oracle Secure Coding Standard for Java - Guidelines 03. Numeric Types and Operations (NUM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1158SEI CERT C Coding Standard - Guidelines 04. Integers (INT)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingFLP03-CDetect and handle floating point errors
CERT C Secure CodingINT33-CExactEnsure that division and remainder operations do not result in divide-by-zero errors
The CERT Oracle Secure Coding Standard for Java (2011)NUM02-JEnsure that division and modulo operations do not result in divide-by-zero errors
Software Fault PatternsSFP1Glitch in computation
+ Content History
Modifications
Modification DateModifierOrganization
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings

CWE-609: Double-Checked Locking

Weakness ID: 609
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The program uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.
+ Extended Description
Double-checked locking refers to the situation where a programmer checks to see if a resource has been initialized, grabs a lock, checks again to see if the resource has been initialized, and then performs the initialization if it has not occurred yet. This should not be done, as is not guaranteed to work in all languages and on all architectures. In summary, other threads may not be operating inside the synchronous block and are not guaranteed to see the operations execute in the same order as they would appear inside the synchronous block.
+ Relationships

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.667Improper Locking
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.367Time-of-check Time-of-use (TOCTOU) Race Condition
+ 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.3617PK - Time and State
+ 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

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
Other

Technical Impact: Modify Application Data; Alter Execution Logic

+ Demonstrative Examples

Example 1

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

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

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

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

(bad code)
 
helper = new Helper();

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

+ Potential Mitigations

Phase: Implementation

While double-checked locking can be achieved in some languages, it is inherently flawed in Java before 1.5, and cannot be achieved without compromising platform independence. Before Java 1.5, only use of the synchronized keyword is known to work. Beginning in Java 1.5, use of the "volatile" keyword allows double-checked locking to work successfully, although there is some debate as to whether it achieves sufficient performance gains. See references.
+ Memberships
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.853The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1143SEI CERT Oracle Secure Coding Standard for Java - Guidelines 09. Locking (LCK)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)LCK10-JDo not use incorrect forms of the double-checked locking idiom
Software Fault PatternsSFP19Missing Lock
+ References
[REF-490] David Bacon et al. "The "Double-Checked Locking is Broken" Declaration". <http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html>.
[REF-491] Jeremy Manson and Brian Goetz. "JSR 133 (Java Memory Model) FAQ". <http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Threading Vulnerabilities", Page 815. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganization
Anonymous Tool Vendor (under NDA)
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Context_Notes
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Demonstrative_Examples
2009-01-12CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Double Checked Locking

CWE-586: Explicit Call to Finalize()

Weakness ID: 586
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software makes an explicit call to the finalize() method from outside the finalizer.
+ Extended Description
While the Java Language Specification allows an object's finalize() method to be called from outside the finalizer, doing so is usually a bad idea. For example, calling finalize() explicitly means that finalize() will be called more than once: the first time will be the explicit call and the last time will be the call that is made after the object is garbage collected.
+ Relationships

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
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.675Duplicate Operations on Resource
+ 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
+ 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

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
Other

Technical Impact: Unexpected State; Quality Degradation

+ Demonstrative Examples

Example 1

The following code fragment calls finalize() explicitly:

(bad code)
Example Language: Java 

// time to clean up
widget.finalize();
+ Potential Mitigations

Phases: Implementation; Testing

Do not make explicit calls to finalize(). Use static analysis tools to spot such instances.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ 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.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1001SFP Secondary Cluster: Use of an Improper API
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET12-JDo not use finalizers
Software Fault PatternsSFP3Use of an improper API
+ Content History
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Name, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Explicit Call to Finalize

CWE-359: Exposure of Private Information ('Privacy Violation')

Weakness ID: 359
Abstraction: Class
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software does not properly prevent private data (such as credit card numbers) from being accessed by actors who either (1) are not explicitly authorized to access the data or (2) do not have the implicit consent of the people to which the data is related.
+ Extended Description

Mishandling private information, such as customer passwords or Social Security numbers, can compromise user privacy and is often illegal. An exposure of private information does not necessarily prevent the software from working properly, and in fact it might be intended by the developer, but it can still be undesirable (or explicitly prohibited by law) for the people who are associated with this private information.

Privacy violations may occur when:

  1. Private user information enters the program.
  2. The data is written to an external location, such as the console, file system, or network.

Private data can enter a program in a variety of ways:

  1. Directly from the user in the form of a password or personal information
  2. Accessed from a database or other data store by the application
  3. Indirectly from a partner or other third party

Some types of private information include:

  • Government identifiers, such as Social Security Numbers
  • Contact information, such as home addresses and telephone numbers
  • Geographic location - where the user is (or was)
  • Employment history
  • Financial data - such as credit card numbers, salary, bank accounts, and debts
  • Pictures, video, or audio
  • Behavioral patterns - such as web surfing history, when certain activities are performed, etc.
  • Relationships (and types of relationships) with others - family, friends, contacts, etc.
  • Communications - e-mail addresses, private e-mail messages, SMS text messages, chat logs, etc.
  • Health - medical conditions, insurance status, prescription records
  • Credentials, such as passwords, which can be used to access other information.

Some of this information may be characterized as PII (Personally Identifiable Information), Protected Health Information (PHI), etc. Categories of private information may overlap or vary based on the intended usage or the policies and practices of a particular industry.

Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations: - Safe Harbor Privacy Framework [REF-340] - Gramm-Leach Bliley Act (GLBA) [REF-341] - Health Insurance Portability and Accountability Act (HIPAA) [REF-342] - California SB-1386 [REF-343].

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.

+ Alternate Terms
Privacy leak
Privacy leakage
+ 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.200Information Exposure
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.202Exposure of Sensitive Data Through Data Queries
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1011Authorize Actors
+ 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.2547PK - Security Features
+ 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 DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
+ 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

Mobile (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

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

In 2004, an employee at AOL sold approximately 92 million private customer e-mail addresses to a spammer marketing an offshore gambling web site [REF-338]. In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated.

Example 2

The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account.

(bad code)
Example Language: C# 
pass = GetPassword();
...
dbmsLog.WriteLine(id + ":" + pass + ":" + type + ":" + tstamp);

The code in the example above logs a plaintext password to the filesystem. Although many developers trust the filesystem as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

Example 3

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

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

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

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

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

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

+ 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.2547PK - Security Features
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.857The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.975SFP Secondary Cluster: Architecture
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1029OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1147SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsPrivacy Violation
The CERT Oracle Secure Coding Standard for Java (2011)FIO13-JDo not log sensitive information outside a trust boundary
+ References
[REF-338] J. Oates. "AOL man pleads guilty to selling 92m email addies". The Register. 2005. <http://www.theregister.co.uk/2005/02/07/aol_email_theft/>.
[REF-339] NIST. "Guide to Protecting the Confidentiality of Personally Identifiable Information (SP 800-122)". 2010-04. <http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf>.
[REF-340] U.S. Department of Commerce. "Safe Harbor Privacy Framework". <http://www.export.gov/safeharbor/>.
[REF-341] Federal Trade Commission. "Financial Privacy: The Gramm-Leach Bliley Act (GLBA)". <http://www.ftc.gov/privacy/glbact/index.html>.
[REF-342] U.S. Department of Human Services. "Health Insurance Portability and Accountability Act (HIPAA)". <http://www.hhs.gov/ocr/hipaa/>.
[REF-343] Government of the State of California. "California SB-1386". 2002. <http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html>.
[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf>.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ 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 Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Other_Notes
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-12-28CWE Content TeamMITRE
updated Other_Notes, References
2010-02-16CWE Content TeamMITRE
updated Other_Notes, References
2011-03-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Other_Notes, References
2012-05-11CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, References
2014-02-18CWE Content TeamMITRE
updated Alternate_Terms, Demonstrative_Examples, Description, Name, Other_Notes, References
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
2018-03-27CWE Content TeamMITRE
updated Relationships
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2014-02-18Privacy Violation

CWE-583: finalize() Method Declared Public

Weakness ID: 583
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The program violates secure coding principles for mobile code by declaring a finalize() method public.
+ Extended Description
A program should never call finalize explicitly, except to call super.finalize() inside an implementation of finalize(). In mobile code situations, the otherwise error prone practice of manual garbage collection can become a security threat if an attacker can maliciously invoke one of your finalize() methods because it is declared with public access.
+ 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
+ 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.490Mobile Code 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
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

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
Confidentiality
Integrity
Availability

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

+ Demonstrative Examples

Example 1

The following Java Applet code mistakenly declares a public finalize() method.

(bad code)
Example Language: Java 
public final class urlTool extends Applet {
public void finalize() {
...
}
...
}

Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running.

+ Potential Mitigations

Phase: Implementation

If you are using finalize() as it was designed, there is no reason to declare finalize() with anything other than protected access.
+ 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.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET12-JDo not use finalizers
Software Fault PatternsSFP28Unexpected access points
+ Content History
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Public Finalize Method

CWE-568: finalize() Method Without super.finalize()

Weakness ID: 568
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software contains a finalize() method that does not call super.finalize().
+ Extended Description
The Java Language Specification states that it is a good practice for a finalize() method to call super.finalize().
+ Relationships

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.573Improper Following of Specification by Caller
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.459Incomplete Cleanup
+ 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.399Resource Management Errors
+ 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

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
Other

Technical Impact: Quality Degradation

+ Demonstrative Examples

Example 1

The following method omits the call to super.finalize().

(bad code)
Example Language: Java 
protected void finalize() {
discardNative();
}
+ Potential Mitigations

Phase: Implementation

Call the super.finalize() method.

Phase: Testing

Use static analysis tools to spot such issues in your code.
+ 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.850The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1002SFP Secondary Cluster: Unexpected Entry Points
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1140SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)MET12-JDo not use finalizers
Software Fault PatternsSFP28Unexpected access points
+ Content History
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Erroneous Finalize Method

CWE-754: Improper Check for Unusual or Exceptional Conditions

Weakness ID: 754
Abstraction: Class
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software does not check or improperly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the software.
+ Extended Description

The programmer may assume that certain events or conditions will never occur or do not need to be worried about, such as low memory conditions, lack of access to resources due to restrictive permissions, or misbehaving clients or components. However, attackers may intentionally trigger these unusual conditions, thus violating the programmer's assumptions, possibly introducing instability, incorrect behavior, or a vulnerability.

Note that this entry is not exclusively about the use of exceptions and exception handling, which are mechanisms for both checking and handling unusual or unexpected conditions.

+ Relationships

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.703Improper Check or Handling of Exceptional Conditions
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.252Unchecked Return Value
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.253Incorrect Check of Function Return Value
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.273Improper Check for Dropped Privileges
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.354Improper Validation of Integrity Check Value
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.394Unexpected Status Code or Return Value
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1012Cross Cutting
+ 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.840Business Logic 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.703Improper Check or Handling of Exceptional Conditions
+ Background Details
Many functions will return some value about the success of their actions. This will alert the program whether or not to handle any errors caused by that function.
+ Modes Of Introduction

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
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
Integrity
Availability

Technical Impact: DoS: Crash, Exit, or Restart; Unexpected State

The data which were produced as a result of a function call could be in a bad state upon return. If the return value is not checked, then this bad data may be used in operations, possibly leading to a crash or other unintended behaviors.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

Consider the following code segment:

(bad code)
Example Language:
char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);

The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy().

Example 2

The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().

(bad code)
Example Language:
buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size);

The traditional defense of this coding error is: "If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations:

  • Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue.
  • It is impossible for the program to perform a graceful exit if required. If the program is performing an atomic operation, it can leave the system in an inconsistent state.
  • The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.

Example 3

The following examples read a file into a byte array.

(bad code)
Example Language: C# 
char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {
String userName = (String) i.Current();
String pFileName = PFILE_ROOT + "/" + userName;
StreamReader sr = new StreamReader(pFileName);
sr.Read(byteArray,0,1024);//the file is always 1k bytes
sr.Close();
processPFile(userName, byteArray);
}
(bad code)
Example Language: Java 
FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {
String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName;
FileInputStream fis = new FileInputStream(pFileName);
fis.read(byteArray); // the file is always 1k bytes
fis.close();
processPFile(userName, byteArray);

The code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and treat it as though it belongs to the attacker.

Example 4

The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference.

(bad code)
Example Language: Java 
String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM) == 0) {
...
}
...

The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a NULL dereference.

(bad code)
Example Language: Java 
String itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {
...
}
...

The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

Example 5

The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined.

(bad code)
Example Language: Java 
System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported");

The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

Example 6

The following VB.NET code does not check to make sure that it has read 50 bytes from myfile.txt. This can cause DoDangerousOperation() to operate on an unexpected value.

(bad code)
Example Language: C# 
Dim MyFile As New FileStream("myfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read)
Dim MyArray(50) As Byte
MyFile.Read(MyArray, 0, 50)
DoDangerousOperation(MyArray(20))

In .NET, it is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. The stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested.

Example 7

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

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

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

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

If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. When this occurs, a NULL pointer dereference (CWE-476) will occur in the call to strcpy().

Note that this example is also vulnerable to a buffer overflow (see CWE-119).

Example 8

In the following C/C++ example the method outputStringToFile opens a file in the local filesystem and outputs a string to the file. The input parameters output and filename contain the string to output to the file and the name of the file respectively.

(bad code)
Example Language: C++ 
int outputStringToFile(char *output, char *filename) {

openFileToWrite(filename);
writeToFile(output);
closeFile(filename);
}

However, this code does not check the return values of the methods openFileToWrite, writeToFile, closeFile to verify that the file was properly opened and closed and that the string was successfully written to the file. The return values for these methods should be checked to determine if the method was successful and allow for detection of errors or unexpected conditions as in the following example.

(good code)
Example Language: C++ 
int outputStringToFile(char *output, char *filename) {
int isOutput = SUCCESS;

int isOpen = openFileToWrite(filename);
if (isOpen == FAIL) {
printf("Unable to open file %s", filename);
isOutput = FAIL;
}
else {
int isWrite = writeToFile(output);
if (isWrite == FAIL) {
printf("Unable to write to file %s", filename);
isOutput = FAIL;
}

int isClose = closeFile(filename);
if (isClose == FAIL)
isOutput = FAIL;
}
return isOutput;
}

Example 9

In the following Java example the method readFromFile uses a FileReader object to read the contents of a file. The FileReader object is created using the File object readFile, the readFile object is initialized using the setInputFile method. The setInputFile method should be called before calling the readFromFile method.

(bad code)
Example Language: Java 
private File readFile = null;

public void setInputFile(String inputFile) {

// create readFile File object from string containing name of file
}

public void readFromFile() {
try {
reader = new FileReader(readFile);

// read input file
} catch (FileNotFoundException ex) {...}
}

However, the readFromFile method does not check to see if the readFile object is null, i.e. has not been initialized, before creating the FileReader object and reading from the input file. The readFromFile method should verify whether the readFile object is null and output an error message and raise an exception if the readFile object is null, as in the following code.

(good code)
Example Language: Java 
private File readFile = null;

public void setInputFile(String inputFile) {

// create readFile File object from string containing name of file
}

public void readFromFile() {
try {
if (readFile == null) {
System.err.println("Input file has not been set, call setInputFile method before calling openInputFile");
throw NullPointerException;
}

reader = new FileReader(readFile);

// read input file
} catch (FileNotFoundException ex) {...}
catch (NullPointerException ex) {...}
}
+ Observed Examples
ReferenceDescription
Unchecked return value leads to resultant integer overflow and code execution.
Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).

Phase: Implementation

Check the results of all functions that return a value and verify that the value is expected.

Effectiveness: High

Note: Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.

Phase: Implementation

If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).

Effectiveness: High

Note: Using specific exceptions, and ensuring that exceptions are checked, helps programmers to anticipate and appropriately handle many unusual events that could occur.

Phase: Implementation

Ensure that error messages only contain minimal details that are useful to the intended audience, and 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.

Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a 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.

Note: Performing extensive input validation does not help with handling unusual conditions, but it will minimize their occurrences and will make it more difficult for attackers to trigger them.

Phases: Architecture and Design; Implementation

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

Phase: Architecture and Design

Use system limits, which should help to prevent resource exhaustion. However, the software should still handle low resource conditions since they may still occur.
+ Detection Methods

Automated Static Analysis

Automated static analysis may be useful for detecting unusual conditions involving system resources or common programming idioms, but not for violations of business rules.

Effectiveness: Moderate

Manual Dynamic Analysis

Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.
+ Memberships
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.389Error Conditions, Return Values, Status Codes
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8022010 Top 25 - Risky Resource Management
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.8672011 Top 25 - Weaknesses On the Cusp
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.962SFP Secondary Cluster: Unchecked Status Condition
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

Relationship

Sometimes, when a return value can be used to indicate an error, an unchecked return value is a code-layer instance of a missing application-layer check for exceptional conditions. However, return values are not always needed to communicate exceptional conditions. For example, expiration of resources, values passed by reference, asynchronously modified data, sockets, etc. may indicate exceptional conditions without the use of a return value.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
SEI CERT Perl Coding StandardEXP31-PLCWE More AbstractDo not suppress or ignore exceptions
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Program Building Blocks" Page 341. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 1, "Exceptional Conditions," Page 22. 1st Edition. Addison Wesley. 2006.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.
[REF-622] Frank Kim. "Top 25 Series - Rank 15 - Improper Check for Unusual or Exceptional Conditions". SANS Software Security Institute. 2010-03-15. <http://blogs.sans.org/appsecstreetfighter/2010/03/15/top-25-series-rank-15-improper-check-for-unusual-or-exceptional-conditions/>.
+ Content History
Submissions
Submission DateSubmitterOrganization
2009-03-03CWE Content TeamMITRE
New entry for reorganization of CWE-703.
Modifications
Modification DateModifierOrganization
2009-07-27CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Likelihood_of_Exploit, Time_of_Introduction
2010-02-16CWE Content TeamMITRE
updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Potential_Mitigations
2010-12-13CWE Content TeamMITRE
updated Relationship_Notes
2011-03-29CWE Content TeamMITRE
updated Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2010-02-16Improper Check for Exceptional Conditions

CWE-703: Improper Check or Handling of Exceptional Conditions

Weakness ID: 703
Abstraction: Class
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the software.
+ 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
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).1000Research Concepts
ParentOfBaseBase - a weakness that is 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.166Improper Handling of Missing Special Element
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.167Improper Handling of Additional Special Element
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.168Improper Handling of Inconsistent Special Elements
ParentOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.228Improper Handling of Syntactically Invalid Structure
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.248Uncaught Exception
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.274Improper Handling of Insufficient Privileges
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.280Improper Handling of Insufficient Permissions or Privileges
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.333Improper Handling of Insufficient Entropy in TRNG
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.391Unchecked Error Condition
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.392Missing Report of Error Condition
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.393Return of Wrong Status Code
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.397Declaration of Throws for Generic Exception
ParentOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.754Improper Check for Unusual or Exceptional Conditions
ParentOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.755Improper Handling of Exceptional Conditions
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1012Cross Cutting
+ 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
ParentOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.754Improper Check for Unusual or Exceptional Conditions
ParentOfClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.755Improper Handling of Exceptional Conditions
+ 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.
Operation
+ 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
Availability
Integrity

Technical Impact: Read Application Data; DoS: Crash, Exit, or Restart; Unexpected State

+ Detection Methods

Dynamic Analysis with Manual Results Interpretation

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

Highly cost effective:
  • Fault Injection - source code
  • Fault Injection - binary
Cost effective for partial coverage:
  • Forced Path Execution

Effectiveness: High

Manual Static Analysis - Source Code

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

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

Effectiveness: High

Automated Static Analysis - Source Code

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

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

Effectiveness: SOAR Partial

Architecture or Design Review

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

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

Effectiveness: High

+ Memberships
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.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
+ Notes

Relationship

This is a high-level class that might have some overlap with other classes. It could be argued that even "normal" weaknesses such as buffer overflows involve unusual or exceptional conditions. In that sense, this might be an inherent aspect of most other weaknesses within CWE, similar to API Abuse (CWE-227) and Indicator of Poor Code Quality (CWE-398). However, this entry is currently intended to unify disparate concepts that do not have other places within the Research Concepts view (CWE-1000).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)ERR06-JDo not throw undeclared checked exceptions
+ References
[REF-567] Taimur Aslam. "A Taxonomy of Security Faults in the UNIX Operating System". 1995-08-01. <http://ftp.cerias.purdue.edu/pub/papers/taimur-aslam/aslam-taxonomy-msthesis.pdf>.
[REF-568] Taimur Aslam, Ivan Krsul and Eugene H. Spafford. "Use of A Taxonomy of Security Faults". 1995-08-01. <http://csrc.nist.gov/nissc/1996/papers/NISSC96/paper057/PAPER.PDF>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
+ Content History
Submissions
Submission DateSubmitterOrganization
2008-09-09CWE Content TeamMITRE
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2010-02-16CWE Content TeamMITRE
updated Relationships
2010-12-13CWE Content TeamMITRE
updated Name, Relationship_Notes
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Detection_Factors, Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2010-12-13Failure to Handle Exceptional Conditions

CWE-460: Improper Cleanup on Thrown Exception

Weakness ID: 460
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
+ Extended Description
Often, when functions or loops become complicated, some level of resource cleanup is needed throughout execution. Exceptions can disturb the flow of the code and prevent the necessary cleanup from happening.
+ Relationships

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.755Improper Handling of Exceptional Conditions
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.459Incomplete Cleanup
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1012Cross Cutting
+ 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
+ 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
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

C (Undetermined Prevalence)

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
Other

Technical Impact: Varies by Context

The code could be left in a bad state.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad code)
Example Language: Java 
public class foo {
public static final void main( String args[] ) {

boolean returnValue;
returnValue=doStuff();
}
public static final boolean doStuff( ) {

boolean threadLock;
boolean truthvalue=true;
try {

while(
//check some condition
) {

threadLock=true; //do some stuff to truthvalue
threadLock=false;
}
}
catch (Exception e){

System.err.println("You did something bad");
if (something) return truthvalue;
}
return truthvalue;
}
}

In this case, you may leave a thread locked accidentally.

+ Potential Mitigations

Phase: Implementation

If one breaks from a loop or function by throwing an exception, make sure that cleanup happens or that you should exit the program. Use throwing exceptions sparsely.
+ 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.851The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.961SFP Secondary Cluster: Incorrect Exception Behavior
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1141SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPImproper cleanup on thrown exception
The CERT Oracle Secure Coding Standard for Java (2011)ERR03-JRestore prior object state on method failure
The CERT Oracle Secure Coding Standard for Java (2011)ERR05-JDo not let checked exceptions escape from a finally block
SEI CERT Perl Coding StandardEXP31-PLImpreciseDo not suppress or ignore exceptions
+ Content History
Submissions
Submission DateSubmitterOrganization
CLASP
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Description, Other_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2019-01-03CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings

CWE-116: Improper Encoding or Escaping of Output

Weakness ID: 116
Abstraction: Class
Structure: Simple
Status: Draft