Home > CWE List > VIEW SLICE: CWE-844: Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011) (4.15) |
|
CWE VIEW: Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)
CWE entries in this view (graph) are fully or partially eliminated by following the guidance presented in the book "The CERT Oracle Secure Coding Standard for Java" published in 2011. This view is considered obsolete as a newer version of the coding standard is available.
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:
844 - Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)
Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS) - (845) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)) Weaknesses in this category are related to rules in the Input Validation and Data Sanitization (IDS) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - 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 SanitizationOutput ValidationOutput Encoding 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Permissive Regular Expression - (625) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)) > 625 (Permissive Regular Expression) The product uses a regular expression that does not sufficiently restrict the set of allowed values. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)) > 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - 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 injectionShell metacharactersOS Command Injection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 845 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)) > 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 - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 3 - Declarations and Initialization (DCL) - (846) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 846 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 3 - Declarations and Initialization (DCL)) Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 846 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 3 - 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 - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP) - (847) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 847 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP)) Weaknesses in this category are related to rules in the Expressions (EXP) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 847 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - 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. 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.Signal Handler Use of a Non-reentrant Function - (479) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 847 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - Expressions (EXP)) > 479 (Signal Handler Use of a Non-reentrant Function) The product defines a signal handler that calls a non-reentrant function. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 847 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 847 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 4 - 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. Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM) - (848) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 848 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM)) Weaknesses in this category are related to rules in the Numeric Types and Operations (NUM) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 848 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 848 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - Numeric Types and Operations (NUM)) > 369 (Divide By Zero) The product divides a value by zero. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 848 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 5 - 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. Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ) - (849) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)) Weaknesses in this category are related to rules in the Object Orientation (OBJ) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Critical Public Variable Without Final Modifier - (493) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)) > 493 (Critical Public Variable Without Final Modifier) The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - 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. 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.Array Declared Public, Final, and Static - (582) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - Object Orientation (OBJ)) > 582 (Array Declared Public, Final, and Static) The product declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 849 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 6 - 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 - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET) - (850) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) Weaknesses in this category are related to rules in the Methods (MET) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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.Reliance on Package-level Scope - (487) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 487 (Reliance on Package-level Scope) Java packages are not inherently closed; therefore, relying on them for code security is not a good practice. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 568 (finalize() Method Without super.finalize()) The product contains a finalize() method that does not call super.finalize(). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 581 (Object Model Violation: Just One of Equals and Hashcode Defined) The product does not maintain equal hashcodes for equal objects. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 583 (finalize() Method Declared Public) The product violates secure coding principles for mobile code by declaring a finalize() method public. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - Methods (MET)) > 586 (Explicit Call to Finalize()) The product makes an explicit call to the finalize() method from outside the finalizer. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 850 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 7 - 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 Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR) - (851) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) Weaknesses in this category are related to rules in the Exceptional Behavior (ERR) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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.Generation of Error Message Containing Sensitive Information - (209) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 209 (Generation of Error Message Containing Sensitive Information) The product generates an error message that includes sensitive information about its environment, users, or associated data. 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 Missing Values - (230) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 230 (Improper Handling of Missing Values) The product does not handle or incorrectly handles when a parameter, field, or argument name is specified, but the associated value is missing, i.e. it is empty, blank, or null. 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 Undefined Values - (232) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 232 (Improper Handling of Undefined Values) The product does not handle or incorrectly handles when a value is not defined or supported for the associated parameter, field, or argument name. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 248 (Uncaught Exception) An exception is thrown from a function, but it is not caught. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 382 (J2EE Bad Practices: Use of System.exit()) A J2EE application uses System.exit(), which also shuts down its container. 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.Detection of Error Condition Without Action - (390) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 390 (Detection of Error Condition Without Action) The product detects a specific error, but takes no actions to handle the error. 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 NullPointerException Catch to Detect NULL Pointer Dereference - (395) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 395 (Use of NullPointerException Catch to Detect NULL Pointer Dereference) Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Exposure of Sensitive System Information to an Unauthorized Control Sphere - (497) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 497 (Exposure of Sensitive System Information to an Unauthorized Control Sphere) The product does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - 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. 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.Uncaught Exception in Servlet - (600) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 600 (Uncaught Exception in Servlet ) The Servlet does not catch all exceptions, which may reveal sensitive debugging information.Missing Catch Block Chain - a Compound Element that is a sequence of two or more separate weaknesses that can be closely linked together within software. One weakness, X, can directly create the conditions that are necessary to cause another weakness, Y, to enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y, and Y is "resultant" from X. Chains can involve more than two weaknesses, and in some cases, they might have a tree-like structure.Unchecked Return Value to NULL Pointer Dereference - (690) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - Exceptional Behavior (ERR)) > 690 (Unchecked Return Value to NULL Pointer Dereference) The product does not check for an error after calling a function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 851 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 8 - 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. Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA) - (852) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 852 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)) Weaknesses in this category are related to rules in the Visibility and Atomicity (VNA) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 852 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')) The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 852 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 852 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 852 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 852 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 852 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - 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 - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK) - (853) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)) Weaknesses in this category are related to rules in the Locking (LCK) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)) > 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - 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. 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.Deadlock - (833) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 853 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 10 - Locking (LCK)) > 833 (Deadlock) The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock. Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - Thread APIs (THI) - (854) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 854 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - Thread APIs (THI)) Weaknesses in this category are related to rules in the Thread APIs (THI) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 854 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 854 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 11 - Thread APIs (THI)) > 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. Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS) - (855) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 855 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS)) Weaknesses in this category are related to rules in the Thread Pools (TPS) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 855 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 855 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 855 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - 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 - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 13 - Thread-Safety Miscellaneous (TSM) - (856) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 856 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 13 - Thread-Safety Miscellaneous (TSM)) Weaknesses in this category are related to rules in the Thread-Safety Miscellaneous (TSM) chapter of The CERT Oracle Secure Coding Standard for Java (2011). Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO) - (857) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) Weaknesses in this category are related to rules in the Input Output (FIO) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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 Calculation of Multi-Byte String Length - (135) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) > 135 (Incorrect Calculation of Multi-Byte String Length) The product does not correctly calculate the length of strings that can contain wide or multi-byte characters. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) > 276 (Incorrect Default Permissions) During installation, installed file permissions are set to allow anyone to modify those files. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - 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 violationPrivacy leakPrivacy leakage 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) > 377 (Insecure Temporary File) Creating and using insecure temporary files can leave application and system data vulnerable to attack. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)) > 532 (Insertion of Sensitive Information into Log File) Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 857 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - 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 - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER) - (858) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 858 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)) Weaknesses in this category are related to rules in the Serialization (SER) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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.Execution with Unnecessary Privileges - (250) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 858 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)) > 250 (Execution with Unnecessary Privileges) The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 858 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 858 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 858 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 858 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)) > 502 (Deserialization of Untrusted Data) The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.Marshaling, UnmarshalingPickling, UnpicklingPHP Object Injection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 858 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)) > 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 858 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - 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 - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC) - (859) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)) Weaknesses in this category are related to rules in the Platform Security (SEC) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)) > 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. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Channel Accessible by Non-Endpoint - (300) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)) > 300 (Channel Accessible by Non-Endpoint) The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint.Adversary-in-the-Middle / AITMMan-in-the-Middle / MITMPerson-in-the-Middle / PITMMonkey-in-the-MiddleMonster-in-the-MiddleManipulator-in-the-MiddleOn-path attackInterception attack 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 Assumed-Immutable Data - (302) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)) > 302 (Authentication Bypass by Assumed-Immutable Data) The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)) > 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. 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 Verification of Cryptographic Signature - (347) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)) > 347 (Improper Verification of Cryptographic Signature) The product does not verify, or incorrectly verifies, the cryptographic signature for data. 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 Input to Select Classes or Code ('Unsafe Reflection') - (470) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)) > 470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')) The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.Reflection Injection 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.Download of Code Without Integrity Check - (494) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)) > 494 (Download of Code Without Integrity Check) The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - 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. 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.Reliance on Untrusted Inputs in a Security Decision - (807) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 859 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)) > 807 (Reliance on Untrusted Inputs in a Security Decision) The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism. Category - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV) - (860) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 860 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - Runtime Environment (ENV)) Weaknesses in this category are related to rules in the Runtime Environment (ENV) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 860 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 860 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 17 - 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 - a CWE entry that contains a set of other entries that share a common characteristic.The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC) - (861) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)) Weaknesses in this category are related to rules in the Miscellaneous (MSC) chapter of The CERT Oracle Secure Coding Standard for Java (2011). 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)) > 311 (Missing Encryption of Sensitive Data) The product does not encrypt sensitive or critical information before storage or transmission. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Improper Handling of Insufficient Entropy in TRNG - (333) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)) > 333 (Improper Handling of Insufficient Entropy in TRNG) True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - 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 - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - 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 - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - 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 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 Singleton Pattern Without Synchronization in a Multithreaded Context - (543) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)) > 543 (Use of Singleton Pattern Without Synchronization in a Multithreaded Context) The product uses the singleton pattern when creating a resource within a multithreaded environment. 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - 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 - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 844 (Weaknesses Addressed by The CERT Oracle Secure Coding Standard for Java (2011)) > 861 (The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)) > 798 (Use of Hard-coded Credentials) The product contains hard-coded credentials, such as a password or cryptographic key.
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.
View ComponentsA | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence)
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-770: Allocation of Resources Without Limits or Throttling
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product 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. 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. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Often Prevalent) Example 1 This code allocates a socket and forks each time it receives a new connection. (bad code) Example Language: C 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: C 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: C /* 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: C 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 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: C bar connection() {
foo = malloc(1024); }return foo; endConnection(bar foo) { free(foo); }int main() { while(1) { }foo=connection(); }endConnection(foo)
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Relationship This 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.
CWE-582: Array Declared Public, Final, and Static
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified. Because arrays are mutable objects, the final constraint requires that the array object itself be assigned only once, but makes no guarantees about the values of the array elements. Since the array is public, a malicious program can change the values stored in the array. As such, in most cases an array declared public, final and static is a bug. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Java (Undetermined Prevalence) Example 1 The following Java Applet code mistakenly declares an array public, final and static. (bad code) Example Language: Java public final class urlTool extends Applet {
public final static URL[] urls; }...
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-405: Asymmetric Resource Consumption (Amplification)
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not properly 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." 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. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. 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) 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.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-289: Authentication Bypass by Alternate Name
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product performs 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. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence)
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Relationship 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.
CWE-302: Authentication Bypass by Assumed-Immutable Data
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence) Example 1 In the following example, an "authenticated" cookie is used to determine whether or not a user should be granted access to a system. (bad code) Example Language: Java boolean authenticated = new Boolean(getCookieValue("authenticated")).booleanValue();
if (authenticated) { ... }Modifying the value of a cookie on the client-side is trivial, but many developers assume that cookies are essentially immutable.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-589: Call to Non-ubiquitous API
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses 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. 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. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-572: Call to Thread run() instead of start()
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product 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. 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. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Java (Undetermined Prevalence) 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();
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-300: Channel Accessible by Non-Endpoint
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint. In order to establish secure communication between two parties, it is often important to adequately verify the identity of entities at each end of the communication channel. Inadequate or inconsistent verification may result in insufficient or incorrect identification of either communicating entity. This can have negative consequences such as misplaced trust in the entity at the other end of the channel. An attacker can leverage this by interposing between the communicating entities and masquerading as the original entity. In the absence of sufficient verification of identity, such an attacker can eavesdrop and potentially modify the communication between the original entities.
This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence) Example 1 In the Java snippet below, data is sent over an unencrypted channel to a remote server. (bad code) Example Language: Java Socket sock;
PrintWriter out; try { sock = new Socket(REMOTE_HOST, REMOTE_PORT);
out = new PrintWriter(echoSocket.getOutputStream(), true); // Write data to remote host via socket output stream. ... By eavesdropping on the communication channel or posing as the endpoint, an attacker would be able to read all of the transmitted data.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Maintenance The summary identifies multiple distinct possibilities, suggesting that this is a category that must be broken into more specific weaknesses.
CWE-319: Cleartext Transmission of Sensitive Information
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors. 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. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Hardware Design" (CWE-1194)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. 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) 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:
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Maintenance 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.
CWE-498: Cloneable Class Containing Sensitive Information
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe code contains a class with sensitive data, but the class is cloneable. The data can then be accessed by cloning the class. Cloneable classes are effectively open classes, since data cannot be hidden in them. Classes that do not explicitly deny cloning can be cloned by any other class without running the constructor. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C++ (Undetermined Prevalence) Java (Undetermined Prevalence) C# (Undetermined Prevalence) Example 1 The following example demonstrates the weakness. (bad code) Example Language: Java public class CloneClient {
public CloneClient() //throws
java.lang.CloneNotSupportedException { Teacher t1 = new Teacher("guddu","22,nagar road"); //... // Do some stuff to remove the teacher. Teacher t2 = (Teacher)t1.clone(); System.out.println(t2.name); public static void main(String args[]) { new CloneClient(); class Teacher implements Cloneable { public Object clone() { try { return super.clone(); }catch (java.lang.CloneNotSupportedException e) { throw new RuntimeException(e.toString()); public String name; public String clas; public Teacher(String name,String clas) { this.name = name; this.clas = clas; Make classes uncloneable by defining a clone function like: (good code) Example Language: Java public final void clone() throws java.lang.CloneNotSupportedException {
throw new java.lang.CloneNotSupportedException(); }This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-182: Collapse of Data into Unsafe Value
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence)
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Relationship Overlaps regular expressions, although an implementation might not necessarily use regexp's.
CWE-486: Comparison of Classes by Name
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name. If the decision to trust the methods and data of an object is based on the name of a class, it is possible for malicious users to send objects of the same name as trusted classes and thereby gain the trust afforded to known classes and types. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Java (Undetermined Prevalence) Example 1 In this example, the expression in the if statement compares the class of the inputClass object to a trusted class by comparing the class names. (bad code) Example Language: Java if (inputClass.getClass().getName().equals("TrustedClassName")) {
// Do something assuming you trust inputClass // ... However, multiple classes can have the same name therefore comparing an object's class by name can allow untrusted classes of the same name as the trusted class to be use to execute unintended or incorrect code. To compare the class of an object to the intended class the getClass() method and the comparison operator "==" should be used to ensure the correct trusted class is used, as shown in the following example. (good code) Example Language: Java if (inputClass.getClass() == TrustedClass.class) {
// Do something assuming you trust inputClass // ... Example 2 In this example, the Java class, TrustedClass, overrides the equals method of the parent class Object to determine equivalence of objects of the class. The overridden equals method first determines if the object, obj, is the same class as the TrustedClass object and then compares the object's fields to determine if the objects are equivalent. (bad code) Example Language: Java public class TrustedClass {
...
@Override public boolean equals(Object obj) { boolean isEquals = false;
// first check to see if the object is of the same class if (obj.getClass().getName().equals(this.getClass().getName())) { // then compare object fields ... if (...) { isEquals = true; }return isEquals; ... However, the equals method compares the class names of the object, obj, and the TrustedClass object to determine if they are the same class. As with the previous example using the name of the class to compare the class of objects can lead to the execution of unintended or incorrect code if the object passed to the equals method is of another class with the same name. To compare the class of an object to the intended class, the getClass() method and the comparison operator "==" should be used to ensure the correct trusted class is used, as shown in the following example. (good code) Example Language: Java public boolean equals(Object obj) {
...
// first check to see if the object is of the same class if (obj.getClass() == this.getClass()) { ... }...
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-595: Comparison of Object References Instead of Object Contents
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects. For example, in Java, comparing objects using == usually produces deceptive results, since the == operator compares object references rather than values; often, this means that using == for strings is actually comparing the strings' references, not their values. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Java (Undetermined Prevalence) JavaScript (Undetermined Prevalence) PHP (Undetermined Prevalence) Class: Not Language-Specific (Undetermined Prevalence) Example 1 In the example below, two Java String objects are declared and initialized with the same string values. An if statement is used to determine if the strings are equivalent. (bad code) Example Language: Java String str1 = new String("Hello");
String str2 = new String("Hello"); if (str1 == str2) { System.out.println("str1 == str2"); }However, the if statement will not be executed as the strings are compared using the "==" operator. For Java objects, such as String objects, the "==" operator compares object references, not object values. While the two String objects above contain the same string values, they refer to different object references, so the System.out.println statement will not be executed. To compare object values, the previous code could be modified to use the equals method: (good code) if (str1.equals(str2)) {
System.out.println("str1 equals str2"); }Example 2 In the following Java example, two BankAccount objects are compared in the isSameAccount method using the == operator. (bad code) Example Language: Java public boolean isSameAccount(BankAccount accountA, BankAccount accountB) {
return accountA == accountB; }Using the == operator to compare objects may produce incorrect or deceptive results by comparing object references rather than values. The equals() method should be used to ensure correct results or objects should contain a member variable that uniquely identifies the object. The following example shows the use of the equals() method to compare the BankAccount objects and the next example uses a class get method to retrieve the bank account number that uniquely identifies the BankAccount object to compare the objects. (good code) Example Language: Java public boolean isSameAccount(BankAccount accountA, BankAccount accountB) {
return accountA.equals(accountB); }
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider. A race condition occurs within concurrent environments, and is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc. A race condition violates these properties, which are closely related:
A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity. Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x). The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Sometimes Prevalent) C++ (Sometimes Prevalent) Java (Sometimes Prevalent) Technologies Class: Mobile (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence) Example 1 This code could be used in an e-commerce application that supports transfers between accounts. It takes the total amount of the transfer, sends it to the new account, and deducts the amount from the original account. (bad code) Example Language: Perl $transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase(); if ($transfer_amount < 0) { FatalError("Bad Transfer Amount"); }$newbalance = $balance - $transfer_amount; if (($balance - $transfer_amount) < 0) { FatalError("Insufficient Funds"); }SendNewBalanceToDatabase($newbalance); NotifyUser("Transfer of $transfer_amount succeeded."); NotifyUser("New balance: $newbalance"); A race condition could occur between the calls to GetBalanceFromDatabase() and SendNewBalanceToDatabase(). Suppose the balance is initially 100.00. An attack could be constructed as follows: (attack code) Example Language: Other In the following pseudocode, the attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2. Both callers are for the same user account.
CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles CALLER-1). CALLER-2 is associated with PROGRAM-2. CALLER-1 makes a transfer request of 80.00. PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00 PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase(). Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase() encounters a delay. CALLER-2 makes a transfer request of 1.00. PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This happens because the previous PROGRAM-1 request was not processed yet. PROGRAM-2 determines the new balance as 99.00. After the initial delay, PROGRAM-1 commits its balance to the database, setting it to 20.00. PROGRAM-2 sends a request to update the database, setting the balance to 99.00 At this stage, the attacker should have a balance of 19.00 (due to 81.00 worth of transfers), but the balance is 99.00, as recorded in the database. To prevent this weakness, the programmer has several options, including using a lock to prevent multiple simultaneous requests to the web application, or using a synchronization mechanism that includes all the code between GetBalanceFromDatabase() and SendNewBalanceToDatabase(). Example 2 The following function attempts to acquire a lock in order to perform operations on a shared resource. (bad code) Example Language: C void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);
/* access shared resource */ pthread_mutex_unlock(mutex); However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior. In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels. (good code) Example Language: C int f(pthread_mutex_t *mutex) {
int result;
result = pthread_mutex_lock(mutex); if (0 != result) return result;
/* access shared resource */ return pthread_mutex_unlock(mutex); Example 3 Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs. Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Research Gap Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing interest in this area. Research Gap Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many race conditions are related to synchronization problems that do not necessarily require a time-of-check. Research Gap From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues. Maintenance The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.
CWE-766: Critical Data Element Declared Public
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product declares a critical variable, field, or member to be public when intended security policy requires it to be private. This issue makes it more difficult to maintain the product, which indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities. It also might make it easier to introduce vulnerabilities. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C++ (Undetermined Prevalence) C# (Undetermined Prevalence) Java (Undetermined Prevalence) Example 1 The following example declares a critical variable public, making it accessible to anyone with access to the object in which it is contained. (bad code) Example Language: C++ public: char* password;
Instead, the critical data should be declared private. (good code) Example Language: C++ private: char* password;
Even though this example declares the password to be private, there are other possible issues with this implementation, such as the possibility of recovering the password from process memory (CWE-257). Example 2 The following example shows a basic user account class that includes member variables for the username and password as well as a public constructor for the class and a public method to authorize access to the user account. (bad code) Example Language: C++ #define MAX_PASSWORD_LENGTH 15
#define MAX_USERNAME_LENGTH 15 class UserAccount { public:
UserAccount(char *username, char *password)
{ if ((strlen(username) > MAX_USERNAME_LENGTH) || }(strlen(password) > MAX_PASSWORD_LENGTH)) { ExitError("Invalid username or password"); }strcpy(this->username, username); strcpy(this->password, password); int authorizeAccess(char *username, char *password) { if ((strlen(username) > MAX_USERNAME_LENGTH) ||
(strlen(password) > MAX_PASSWORD_LENGTH)) { ExitError("Invalid username or password"); }// if the username and password in the input parameters are equal to // the username and password of this account class then authorize access if (strcmp(this->username, username) || strcmp(this->password, password)) return 0;
// otherwise do not authorize access else return 1;
char username[MAX_USERNAME_LENGTH+1]; char password[MAX_PASSWORD_LENGTH+1]; However, the member variables username and password are declared public and therefore will allow access and changes to the member variables to anyone with access to the object. These member variables should be declared private as shown below to prevent unauthorized access and changes. (good code) Example Language: C++ class UserAccount
{ public: ...
private: char username[MAX_USERNAME_LENGTH+1]; };char password[MAX_PASSWORD_LENGTH+1];
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-493: Critical Public Variable Without Final Modifier
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values. If a field is non-final and public, it can be changed once the value is set by any function that has access to the class which contains the field. This could lead to a vulnerability if other parts of the program make assumptions about the contents of that field. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Java (Undetermined Prevalence) C++ (Undetermined Prevalence) Example 1 Suppose this WidgetData class is used for an e-commerce web site. The programmer attempts to prevent price-tampering attacks by setting the price of the widget using the constructor. (bad code) Example Language: Java public final class WidgetData extends Applet {
public float price; }... public WidgetData(...) { this.price = LookupPrice("MyWidgetType"); }The price field is not final. Even though the value is set by the constructor, it could be modified by anybody that has access to an instance of WidgetData. Example 2 Assume the following code is intended to provide the location of a configuration file that controls execution of the application. (bad code) Example Language: C++ public string configPath = "/etc/application/config.dat";
(bad code) Example Language: Java public String configPath = new String("/etc/application/config.dat");
While this field is readable from any function, and thus might allow an information leak of a pathname, a more serious problem is that it can be changed by any function.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
|