CWE

Common Weakness Enumeration

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

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > VIEW SLICE: CWE-1133: Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java (4.16)  
ID

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

View ID: 1133
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
Type: Graph
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
Stakeholder Description
Software Developers By 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.
Product Customers If 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.
Educators Educators 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 pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.
Show Details:
1133 - Weaknesses Addressed by the SEI CERT Oracle Coding Standard for Java
+ Category Category - 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper 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 product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved. Output Sanitization Output Validation Output Encoding
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper 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 product does not neutralize or incorrectly neutralizes output that is written to logs.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as line delimiters when they are sent to a downstream component.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper 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 product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of 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 product uses a function that accepts a format string as an argument, but the format string originates from an external source.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
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 product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Shell injection Shell metacharacters OS Command Injection
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
+ Category Category - 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper 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 product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
+ Category Category - 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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)
The product dereferences a pointer that it expects to be valid but is NULL. NPD null deref NPE nil pointer dereference
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
+ Category Category - 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number. Overflow Wraparound wrap, wrap-around, wrap around
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 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 product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
+ Category Category - 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product 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.
+ Category Category - 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product sends non-cloned mutable data as an argument to a method or function.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product declares a critical variable, field, or member to be public when intended security policy requires it to be private.
+ Category Category - 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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. assertion failure
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product uses an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.
* Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 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 product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product does not maintain equal hashcodes for equal objects.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper 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 product does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product makes an explicit call to the finalize() method from outside the finalizer.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product violates secure coding principles for mobile code by declaring a finalize() method public.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product contains a finalize() method that does not call super.finalize().
+ Category Category - 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product does not properly "clean up" and remove temporary or supporting resources after they have been used. Insufficient Cleanup
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect 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 product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper 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 product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
* Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 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 product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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.
+ Category Category - 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 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 product contains a concurrent code sequence that 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 operating concurrently. Race Condition
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper 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 product does not lock or does not correctly lock a resource when the product must have exclusive access to the resource.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper 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 product utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper 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 product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
+ Category Category - 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unrestricted 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 product properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper 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 product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing 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 product utilizes a shared resource in a concurrent manner but does not attempt to synchronize access to the resource.
+ Category Category - 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee.
+ Category Category - 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing 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 product encounters an error but does not provide a status code or return value to indicate that an error has occurred.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 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))
The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product's resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources.
* Category Category - 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.
+ Category Category - 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Incorrect Behavior Order: Validate Before Canonicalize - (180)
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)) > 180 (Incorrect Behavior Order: Validate Before Canonicalize)
The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of 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 product receives input from an upstream component, but it does not account for byte ordering (e.g. big-endian and little-endian) when processing the input, causing an incorrect number or value to be used.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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)
During installation, installed file permissions are set to allow anyone to modify those files.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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 product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Exposure of Private Personal Information to an Unauthorized Actor - (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 Personal Information to an Unauthorized Actor)
The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected. Privacy violation Privacy leak Privacy leakage
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper 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 product does not release or incorrectly releases a resource before it is made available for re-use.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 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))
The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product does not properly "clean up" and remove temporary or supporting resources after they have been used. Insufficient Cleanup
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Insertion of Sensitive Information into Log File - (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 (Insertion of Sensitive Information into Log File)
The product writes sensitive information to a log file.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of 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 product defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect 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 product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Permission Assignment for Critical Resource - (732)
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 product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
+ Category Category - 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Transmission of Sensitive Information - (319)
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 product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 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 product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources. Resource Exhaustion
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid. Marshaling, Unmarshaling Pickling, Unpickling PHP Object Injection
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
+ Category Category - 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Permission Assignment for Critical Resource - (732)
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 product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 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.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Incorrect Permission Assignment for Critical Resource - (732)
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 product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+ Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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.
+ Category Category - 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Use of 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 product contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Missing Encryption of Sensitive Data - (311)
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 product does not encrypt sensitive or critical information before storage or transmission.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Use of a Broken or Risky Cryptographic Algorithm - (327)
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 product uses a broken or risky cryptographic algorithm or protocol.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Use of 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 product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 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.
* Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 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 product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources. Resource Exhaustion
* Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Missing Release of Memory after Effective Lifetime - (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 (Missing Release of Memory after Effective Lifetime)
The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory. Memory Leak
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 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 product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
* Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Hard-coded Credentials - (798)
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 product contains hard-coded credentials, such as a password or cryptographic key.
* Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 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 Android (DRD) section of the SEI CERT Oracle Secure Coding Standard for Java.
* Category Category - 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 Concurrency (CON) section of the SEI CERT Oracle Secure Coding Standard for Java.
+ Vulnerability Mapping Notes

Usage: PROHIBITED

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

Reason: View

Rationale:

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

Comments:

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

Relationship

The relationships in this view 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 view Total CWEs
Weaknesses 88 out of 940
Categories 21 out of 374
Views 0 out of 51
Total 109 out of 1365
+ Content History
+ Submissions
Submission Date Submitter Organization
2018-12-11
(CWE 3.2, 2019-01-03)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2020-02-24 CWE Content Team MITRE
updated View_Audience
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

View Components

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

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

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

Edit Custom Filter


+ Description
The product, 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.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Access Control
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.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 345 Insufficient Verification of Data Authenticity
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1214 Data Integrity Issues
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Observed Examples
Reference Description
Does not verify that trusted entity is authoritative for all entities in its response.
use of extra data in a signature allows certificate signature forging
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 860 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 977 SFP Secondary Cluster: Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1150 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 16. Runtime Environment (ENV)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1365 ICS Communications: Unreliability
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1373 ICS Engineering (Construction/Deployment): Trust Model Problems
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1411 Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes

Usage: ALLOWED

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

Reason: Acceptable-Use

Rationale:

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

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Untrusted Data Appended with Trusted Data
The CERT Oracle Secure Coding Standard for Java (2011) ENV01-J Place all security-sensitive code in a single JAR and sign and seal it
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-07-30 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2020-02-24 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-04-28 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Modes_of_Introduction, Relationships, Time_of_Introduction
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Untrusted Data Appended with Trusted Data

CWE-770: Allocation of Resources Without Limits or Throttling

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

Edit Custom Filter


+ Description
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
+ Extended Description

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

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

Phase: Requirements

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

Phase: Implementation

Strategy: Input Validation

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

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

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

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

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

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

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

Phase: Architecture and Design

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

Phases: Architecture and Design; Implementation

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

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

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

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

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

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

+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 400 Uncontrolled Resource Consumption
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 665 Improper Initialization
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 774 Allocation of File Descriptors or Handles Without Limits or Throttling
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 789 Memory Allocation with Excessive Size Value
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1325 Improperly Controlled Sequential Memory Allocation
CanFollow Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 20 Improper Input Validation
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 399 Resource Management Errors
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 840 Business Logic Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 400 Uncontrolled Resource Consumption
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
System Configuration
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Often Prevalent)

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

Manual Static Analysis

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

Fuzzing

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

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

Effectiveness: Opportunistic

Automated Dynamic Analysis

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

Automated Static Analysis

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

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

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

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 802 2010 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 857 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 861 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 867 2011 Top 25 - Weaknesses On the Cusp
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 876 CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 877 CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 985 SFP Secondary Cluster: Unrestricted Consumption
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1147 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1148 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1152 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

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

Reason: Acceptable-Use

Rationale:

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

Comments:

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

Relationship

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

Theoretical

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

CWE-405: Asymmetric Resource Consumption (Amplification)

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

Edit Custom Filter


+ Description
The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
+ Extended Description
This can lead to poor performance due to "amplification" of resource consumption, typically in a non-linear fashion. This situation is worsened if the product allows malicious users or attackers to consume more resources than their access level permits.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Availability

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

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

Phase: System Configuration

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

Effectiveness: High

Note: Business requirements may prevent disabling resource-intensive algorithms.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 400 Uncontrolled Resource Consumption
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 406 Insufficient Control of Network Message Volume (Network Amplification)
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 407 Inefficient Algorithmic Complexity
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 408 Incorrect Behavior Order: Early Amplification
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 409 Improper Handling of Highly Compressed Data (Data Amplification)
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1050 Excessive Platform Resource Consumption within a Loop
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1072 Data Resource Access without Use of Connection Pooling
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1073 Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1084 Invokable Control Element with Excessive File or Data Access Operations
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1089 Large Data Table with Excessive Number of Indices
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1094 Excessive Index Range Scan for a Data Resource
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1176 Inefficient CPU Computation
PeerOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 404 Improper Resource Shutdown or Release
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: Client Server (Undetermined Prevalence)

+ Demonstrative Examples

Example 1

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

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

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

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


Example 2

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

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

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

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


Example 3

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

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

Example 4

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

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

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

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

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

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


Example 5

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


+ Observed Examples
Reference Description
Classic "Smurf" attack, using spoofed ICMP packets to broadcast addresses.
Parsing library allows XML bomb
Tool creates directories before authenticating user.
Python has "quadratic complexity" issue when converting string to int with many digits in unexpected bases
server allows ReDOS with crafted User-Agent strings, due to overlapping capture groups that cause excessive backtracking.
composite: NTP feature generates large responses (high amplification factor) with spoofed UDP source addresses.
Diffie-Hellman (DHE) Key Agreement Protocol allows attackers to send arbitrary numbers that are not public keys, which causes the server to perform expensive, unnecessary computation of modular exponentiation.
The Diffie-Hellman Key Agreement Protocol allows use of long exponents, which are more computationally expensive than using certain "short exponents" with particular properties.
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 730 OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 855 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 857 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 977 SFP Secondary Cluster: Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1145 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1147 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

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

Reason: Abstraction

Rationale:

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

Comments:

Examine children of this entry to see if there is a better fit
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Asymmetric resource consumption (amplification)
OWASP Top Ten 2004 A9 CWE More Specific Denial of Service
WASC 41 XML Attribute Blowup
The CERT Oracle Secure Coding Standard for Java (2011) TPS00-J Use thread pools to enable graceful degradation of service during traffic bursts
The CERT Oracle Secure Coding Standard for Java (2011) FIO04-J Release resources when they are no longer needed
+ References
[REF-1164] Ilya Kantor. "Catastrophic backtracking". 2020-12-13. <https://javascript.info/regexp-catastrophic-backtracking>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2021-11-11 Szilárd Pfeiffer Balasys IT Security
Submitted content that led to modifications in applicable platforms, common consequences, potential mitigations, demonstrative examples, observed examples.
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14 CWE Content Team MITRE
updated Description
2009-07-27 CWE Content Team MITRE
updated Common_Consequences, Other_Notes
2010-02-16 CWE Content Team MITRE
updated Taxonomy_Mappings
2010-12-13 CWE Content Team MITRE
updated Description
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-07-30 CWE Content Team MITRE
updated Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Functional_Areas
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2019-06-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Time_of_Introduction
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples

CWE-289: Authentication Bypass by Alternate Name

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

Edit Custom Filter


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

Technical Impact: Bypass Protection Mechanism

+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

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

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1390 Weak Authentication
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 46 Path Equivalence: 'filename ' (Trailing Space)
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 52 Path Equivalence: '/multiple/trailing/slash//'
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 173 Improper Handling of Alternate Encoding
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 178 Improper Handling of Case Sensitivity
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Software Development" (CWE-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1211 Authentication Errors
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Architectural Concepts" (CWE-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Observed Examples
Reference Description
Protection mechanism that restricts URL access can be bypassed using URL encoding.
Bypass of authentication for files using "\" (backslash) or "%5C" (encoded backslash).
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 845 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 947 SFP Secondary Cluster: Authentication Bypass
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1134 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes

Usage: ALLOWED

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

Reason: Acceptable-Use

Rationale:

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

Comments:

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

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 Name Node ID Fit Mapped Node Name
PLOVER Authentication bypass by alternate name
The CERT Oracle Secure Coding Standard for Java (2011) IDS01-J CWE More Specific Normalize strings before validating them
SEI CERT Oracle Coding Standard for Java IDS01-J CWE More Specific Normalize strings before validating them
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-11-24 CWE Content Team MITRE
updated Observed_Examples
2009-07-27 CWE Content Team MITRE
updated Other_Notes, Potential_Mitigations, Theoretical_Notes
2011-03-29 CWE Content Team MITRE
updated Potential_Mitigations
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-07-30 CWE Content Team MITRE
updated Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations
2022-10-13 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Type
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

CWE-589: Call to Non-ubiquitous API

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

Edit Custom Filter


+ Description
The product uses 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.
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
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.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 474 Use of Function with Inconsistent Implementations
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design
Implementation
+ Weakness Ordinalities
Ordinality Description
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Detection Methods

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 850 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1001 SFP Secondary Cluster: Use of an Improper API
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1140 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 06. Methods (MET)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1412 Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes

Usage: ALLOWED

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

Reason: Acceptable-Use

Rationale:

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

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011) MET02-J Do not use deprecated or obsolete classes or methods
The CERT Oracle Secure Coding Standard for Java (2011) SER00-J Maintain serialization compatibility during class evolution
Software Fault Patterns SFP3 Use of an improper API
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes
2008-10-14 CWE Content Team MITRE
updated Description
2009-07-27 CWE Content Team MITRE
updated Other_Notes, Potential_Mitigations
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2020-02-24 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Call to Limited API

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

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

Edit Custom Filter


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

Technical Impact: Quality Degradation; Varies by Context

+ Potential Mitigations

Phase: Implementation

Use the start() method instead of the run() method.
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 821 Incorrect Synchronization
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Java (Undetermined Prevalence)

+ 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();

+ Detection Methods

Automated Static Analysis

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

Effectiveness: High

+ Affected Resources
  • System Process
+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 854 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - Thread APIs (THI)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1001 SFP Secondary Cluster: Use of an Improper API
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1144 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 10. Thread APIs (THI)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1401 Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes

Usage: ALLOWED

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

Reason: Acceptable-Use

Rationale:

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

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011) THI00-J Do not invoke Thread.run()
Software Fault Patterns SFP3 Use of an improper API
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-12-15
(CWE Draft 5, 2006-12-15)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification Date Modifier Organization
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes
2009-05-27 CWE Content Team MITRE
updated Demonstrative_Examples
2009-07-27 CWE Content Team MITRE
updated Description, Other_Notes
2010-09-27 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2020-02-24 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Call to Thread.run()

CWE-319: Cleartext Transmission of Sensitive Information

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

Edit Custom Filter


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

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

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

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

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

Technical Impact: Read Application Data; Modify Files or Directories

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

Phase: Architecture and Design

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Testing

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

Phase: Operation

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

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

Class: System on Chip (Undetermined Prevalence)

Test/Debug Hardware (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

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

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

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


Example 2

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

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


Example 3

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


Example 4

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

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

The JSON result might be:

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

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

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

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

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

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

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

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


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

Black Box

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

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

Automated Static Analysis

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

Effectiveness: High

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

Usage: ALLOWED

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

Reason: Acceptable-Use

Rationale:

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

Comments:

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

Maintenance

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