CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-844: Weaknesses Addressed by the CERT Java Secure Coding Standard (3.0)  
ID

CWE VIEW: Weaknesses Addressed by the CERT Java Secure Coding Standard

View ID: 844
Type: Graph
Status: Incomplete
+ Objective
CWE entries in this view (graph) are fully or partially eliminated by following the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this view is incomplete.
+ Audience
StakeholderDescription
Software DevelopersBy following the CERT Java Secure Coding Standard, developers will be able to fully or partially prevent the weaknesses that are identified in this view. In addition, developers can use a CWE coverage graph to determine which weaknesses are not directly addressed by the standard, which will help identify and resolve remaining gaps in training, tool acquisition, or other approaches for reducing weaknesses.
Software CustomersIf a software developer claims to be following the CERT Java Secure Coding standard, then customers can search for the weaknesses in this view in order to formulate independent evidence of that claim.
EducatorsEducators can use this view in multiple ways. For example, if there is a focus on teaching weaknesses, the educator could link them to the relevant Secure Coding Standard.
+ Relationships
Show Details:
844 - Weaknesses Addressed by the CERT Java Secure Coding Standard
+CategoryCategoryCERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS) - (845)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS))
Weaknesses in this category are related to rules in the Input Validation and Data Sanitization section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassImproper Encoding or Escaping of Output - (116)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 116 (Improper Encoding or Escaping of Output)
The software prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.Output SanitizationOutput ValidationOutput Encoding
*BaseBaseUse of Externally-Controlled Format String - (134)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 134 (Use of Externally-Controlled Format String)
The software uses a function that accepts a format string as an argument, but the format string originates from an external source.
*VariantVariantImproper Neutralization of Line Delimiters - (144)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 144 (Improper Neutralization of Line Delimiters)
The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as line delimiters when they are sent to a downstream component.
*VariantVariantImproper Neutralization of Escape, Meta, or Control Sequences - (150)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 150 (Improper Neutralization of Escape, Meta, or Control Sequences)
The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.
*CategoryCategoryCleansing, Canonicalization, and Comparison Errors - (171)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 171 (Cleansing, Canonicalization, and Comparison Errors)
Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform neutralization for untrusted data.
*BaseBaseIncorrect Behavior Order: Validate Before Canonicalize - (180)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 180 (Incorrect Behavior Order: Validate Before Canonicalize)
The software validates input before it is canonicalized, which prevents the software from detecting data that becomes invalid after the canonicalization step.
*BaseBaseCollapse of Data into Unsafe Value - (182)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 182 (Collapse of Data into Unsafe Value)
The software filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
*VariantVariantAuthentication Bypass by Alternate Name - (289)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 289 (Authentication Bypass by Alternate Name)
The software performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
*BaseBaseImproper Handling of Highly Compressed Data (Data Amplification) - (409)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 409 (Improper Handling of Highly Compressed Data (Data Amplification))
The software does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
*BaseBasePermissive Regular Expression - (625)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - 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.
*VariantVariantUse of Non-Canonical URL Paths for Authorization Decisions - (647)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 647 (Use of Non-Canonical URL Paths for Authorization Decisions)
The software defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.
*BaseBaseImproper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The software constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.Shell injectionShell metacharacters
*BaseBaseInappropriate Encoding for Output Context - (838)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 845 (CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)) > 838 (Inappropriate Encoding for Output Context)
The software uses or specifies an encoding when generating output to a downstream component, but the specified encoding is not the same as the encoding that is expected by the downstream component.
+CategoryCategoryCERT Java Secure Coding Section 01 - Declarations and Initialization (DCL) - (846)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 846 (CERT Java Secure Coding Section 01 - Declarations and Initialization (DCL))
Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassImproper Initialization - (665)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 846 (CERT Java Secure Coding Section 01 - Declarations and Initialization (DCL)) > 665 (Improper Initialization)
The software does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
+CategoryCategoryCERT Java Secure Coding Section 02 - Expressions (EXP) - (847)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 847 (CERT Java Secure Coding Section 02 - Expressions (EXP))
Weaknesses in this category are related to rules in the Expressions (EXP) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseUnchecked Return Value - (252)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 847 (CERT Java Secure Coding Section 02 - Expressions (EXP)) > 252 (Unchecked Return Value)
The software does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
*VariantVariantSignal Handler Use of a Non-reentrant Function - (479)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 847 (CERT Java Secure Coding Section 02 - Expressions (EXP)) > 479 (Signal Handler Use of a Non-reentrant Function)
The program defines a signal handler that calls a non-reentrant function.
*BaseBaseComparison of Object References Instead of Object Contents - (595)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 847 (CERT Java Secure Coding Section 02 - Expressions (EXP)) > 595 (Comparison of Object References Instead of Object Contents)
The program compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
*VariantVariantUse of Wrong Operator in String Comparison - (597)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 847 (CERT Java Secure Coding Section 02 - Expressions (EXP)) > 597 (Use of Wrong Operator in String Comparison)
The product uses the wrong operator when comparing a string, such as using "==" when the equals() method should be used instead.
+CategoryCategoryCERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM) - (848)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 848 (CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM))
Weaknesses in this category are related to rules in the Numeric Types and Operations (NUM) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseNumeric Truncation Error - (197)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 848 (CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM)) > 197 (Numeric Truncation Error)
Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion.
*BaseBaseDivide By Zero - (369)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 848 (CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM)) > 369 (Divide By Zero)
The product divides a value by zero.
*ClassClassIncorrect Conversion between Numeric Types - (681)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 848 (CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM)) > 681 (Incorrect Conversion between Numeric Types)
When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur.
+CategoryCategoryCERT Java Secure Coding Section 04 - Object Orientation (OBJ) - (849)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ))
Weaknesses in this category are related to rules in the Object Orientation (OBJ) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBasePassing Mutable Objects to an Untrusted Method - (374)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 374 (Passing Mutable Objects to an Untrusted Method)
The program sends non-cloned mutable data as an argument to a method or function.
*BaseBaseReturning a Mutable Object to an Untrusted Caller - (375)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - 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.
*VariantVariantComparison of Classes by Name - (486)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 486 (Comparison of Classes by Name)
The program compares classes by name, which can cause it to use the wrong class when multiple classes can have the same name.
*VariantVariantPublic cloneable() Method Without Final ('Object Hijack') - (491)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - 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.
*VariantVariantUse of Inner Class Containing Sensitive Data - (492)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - 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.
*VariantVariantCritical Public Variable Without Final Modifier - (493)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - 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.
*VariantVariantCloneable Class Containing Sensitive Information - (498)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - 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.
*VariantVariantPublic Static Field Not Marked Final - (500)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - 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.
*VariantVariantArray Declared Public, Final, and Static - (582)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 582 (Array Declared Public, Final, and Static)
The program declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified.
*VariantVariantCritical Variable Declared Public - (766)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 849 (CERT Java Secure Coding Section 04 - Object Orientation (OBJ)) > 766 (Critical Variable Declared Public)
The software declares a critical variable or field to be public when intended security policy requires it to be private.
+CategoryCategoryCERT Java Secure Coding Section 05 - Methods (MET) - (850)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET))
Weaknesses in this category are related to rules in the Methods (MET) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*VariantVariantReliance on Package-level Scope - (487)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - 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.
*VariantVariantfinalize() Method Without super.finalize() - (568)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 568 (finalize() Method Without super.finalize())
The software contains a finalize() method that does not call super.finalize().
*ClassClassImproper Following of Specification by Caller - (573)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 573 (Improper Following of Specification by Caller)
The software does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.
*BaseBaseObject Model Violation: Just One of Equals and Hashcode Defined - (581)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 581 (Object Model Violation: Just One of Equals and Hashcode Defined)
The software does not maintain equal hashcodes for equal objects.
*VariantVariantfinalize() Method Declared Public - (583)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 583 (finalize() Method Declared Public)
The program violates secure coding principles for mobile code by declaring a finalize() method public.
*VariantVariantExplicit Call to Finalize() - (586)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 586 (Explicit Call to Finalize())
The software makes an explicit call to the finalize() method from outside the finalizer.
*VariantVariantCall to Non-ubiquitous API - (589)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - Methods (MET)) > 589 (Call to Non-ubiquitous API)
The software uses an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.
*VariantVariantReachable Assertion - (617)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 850 (CERT Java Secure Coding Section 05 - 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.
+CategoryCategoryCERT Java Secure Coding Section 06 - Exceptional Behavior (ERR) - (851)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR))
Weaknesses in this category are related to rules in the Exceptional Behavior (ERR) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseInformation Exposure Through an Error Message - (209)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 209 (Information Exposure Through an Error Message)
The software generates an error message that includes sensitive information about its environment, users, or associated data.
*VariantVariantImproper Handling of Missing Values - (230)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 230 (Improper Handling of Missing Values)
The software 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.
*VariantVariantImproper Handling of Undefined Values - (232)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 232 (Improper Handling of Undefined Values)
The software does not handle or incorrectly handles when a value is not defined or supported for the associated parameter, field, or argument name.
*BaseBaseUncaught Exception - (248)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 248 (Uncaught Exception)
An exception is thrown from a function, but it is not caught.
*VariantVariantJ2EE Bad Practices: Use of System.exit() - (382)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 382 (J2EE Bad Practices: Use of System.exit())
A J2EE application uses System.exit(), which also shuts down its container.
*ClassClassDetection of Error Condition Without Action - (390)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 390 (Detection of Error Condition Without Action)
The software detects a specific error, but takes no actions to handle the error.
*BaseBaseUse of NullPointerException Catch to Detect NULL Pointer Dereference - (395)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - 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.
*BaseBaseDeclaration of Throws for Generic Exception - (397)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - 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.
*VariantVariantImproper Cleanup on Thrown Exception - (460)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - 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.
*VariantVariantExposure of System Data to an Unauthorized Control Sphere - (497)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 497 (Exposure of System Data to an Unauthorized Control Sphere)
Exposing system data or debugging information helps an adversary learn about the system and form an attack plan.
*BaseBaseReturn Inside Finally Block - (584)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - 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.
*BaseBaseUncaught Exception in Servlet - (600)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 600 (Uncaught Exception in Servlet )
The Servlet does not catch all exceptions, which may reveal sensitive debugging information.Missing Catch Block
*ChainChainUnchecked Return Value to NULL Pointer Dereference - (690)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - 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.
*ClassClassImproper Check or Handling of Exceptional Conditions - (703)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 703 (Improper Check or Handling of Exceptional Conditions)
The software does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the software.
*ClassClassIncorrect Control Flow Scoping - (705)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 851 (CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)) > 705 (Incorrect Control Flow Scoping)
The software does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
+CategoryCategoryCERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA) - (852)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA))
Weaknesses in this category are related to rules in the Visibility and Atomicity (VNA) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
*BaseBaseRace Condition within a Thread - (366)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - 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.
*BaseBaseImproper Resource Locking - (413)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)) > 413 (Improper Resource Locking)
The software does not lock or does not correctly lock a resource when the software must have exclusive access to the resource.
*BaseBaseUnsynchronized Access to Shared Data in a Multithreaded Context - (567)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - 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.
*BaseBaseImproper Synchronization - (662)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)) > 662 (Improper Synchronization)
The software attempts to use a shared resource in an exclusive manner, but does not prevent or incorrectly prevents use of the resource by another thread or process.
*BaseBaseImproper Locking - (667)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 852 (CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)) > 667 (Improper Locking)
The software does not properly acquire a lock on a resource, or it does not properly release a lock on a resource, leading to unexpected resource state changes and behaviors.
+CategoryCategoryCERT Java Secure Coding Section 08 - Locking (LCK) - (853)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK))
Weaknesses in this category are related to rules in the Locking (LCK) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseUnrestricted Externally Accessible Lock - (412)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 412 (Unrestricted Externally Accessible Lock)
The software properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control.
*BaseBaseImproper Resource Locking - (413)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 413 (Improper Resource Locking)
The software does not lock or does not correctly lock a resource when the software must have exclusive access to the resource.
*BaseBaseDouble-Checked Locking - (609)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 609 (Double-Checked Locking)
The program uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.
*BaseBaseImproper Locking - (667)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 667 (Improper Locking)
The software does not properly acquire a lock on a resource, or it does not properly release a lock on a resource, leading to unexpected resource state changes and behaviors.
*BaseBaseMissing Synchronization - (820)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 820 (Missing Synchronization)
The software utilizes a shared resource in a concurrent manner but does not attempt to synchronize access to the resource.
*BaseBaseDeadlock - (833)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 853 (CERT Java Secure Coding Section 08 - Locking (LCK)) > 833 (Deadlock)
The software contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.
+CategoryCategoryCERT Java Secure Coding Section 09 - Thread APIs (THI) - (854)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 854 (CERT Java Secure Coding Section 09 - Thread APIs (THI))
Weaknesses in this category are related to rules in the Thread APIs (THI) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*VariantVariantCall to Thread run() instead of start() - (572)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 854 (CERT Java Secure Coding Section 09 - Thread APIs (THI)) > 572 (Call to Thread run() instead of start())
The program calls a thread's run() method instead of calling start(), which causes the code to run in the thread of the caller instead of the callee.
*ClassClassIncorrect Control Flow Scoping - (705)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 854 (CERT Java Secure Coding Section 09 - Thread APIs (THI)) > 705 (Incorrect Control Flow Scoping)
The software does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
+CategoryCategoryCERT Java Secure Coding Section 10 - Thread Pools (TPS) - (855)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 855 (CERT Java Secure Coding Section 10 - Thread Pools (TPS))
Weaknesses in this category are related to rules in the Thread Pools (TPS) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseMissing Report of Error Condition - (392)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 855 (CERT Java Secure Coding Section 10 - Thread Pools (TPS)) > 392 (Missing Report of Error Condition)
The software encounters an error but does not provide a status code or return value to indicate that an error has occurred.
*ClassClassAsymmetric Resource Consumption (Amplification) - (405)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 855 (CERT Java Secure Coding Section 10 - Thread Pools (TPS)) > 405 (Asymmetric Resource Consumption (Amplification))
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
*BaseBaseInsufficient Resource Pool - (410)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 855 (CERT Java Secure Coding Section 10 - Thread Pools (TPS)) > 410 (Insufficient Resource Pool)
The software's resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for resources.
*CategoryCategoryCERT Java Secure Coding Section 11 - Thread-Safety Miscellaneous (TSM) - (856)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 856 (CERT Java Secure Coding Section 11 - Thread-Safety Miscellaneous (TSM))
Weaknesses in this category are related to rules in the Thread-Safety Miscellaneous (TSM) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+CategoryCategoryCERT Java Secure Coding Section 12 - Input Output (FIO) - (857)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO))
Weaknesses in this category are related to rules in the Input Output (FIO) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseIncorrect Calculation of Multi-Byte String Length - (135)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 135 (Incorrect Calculation of Multi-Byte String Length)
The software does not correctly calculate the length of strings that can contain wide or multi-byte characters.
*BaseBaseUse of Incorrect Byte Ordering - (198)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 198 (Use of Incorrect Byte Ordering)
The software receives input from an upstream component, but it does not account for byte ordering (e.g. big-endian and little-endian) when processing the input, causing an incorrect number or value to be used.
*VariantVariantIncorrect Default Permissions - (276)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 276 (Incorrect Default Permissions)
The software, upon installation, sets incorrect permissions for an object that exposes it to an unintended actor.
*VariantVariantIncorrect Execution-Assigned Permissions - (279)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 279 (Incorrect Execution-Assigned Permissions)
While it is executing, the software sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
*ClassClassExposure of Private Information ('Privacy Violation') - (359)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 359 (Exposure of Private Information ('Privacy Violation'))
The software does not properly prevent private data (such as credit card numbers) from being accessed by actors who either (1) are not explicitly authorized to access the data or (2) do not have the implicit consent of the people to which the data is related.Privacy leakPrivacy leakage
*BaseBaseInsecure Temporary File - (377)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 377 (Insecure Temporary File)
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
*BaseBaseImproper Resource Shutdown or Release - (404)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 404 (Improper Resource Shutdown or Release)
The program does not release or incorrectly releases a resource before it is made available for re-use.
*ClassClassAsymmetric Resource Consumption (Amplification) - (405)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 405 (Asymmetric Resource Consumption (Amplification))
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
*BaseBaseIncomplete Cleanup - (459)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 459 (Incomplete Cleanup)
The software does not properly "clean up" and remove temporary or supporting resources after they have been used.Insufficient Cleanup
*VariantVariantInformation Exposure Through Log Files - (532)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 532 (Information Exposure Through Log Files)
Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.
*VariantVariantInformation Exposure Through Server Log Files - (533)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 533 (Information Exposure Through Server Log Files)
A server.log file was found. This can give information on whatever application left the file. Usually this can give full path names and system information, and sometimes usernames and passwords.
*VariantVariantInformation Exposure Through Cleanup Log Files - (542)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 542 (Information Exposure Through Cleanup Log Files)
The application does not properly protect or delete a log file related to cleanup.
*VariantVariantImproper Handling of Windows Device Names - (67)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 67 (Improper Handling of Windows Device Names)
The software constructs pathnames from user input, but it does not handle or incorrectly handles a pathname containing a Windows device name such as AUX or CON. This typically leads to denial of service or an information exposure when the application attempts to process the pathname as a regular file.
*ClassClassIncorrect Permission Assignment for Critical Resource - (732)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
*BaseBaseAllocation of Resources Without Limits or Throttling - (770)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 857 (CERT Java Secure Coding Section 12 - Input Output (FIO)) > 770 (Allocation of Resources Without Limits or Throttling)
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on how many resources can be allocated, in violation of the intended security policy for that actor.
+CategoryCategoryCERT Java Secure Coding Section 13 - Serialization (SER) - (858)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER))
Weaknesses in this category are related to rules in the Serialization (SER) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*ClassClassExecution with Unnecessary Privileges - (250)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 250 (Execution with Unnecessary Privileges)
The software 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.
*BaseBaseCleartext Transmission of Sensitive Information - (319)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 319 (Cleartext Transmission of Sensitive Information)
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
*BaseBaseUncontrolled Resource Consumption ('Resource Exhaustion') - (400)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 400 (Uncontrolled Resource Consumption ('Resource Exhaustion'))
The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
*VariantVariantSerializable Class Containing Sensitive Data - (499)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - 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.
*VariantVariantDeserialization of Untrusted Data - (502)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 502 (Deserialization of Untrusted Data)
The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.Marshaling, UnmarshalingPickling, Unpickling
*VariantVariantCall to Non-ubiquitous API - (589)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 589 (Call to Non-ubiquitous API)
The software uses an API function that does not exist on all versions of the target platform. This could cause portability problems or inconsistencies that allow denial of service or other consequences.
*BaseBaseAllocation of Resources Without Limits or Throttling - (770)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 858 (CERT Java Secure Coding Section 13 - Serialization (SER)) > 770 (Allocation of Resources Without Limits or Throttling)
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on how many resources can be allocated, in violation of the intended security policy for that actor.
+CategoryCategoryCERT Java Secure Coding Section 14 - Platform Security (SEC) - (859)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC))
Weaknesses in this category are related to rules in the Platform Security (SEC) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseDirect Use of Unsafe JNI - (111)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - 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.
*BaseBaseIncorrect Privilege Assignment - (266)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - 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.
*BaseBaseLeast Privilege Violation - (272)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - 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.
*ClassClassChannel Accessible by Non-Endpoint ('Man-in-the-Middle') - (300)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 300 (Channel Accessible by Non-Endpoint ('Man-in-the-Middle'))
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.
*VariantVariantAuthentication Bypass by Assumed-Immutable Data - (302)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - 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.
*BaseBaseCleartext Transmission of Sensitive Information - (319)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 319 (Cleartext Transmission of Sensitive Information)
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
*BaseBaseImproper Verification of Cryptographic Signature - (347)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 347 (Improper Verification of Cryptographic Signature)
The software does not verify, or incorrectly verifies, the cryptographic signature for data.
*BaseBaseUse of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') - (470)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'))
The application 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
*BaseBaseDownload of Code Without Integrity Check - (494)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - 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.
*ClassClassIncorrect Permission Assignment for Critical Resource - (732)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
*BaseBaseReliance on Untrusted Inputs in a Security Decision - (807)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 859 (CERT Java Secure Coding Section 14 - Platform Security (SEC)) > 807 (Reliance on Untrusted Inputs in a Security Decision)
The application 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.
+CategoryCategoryCERT Java Secure Coding Section 15 - Runtime Environment (ENV) - (860)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 860 (CERT Java Secure Coding Section 15 - Runtime Environment (ENV))
Weaknesses in this category are related to rules in the Runtime Environment (ENV) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseAcceptance of Extraneous Untrusted Data With Trusted Data - (349)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 860 (CERT Java Secure Coding Section 15 - Runtime Environment (ENV)) > 349 (Acceptance of Extraneous Untrusted Data With Trusted Data)
The software, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
*ClassClassIncorrect Permission Assignment for Critical Resource - (732)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 860 (CERT Java Secure Coding Section 15 - Runtime Environment (ENV)) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+CategoryCategoryCERT Java Secure Coding Section 49 - Miscellaneous (MSC) - (861)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC))
Weaknesses in this category are related to rules in the Miscellaneous (MSC) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
*BaseBaseUse of Hard-coded Password - (259)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 259 (Use of Hard-coded Password)
The software contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
*BaseBaseMissing Encryption of Sensitive Data - (311)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 311 (Missing Encryption of Sensitive Data)
The software does not encrypt sensitive or critical information before storage or transmission.
*ClassClassUse of Insufficiently Random Values - (330)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 330 (Use of Insufficiently Random Values)
The software may use insufficiently random numbers or values in a security context that depends on unpredictable numbers.
*VariantVariantInsufficient Entropy in PRNG - (332)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 332 (Insufficient Entropy in PRNG)
The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.
*VariantVariantImproper Handling of Insufficient Entropy in TRNG - (333)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - 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.
*BaseBaseSame Seed in Pseudo-Random Number Generator (PRNG) - (336)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 336 (Same Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.
*BaseBasePredictable Seed in Pseudo-Random Number Generator (PRNG) - (337)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 337 (Predictable Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
*BaseBaseUncontrolled Resource Consumption ('Resource Exhaustion') - (400)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 400 (Uncontrolled Resource Consumption ('Resource Exhaustion'))
The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
*BaseBaseImproper Release of Memory Before Removing Last Reference ('Memory Leak') - (401)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 401 (Improper Release of Memory Before Removing Last Reference ('Memory Leak'))
The software does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.Memory Leak
*VariantVariantUse of Singleton Pattern Without Synchronization in a Multithreaded Context - (543)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 543 (Use of Singleton Pattern Without Synchronization in a Multithreaded Context)
The software uses the singleton pattern when creating a resource within a multithreaded environment.
*BaseBaseAllocation of Resources Without Limits or Throttling - (770)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 770 (Allocation of Resources Without Limits or Throttling)
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on how many resources can be allocated, in violation of the intended security policy for that actor.
*BaseBaseUse of Hard-coded Credentials - (798)
844 (Weaknesses Addressed by the CERT Java Secure Coding Standard) > 861 (CERT Java Secure Coding Section 49 - Miscellaneous (MSC)) > 798 (Use of Hard-coded Credentials)
The software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.
+ Notes

Relationship

The relationships in this view were determined based on specific statements within the rules from the standard. Not all rules have direct relationships to individual weaknesses, although they likely have chaining relationships in specific circumstances.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE
+ View Metrics
CWEs in this viewTotal CWEs
Total124out of982
Weaknesses106out of 714
Categories18out of 237
Views0out of 31

View Components

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

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

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass345Insufficient Verification of Data Authenticity
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1019Validate Inputs
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass345Insufficient Verification of Data Authenticity
+ Modes Of Introduction

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

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

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control
Integrity

Technical Impact: Bypass Protection Mechanism; Modify Application Data

An attacker could package untrusted data with trusted data to bypass protection mechanisms to gain access to and possibly modify sensitive data.
+ Observed Examples
ReferenceDescription
Does not verify that trusted entity is authoritative for all entities in its response.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUntrusted Data Appended with Trusted Data
CERT Java Secure CodingENV01-JPlace all security-sensitive code in a single JAR and sign and seal it
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Untrusted Data Appended with Trusted Data

CWE-770: Allocation of Resources Without Limits or Throttling

Weakness ID: 770
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on how many resources can be allocated, in violation of the intended security policy for that actor.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
System Configuration
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Availability

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

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

Example 1

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

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

}

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

Example 2

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

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

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

if (socket < 0) {
printf("Unable to open socket connection");
return(FAIL);

}
if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) {
if (openFileToWrite(filename) > 0) {
while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){
if (!(writeToFile(buffer) > 0))
break;

}

}
closeFile();

}
closeSocket(socket);

}

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

Example 3

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

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

int length = getMessageLength(message[0]);

if (length > 0) {
body = &message[1][0];
processMessageBody(body);
return(SUCCESS);

}
else {
printf("Unable to process message; invalid message length");
return(FAIL);

}

}

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

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

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

Example 4

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

(bad)
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)
Example Language: Java 
public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10;
...

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

}
serverSocket.close();


} catch (IOException ex) {...}

}

Example 5

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

Example 5 References:

[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011. <http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.
+ Observed Examples
ReferenceDescription
Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
Large integer value for a length property in an object causes a large amount of memory allocation.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
+ Potential Mitigations

Phase: Requirements

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). A blacklist is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
This will only be applicable to cases where user input can influence the size or frequency of resource allocations.

Phase: Architecture and Design

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

Phase: Architecture and Design

Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.

Phase: Architecture and Design

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

Phases: Architecture and Design; Implementation

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

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
+ Detection Methods

Manual Static Analysis

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

Fuzzing

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

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

Effectiveness: Opportunistic

Automated Dynamic Analysis

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

Automated Static Analysis

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

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

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

+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Maintenance

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

Theoretical

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

CWE-582: Array Declared Public, Final, and Static

Weakness ID: 582
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The program declares an array public, final, and static, which is not sufficient to prevent the array's contents from being modified.
+ Extended Description
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.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass668Exposure of Resource to Wrong Sphere
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory490Mobile Code Issues
+ Modes Of Introduction

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

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

Languages

Java: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

+ Demonstrative Examples

Example 1

The following Java Applet code mistakenly declares an array public, final and static.

(bad)
Example Language: Java 
public final class urlTool extends Applet {
public final static URL[] urls;
...

}
+ Potential Mitigations

Phase: Implementation

In most situations the array should be made private.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingOBJ10-JDo not use public static nonfinal variables
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Unsafe Array Declaration

CWE-405: Asymmetric Resource Consumption (Amplification)

Weakness ID: 405
Abstraction: Class
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
+ Extended Description
This situation is amplified if the software allows malicious users or attackers to consume more resources than their access level permits. Exploiting such a weakness can lead to asymmetric resource consumption, aiding in amplification attacks against the system or the network.
+ Relationships

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

+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ParentOfBaseBase407Algorithmic Complexity
+ Modes Of Introduction

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

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

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Availability

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

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

Phase: Architecture and Design

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

Phase: Architecture and Design

An application must, at all times, keep track of allocated resources and meter their usage appropriately.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAsymmetric resource consumption (amplification)
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
WASC41XML Attribute Blowup
CERT Java Secure CodingTPS00-JUse thread pools to enable graceful degradation of service during traffic bursts
CERT Java Secure CodingFIO04-JRelease resources when they are no longer needed
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Common_Consequences, Other_Notes
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Functional_Areas

CWE-289: Authentication Bypass by Alternate Name

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1010Authenticate Actors
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass287Improper Authentication
+ Modes Of Introduction

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

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

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

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

Phase: Architecture and Design

Strategy: Input Validation

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

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). A blacklist is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Relationship

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

Theoretical

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

CWE-302: Authentication Bypass by Assumed-Immutable Data

Weakness ID: 302
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1010Authenticate Actors
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass287Improper Authentication
+ Modes Of Introduction

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

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

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

In the following example, an "authenticated" cookie is used to determine whether or not a user should be granted access to a system.

(bad)
Example Language: Java 
boolean authenticated = new Boolean(getCookieValue("authenticated")).booleanValue();
if (authenticated) {
...

}

Of course, modifying the value of a cookie on the client-side is trivial, but many developers assume that cookies are essentially immutable.

+ Observed Examples
ReferenceDescription
DebPloit
Web auth
Authentication bypass by setting certain cookies to "true".
Authentication bypass by setting certain cookies to "true".
Admin access by setting a cookie.
Gain privileges by setting cookie.
Product trusts authentication information in cookie.
Authentication bypass by setting admin-testing variable to true.
Bypass auth and gain privileges by setting a variable.
+ Potential Mitigations

Phases: Architecture and Design; Operation; Implementation

Implement proper protection for immutable data (e.g. environment variable, hidden form fields, etc.)
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication Bypass via Assumed-Immutable Data
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
CERT Java Secure CodingSEC02-JDo not base security checks on untrusted sources
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships

CWE-589: Call to Non-ubiquitous API

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory1006Bad Coding Practices
+ Modes Of Introduction

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

PhaseNote
Architecture and Design
Implementation
+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation

+ Potential Mitigations

Phase: Implementation

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

Phase: Testing

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

Phase: Testing

Develop a system to test for API functions that are not portable.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingMET02-JDo not use deprecated or obsolete classes or methods
CERT Java Secure CodingSER00-JMaintain serialization compatibility during class evolution
Software Fault PatternsSFP3Use of an improper API
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2008-10-14CWE Content TeamMITRE
updated Description
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Call to Limited API

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

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase821Incorrect Synchronization
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory557Concurrency Issues
ChildOfBaseBase821Incorrect Synchronization
+ Modes Of Introduction

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

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

Languages

Java: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Quality Degradation; Varies by Context

+ Demonstrative Examples

Example 1

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

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

}

};

thr.run();
+ Potential Mitigations

Phase: Implementation

Use the start() method instead of the run() method.
+ Affected Resources
  • System Process
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingTHI00-JDo not invoke Thread.run()
Software Fault PatternsSFP3Use of an improper API
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Call to Thread.run()

CWE CATEGORY: CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)

Category ID: 845
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Input Validation and Data Sanitization section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE

CWE CATEGORY: CERT Java Secure Coding Section 01 - Declarations and Initialization (DCL)

Category ID: 846
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Declarations and Initialization (DCL) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Membership
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE

CWE CATEGORY: CERT Java Secure Coding Section 02 - Expressions (EXP)

Category ID: 847
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Expressions (EXP) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITRE
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM)

Category ID: 848
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Numeric Types and Operations (NUM) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE

CWE CATEGORY: CERT Java Secure Coding Section 04 - Object Orientation (OBJ)

Category ID: 849
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Object Orientation (OBJ) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITRE
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 05 - Methods (MET)

Category ID: 850
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Methods (MET) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITRE
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)

Category ID: 851
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Exceptional Behavior (ERR) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE

CWE CATEGORY: CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)

Category ID: 852
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Visibility and Atomicity (VNA) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE

CWE CATEGORY: CERT Java Secure Coding Section 08 - Locking (LCK)

Category ID: 853
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Locking (LCK) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Membership
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE

CWE CATEGORY: CERT Java Secure Coding Section 09 - Thread APIs (THI)

Category ID: 854
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Thread APIs (THI) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITRE
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 10 - Thread Pools (TPS)

Category ID: 855
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Thread Pools (TPS) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE

CWE CATEGORY: CERT Java Secure Coding Section 11 - Thread-Safety Miscellaneous (TSM)

Category ID: 856
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Thread-Safety Miscellaneous (TSM) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ Membership
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE

CWE CATEGORY: CERT Java Secure Coding Section 12 - Input Output (FIO)

Category ID: 857
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Input Output (FIO) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITRE
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 13 - Serialization (SER)

Category ID: 858
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Serialization (SER) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE

CWE CATEGORY: CERT Java Secure Coding Section 14 - Platform Security (SEC)

Category ID: 859
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Platform Security (SEC) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2011-09-13CWE Content TeamMITRE
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 15 - Runtime Environment (ENV)

Category ID: 860
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Runtime Environment (ENV) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2011-09-13CWE Content TeamMITRE
updated Relationships
2012-05-11CWE Content TeamMITRE
updated Relationships

CWE CATEGORY: CERT Java Secure Coding Section 49 - Miscellaneous (MSC)

Category ID: 861
Status: Incomplete
+ Summary
Weaknesses in this category are related to rules in the Miscellaneous (MSC) section of the CERT Java Secure Coding Standard. Since not all rules map to specific weaknesses, this category may be incomplete.
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2011-05-24CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITRE
updated Relationships

CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle')

Weakness ID: 300
Abstraction: Class
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
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.
+ Extended Description
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.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

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

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

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Confidentiality
Integrity
Access Control

Technical Impact: Read Application Data; Modify Application Data; Gain Privileges or Assume Identity

An attacker could pose as one of the entities and read or possibly modify the communication.
+ Demonstrative Examples

Example 1

In the Java snippet below, data is sent over an unencrypted channel to a remote server.

(bad)
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.

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

Phase: Implementation

Always fully authenticate both ends of any communications channel.

Phase: Architecture and Design

Adhere to the principle of complete mediation.

Phase: Implementation

A certificate binds an identity to a cryptographic key to authenticate a communicating party. Often, the certificate takes the encrypted form of the hash of the identity of the subject, the public key, and information such as time of issue or expiration using the issuer's private key. The certificate can be validated by deciphering the certificate with the issuer's public key. See also X.509 certificate signature chains and the PGP certification structure.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Maintenance

The summary identifies multiple distinct possibilities, suggesting that this is a category that must be broken into more specific weaknesses.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMan-in-the-middle (MITM)
WASC32Routing Detour
CERT Java Secure CodingSEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
+ References
[REF-244] M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Name
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Man-in-the-middle (MITM)
2009-05-27Channel Accessible by Non-Endpoint (aka 'Man-in-the-Middle')

CWE CATEGORY: Cleansing, Canonicalization, and Comparison Errors

Category ID: 171
Status: Draft
+ Summary
Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform neutralization for untrusted data.
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoft.com/mspress/books/toc/5957.aspx>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms
2011-06-01CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References, Related_Attack_Patterns, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, References, Related_Attack_Patterns, Relationships

CWE-319: Cleartext Transmission of Sensitive Information

Weakness ID: 319
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
+ Extended Description
Many communication channels can be "sniffed" by attackers during data transmission. For example, network traffic can often be sniffed by any attacker who has access to a network interface. This significantly lowers the difficulty of exploitation by attackers.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1013Encrypt Data
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfBaseBase311Missing Encryption of Sensitive Data
+ Modes Of Introduction

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

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Operation
System Configuration
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

Paradigms

Mobile: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Read Application Data; Modify Files or Directories

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

Example 1

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

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

}
catch (IOException e) {
//...

}

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

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

Phase: Architecture and Design

Encrypt the data with a reliable encryption scheme before transmitting.

Phase: Implementation

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

Phase: Testing

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

Phase: Operation

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

Black Box

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

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

+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Transmission of Sensitive Information
CERT Java Secure CodingSEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
CERT Java Secure CodingSER02-JSign then seal sensitive objects before sending them outside a trust boundary
Software Fault PatternsSFP23Exposed Data
+ References
[REF-271] OWASP. "Top 10 2007-Insecure Communications". 2007. <http://www.owasp.org/index.php/Top_10_2007-A9>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoft.com/mspress/books/toc/5957.aspx>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated References
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Relationships
2010-12-13CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, References
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Plaintext Transmission of Sensitive Information

CWE-498: Cloneable Class Containing Sensitive Information

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass664Improper Control of a Resource Through its Lifetime
CanPrecedeClassClass200Information Exposure
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory490Mobile Code Issues
CanPrecedeClassClass200Information Exposure
+ Modes Of Introduction

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

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

Languages

C++: (Undetermined Prevalence)

Java: (Undetermined Prevalence)

C#: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

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

Example 1

The following example demonstrates the weakness.

(bad)
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)
Example Language: Java 
public final void clone() throws java.lang.CloneNotSupportedException {
throw new java.lang.CloneNotSupportedException();

}
+ Potential Mitigations

Phase: Implementation

If you do make your classes clonable, ensure that your clone method is final and throw super.clone().
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPInformation leak through class cloning
CERT Java Secure CodingOBJ07-JSensitive classes must not let themselves be copied
Software Fault PatternsSFP23Exposed Data
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASP
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Other_Notes
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Information Leak through Class Cloning

CWE-182: Collapse of Data into Unsafe Value

Weakness ID: 182
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass693Protection Mechanism Failure
CanFollowClassClass185Incorrect Regular Expression
CanPrecedeVariantVariant33Path Traversal: '....' (Multiple Dot)
CanPrecedeVariantVariant34Path Traversal: '....//'
CanPrecedeVariantVariant35Path Traversal: '.../...//'
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
+ Modes Of Introduction

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

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

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

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

Phase: Architecture and Design

Strategy: Input Validation

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

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). A blacklist is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.
Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function).
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Relationship

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

CWE-486: Comparison of Classes by Name

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass697Insufficient Comparison
PeerOfBaseBase386Symbolic Name not Mapping to Correct Object
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
+ Modes Of Introduction

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

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

Languages

Java: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality
Availability

Technical Impact: Execute Unauthorized Code or Commands

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

Example 1

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

(bad)
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)
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)
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)
Example Language: Java 
public boolean equals(Object obj) {
...
// first check to see if the object is of the same class

if (obj.getClass() == this.getClass()) {
...

}

...

}
+ Potential Mitigations

Phase: Implementation

Use class equivalency to determine type. Rather than use the class name to determine if an object is of a given type, use the getClass() method, and == operator.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsComparing Classes by Name
CLASPComparing classes by name
CERT Java Secure CodingOBJ09-JCompare classes and not class names
Software Fault PatternsSFP1Glitch in computation
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious Kingdoms
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Relevant_Properties, Taxonomy_Mappings
2009-03-10CWE Content TeamMITRE
updated Other_Notes
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Relevant_Properties
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Comparing Classes by Name

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

Weakness ID: 595
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The program compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass697Insufficient Comparison
ParentOfVariantVariant597Use of Wrong Operator in String Comparison
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

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

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

Languages

Java: (Undetermined Prevalence)

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Other

Technical Impact: Other; Varies by Context

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

Example 1

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

(bad)
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)
 
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)
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)
Example Language: Java 
public boolean isSameAccount(BankAccount accountA, BankAccount accountB) {
return accountA.equals(accountB);

}
+ Potential Mitigations

Phase: Implementation

Use the equals() method to compare objects instead of the == operator. If using ==, it is important for performance reasons that your objects are created by a static factory, not by a constructor.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory847CERT Java Secure Coding Section 02 - Expressions (EXP)
MemberOfViewView884CWE Cross-section
MemberOfCategoryCategory977SFP Secondary Cluster: Design
+ Notes

Other

This problem can cause unexpected application behavior. Comparing objects using == usually produces deceptive results, since the == operator compares object references rather than values. To use == on a string, the programmer has to make sure that these objects are unique in the program, that is, that they don't have the equals method defined or have a static factory that produces unique objects.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingEXP02-JUse the two-argument Arrays.equals() method to compare the contents of arrays
CERT Java Secure CodingEXP02-JUse the two-argument Arrays.equals() method to compare the contents of arrays
CERT Java Secure CodingEXP03-JDo not use the equality operators when comparing values of boxed primitives
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes
2009-05-27CWE Content TeamMITRE
updated Name
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences
2014-07-30CWE Content TeamMITRE
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Incorrect Object Comparison: Syntactic
2009-05-27Incorrect Syntactic Object Comparison

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

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

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

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

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

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

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

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

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

Languages

C: (Sometimes Prevalent)

C++: (Sometimes Prevalent)

Java: (Sometimes Prevalent)

(Language-Independent classes): (Undetermined Prevalence)

Paradigms

Concurrent Systems Operating on Shared Resources: (Often Prevalent)

+ Common Consequences

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

ScopeImpactLikelihood
Availability

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

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

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

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

Technical Impact: Read Files or Directories; Read Application Data

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

Example 1

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

(bad)
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)
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)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);
/* access shared resource */


pthread_mutex_unlock(mutex);

}

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

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

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

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

/* access shared resource */


return pthread_mutex_unlock(mutex);

}
+ Observed Examples
ReferenceDescription
Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
Race condition during initialization triggers a buffer overflow.
Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
chain: race condition triggers NULL pointer dereference
Race condition in library function could cause data to be sent to the wrong process.
Race condition in file parser leads to heap corruption.
chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
chain: race condition for an argument value, possibly resulting in NULL dereference
chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Architecture and Design

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

Phase: Architecture and Design

Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

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

Black Box

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

White Box

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

Automated Dynamic Analysis

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

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

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

Effectiveness: Moderate

Automated Static Analysis - Binary or Bytecode

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

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

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

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

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

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

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

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

Effectiveness: High

Manual Static Analysis - Source Code

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

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

Effectiveness: High

Automated Static Analysis - Source Code

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

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

Effectiveness: High

Architecture or Design Review

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

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

Effectiveness: High

+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Maintenance

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

Research Gap

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

Research Gap

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

Research Gap

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

CWE-493: Critical Public Variable Without Final Modifier

Weakness ID: 493
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values.
+ Extended Description
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.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory490Mobile Code Issues
ParentOfVariantVariant500Public Static Field Not Marked Final
+ Modes Of Introduction

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

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

Languages

Java: (Undetermined Prevalence)

C++: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data

The object could potentially be tampered with.
Confidentiality

Technical Impact: Read Application Data

The object could potentially allow the object to be read.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

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)
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)
Example Language: C++ 
public string configPath = "/etc/application/config.dat";
(bad)
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.

+ Potential Mitigations

Phase: Implementation

Declare all public fields as final when possible, especially if it is used to maintain internal state of an Applet or of classes used by an Applet. If a field must be public, then perform all appropriate sanity checks before accessing the field from your code.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsMobile Code: Non-Final Public Field
CLASPFailure to provide confidentiality for stored data
CERT Java Secure CodingOBJ10-JDo not use public static nonfinal variables
Software Fault PatternsSFP28Unexpected access points
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious Kingdoms
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description, Likelihood_of_Exploit, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Background_Details, Demonstrative_Examples, Description, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Mobile Code: Non-final Public Field

CWE-766: Critical Variable Declared Public

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass668Exposure of Resource to Wrong Sphere
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory265Privilege / Sandbox Issues
+ Modes Of Introduction

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

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

Languages

C++: (Undetermined Prevalence)

C#: (Undetermined Prevalence)

Java: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Read Application Data; Modify Application Data

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

Example 1

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

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

Instead, the critical data should be declared private.

(good)
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)
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)
Example Language: C++ 
class UserAccount
{
public:
...


private:
char username[MAX_USERNAME_LENGTH+1];
char password[MAX_PASSWORD_LENGTH+1];

};
+ Observed Examples
ReferenceDescription
variables declared public allows remote read of system properties such as user name and home directory.
+ Potential Mitigations

Phase: Implementation

Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure to protect stored data from modification
CERT Java Secure CodingOBJ01-JDeclare data members as private and provide accessible wrapper methods
Software Fault PatternsSFP28Unexpected access points
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-03-03CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2009-12-28CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Relationships

CWE-833: Deadlock

Weakness ID: 833
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase667Improper Locking
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfBaseBase667Improper Locking
+ Common Consequences

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

ScopeImpactLikelihood
Availability

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

Each thread of execution will "hang" and prevent tasks from completing. In some cases, CPU consumption may occur if a lock check occurs in a tight loop.
+ Observed Examples
ReferenceDescription
OS deadlock
OS deadlock involving 3 separate functions
deadlock in library
deadlock triggered by packets that force collisions in a routing table
read/write deadlock between web server and script
web server deadlock involving multiple listening connections
multiple simultaneous calls to the same function trigger deadlock.
chain: other weakness leads to NULL pointer dereference (CWE-476) or deadlock (CWE-833).
deadlock when an operation is performed on a resource while it is being removed.
Deadlock in device driver triggered by using file handle of a related device.
Deadlock when large number of small messages cannot be processed quickly enough.
OS kernel has deadlock triggered by a signal during a core dump.
Race condition leads to deadlock.
Chain: array index error (CWE-129) leads to deadlock (CWE-833)
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory853CERT Java Secure Coding Section 08 - Locking (LCK)
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingLCK08-JEnsure actively held locks are released on exceptional conditions
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Synchronization Problems" / "Starvation and Deadlocks", Page 760. 1st Edition. Addison Wesley. 2006.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Starvation and Deadlocks", Page 760.. 1st Edition. Addison Wesley. 2006.
[REF-783] Robert C. Seacord. "Secure Coding in C and C++". Chapter 7, "Concurrency", section "Mutual Exclusion and Deadlock", Page 248.. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2010-12-12CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated References
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns

CWE-397: Declaration of Throws for Generic Exception

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory389Error Conditions, Return Values, Status Codes
+ Modes Of Introduction

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

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

Languages

C++: (Undetermined Prevalence)

Java: (Undetermined Prevalence)

C#: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Non-Repudiation
Other

Technical Impact: Hide Activities; Alter Execution Logic

+ Demonstrative Examples

Example 1

The following method throws three types of exceptions.

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

}

While it might seem tidier to write

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

}

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

+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsOverly-Broad Throws Declaration
CERT Java Secure CodingERR07-JDo not throw RuntimeException, Exception, or Throwable
Software Fault PatternsSFP5Ambiguous Exception Type
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious Kingdoms
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-09-24CWE Content TeamMITRE
Removed C from Applicable_Platforms
2008-10-14CWE Content TeamMITRE
updated Applicable_Platforms
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Overly-Broad Throws Declaration

CWE-502: Deserialization of Untrusted Data

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

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

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

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

+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1019Validate Inputs
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

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

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

Languages

Java: (Undetermined Prevalence)

Ruby: (Undetermined Prevalence)

PHP: (Undetermined Prevalence)

Python: (Undetermined Prevalence)

JavaScript: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity

Technical Impact: Modify Application Data; Unexpected State

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

Technical Impact: DoS: Resource Consumption (CPU)

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

Technical Impact: Varies by Context

The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation.
+ Alternate Terms
Marshaling, Unmarshaling:Marshaling and unmarshaling are effectively synonyms for serialization and deserialization, respectively.
Pickling, Unpickling:In Python, the "pickle" functionality is used to perform serialization and deserialization.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

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

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

}

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

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

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

Example 2

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

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

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

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

}

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

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

Phases: Architecture and Design; Implementation

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

Phase: Implementation

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

Phase: Implementation

Explicitly define a final object() to prevent deserialization.

Phases: Architecture and Design; Implementation

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

Phase: Implementation

Avoid having unnecessary types or gadgets available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Whitelist acceptable classes. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Maintenance

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

CWE-390: Detection of Error Condition Without Action

Weakness ID: 390
Abstraction: Class
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software detects a specific error, but takes no actions to handle the error.
+ Relationships

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

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1020Verify Message Integrity
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory389Error Conditions, Return Values, Status Codes
+ Modes Of Introduction

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

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

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Other

Technical Impact: Varies by Context; Unexpected State; Alter Execution Logic

An attacker could utilize an ignored error condition to place the system in an unexpected state that could lead to the execution of unintended logic and could cause other unintended behavior.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

The following example attempts to allocate memory for a character. After the call to malloc, an if statement is used to check whether the malloc function failed.

(bad)
Example Language:
foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {
//We do nothing so we just ignore the error.

}

The conditional successfully detects a NULL return value from malloc indicating a failure, however it does not do anything to handle the problem. Unhandled errors may have unexpected results and may cause the program to crash or terminate.

Instead, the if block should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following example notifies the user that the malloc function did not allocate the required memory resources and returns an error code.

(good)
Example Language:
foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) {
printf("Malloc failed to allocate memory resources");
return -1;

}

Example 2

In the following C++ example the method readFile() will read the file whose name is provided in the input parameter and will return the contents of the file in char string. The method calls open() and read() may result in errors if the file does not exist or does not contain any data to read. These errors will be thrown when the is_open() method and good() method indicate errors opening or reading the file. However, these errors are not handled within the catch statement. Catch statements that do not perform any processing will have unexpected results. In this case an empty char string will be returned, and the file will not be properly closed.

(bad)
Example Language: C++ 
char* readfile (char *filename) {
try {
// open input file
ifstream infile;
infile.open(filename);

if (!infile.is_open()) {
throw "Unable to open file " + filename;

}

// get length of file
infile.seekg (0, ios::end);
int length = infile.tellg();
infile.seekg (0, ios::beg);

// allocate memory
char *buffer = new char [length];

// read data from file
infile.read (buffer,length);

if (!infile.good()) {
throw "Unable to read from file " + filename;

}

infile.close();

return buffer;

}
catch (...) {
/* bug: insert code to handle this later */

}

}

The catch statement should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following C++ example contains two catch statements. The first of these will catch a specific error thrown within the try block, and the second catch statement will catch all other errors from within the catch block. Both catch statements will notify the user that an error has occurred, close the file, and rethrow to the block that called the readFile() method for further handling or possible termination of the program.

(good)
Example Language: C++ 
char* readFile (char *filename) {
try {
// open input file
ifstream infile;
infile.open(filename);

if (!infile.is_open()) {
throw "Unable to open file " + filename;

}

// get length of file
infile.seekg (0, ios::end);
int length = infile.tellg();
infile.seekg (0, ios::beg);

// allocate memory
char *buffer = new char [length];

// read data from file
infile.read (buffer,length);

if (!infile.good()) {
throw "Unable to read from file " + filename;

}
infile.close();

return buffer;

}
catch (char *str) {
printf("Error: %s \n", str);
infile.close();
throw str;

}
catch (...) {
printf("Error occurred trying to read from file \n");
infile.close();
throw;

}

}

Example 3

In the following Java example the method readFile will read the file whose name is provided in the input parameter and will return the contents of the file in a String object. The constructor of the FileReader object and the read method call may throw exceptions and therefore must be within a try/catch block. While the catch statement in this example will catch thrown exceptions in order for the method to compile, no processing is performed to handle the thrown exceptions. Catch statements that do not perform any processing will have unexpected results. In this case, this will result in the return of a null String.

(bad)
Example Language: Java 
public String readFile(String filename) {
String retString = null;
try {
// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);

// initialize character buffer
long fLen = file.length();
char[] cBuf = new char[(int) fLen];

// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);

// close file
fr.close();

retString = new String(cBuf);

} catch (Exception ex) {
/* do nothing, but catch so it'll compile... */

}
return retString;

}

The catch statement should contain statements that either attempt to fix the problem, notify the user that an exception has been raised and continue processing, or perform some cleanup and gracefully terminate the program. The following Java example contains three catch statements. The first of these will catch the FileNotFoundException that may be thrown by the FileReader constructor called within the try/catch block. The second catch statement will catch the IOException that may be thrown by the read method called within the try/catch block. The third catch statement will catch all other exceptions thrown within the try block. For all catch statements the user is notified that the exception has been thrown and the exception is rethrown to the block that called the readFile() method for further processing or possible termination of the program. Note that with Java it is usually good practice to use the getMessage() method of the exception class to provide more information to the user about the exception raised.

(good)
Example Language: Java 
public String readFile(String filename) throws FileNotFoundException, IOException, Exception {
String retString = null;
try {
// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);

// initialize character buffer
long fLen = file.length();
char [] cBuf = new char[(int) fLen];

// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);

// close file
fr.close();

retString = new String(cBuf);

} catch (FileNotFoundException ex) {
System.err.println ("Error: FileNotFoundException opening the input file: " + filename );
System.err.println ("" + ex.getMessage() );
throw new FileNotFoundException(ex.getMessage());

} catch (IOException ex) {
System.err.println("Error: IOException reading the input file.\n" + ex.getMessage() );
throw new IOException(ex);

} catch (Exception ex) {
System.err.println("Error: Exception reading the input file.\n" + ex.getMessage() );
throw new Exception(ex);

}
return retString;

}
+ Potential Mitigations

Phase: Implementation

Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.

Phase: Implementation

If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program.

Phase: Testing

Subject the software to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPImproper error handling
CERT Java Secure CodingERR00-JDo not suppress or ignore checked exceptions
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASP
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, References, Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Improper Error Handling

CWE-111: Direct Use of Unsafe JNI

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase695Use of Low-Level Functionality
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass20Improper Input Validation
+ Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)
NatureTypeIDName
ChildOfClassClass20Improper Input Validation
+ Modes Of Introduction

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

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

Languages

Java: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

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

(bad)
Example Language: Java 
class Echo {

public native void runEcho();
static {

System.loadLibrary("echo");

}
public static void main(String[] args) {

new Echo().runEcho();

}

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

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

}

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

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

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

+ Potential Mitigations

Phase: Implementation

Implement error handling around the JNI call.

Phase: Implementation

Strategy: Refactoring

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

Phase: Implementation

Strategy: Refactoring

Be reluctant to use JNI calls. A Java API equivalent may exist.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsUnsafe JNI
CERT Java Secure CodingSEC08-JDefine wrappers around native methods
Software Fault PatternsSFP3Use of an improper API
+ References
[REF-41] Fortify Software. "Fortify Descriptions". <http://vulncat.fortifysoftware.com>.
[REF-42] Beth Stearns. "The Java(TM) Tutorial: The Java Native Interface". Sun Microsystems. 2005. <http://www.eg.bucknell.edu/~mead/Java-tutorial/native1.1/index.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious Kingdoms
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Demonstrative_Example, Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, References, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Description, Other_Notes
2009-10-29CWE Content TeamMITRE
updated Description, Other_Notes
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Causal_Nature, Potential_Mitigations, References
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unsafe JNI

CWE-369: Divide By Zero

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass682Incorrect Calculation
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass682Incorrect Calculation
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass682Incorrect Calculation
+ Modes Of Introduction

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

PhaseNote
Implementation
+ Common Consequences

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

ScopeImpactLikelihood
Availability

Technical Impact: DoS: Crash, Exit, or Restart

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

Example 1

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

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

}

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

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

}
return totalTime / numRequests;

}

Example 2

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

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

}

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

(good)
 
const int DivideByZero = 10;
double divide(double x, double y){
if ( 0 == y ){
throw DivideByZero;

}
return x/y;

}
...
try{
divide(10, 0);

}
catch( int i ){
if(i==DivideByZero) {
cerr<<"Divide by zero error";

}

}

Example 2 References:

[REF-371] Alex Allain. "Handling Errors Exceptionally Well in C++". <http://www.cprogramming.com/tutorial/exceptions.html>.

Example 3

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

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

}

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

(good)
 
int SafeDivision(int x, int y){
try{
return (x / y);

}
catch (System.DivideByZeroException dbz){
System.Console.WriteLine("Division by zero attempted!");
return 0;

}

}

Example 3 References:

[REF-372] Microsoft. "Exceptions and Exception Handling (C# Programming Guide)". <https://msdn.microsoft.com/pl-pl/library/ms173160(v=vs.100).aspx>.
+ Observed Examples
ReferenceDescription
Invalid size value leads to divide by zero.
"Empty" content triggers divide by zero.
Height value of 0 triggers divide by zero.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingFLP03-CDetect and handle floating point errors
CERT C Secure CodingINT33-CExactEnsure that division and remainder operations do not result in divide-by-zero errors
CERT Java Secure CodingNUM02-JEnsure that division and modulo operations do not result in divide-by-zero errors
Software Fault PatternsSFP1Glitch in computation
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITRE
updated Other_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings

CWE-609: Double-Checked Locking

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

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

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase667Improper Locking
CanPrecedeBaseBase367Time-of-check Time-of-use (TOCTOU) Race Condition
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory3617PK - Time and State
+ Modes Of Introduction

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

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

Languages

Java: (Undetermined Prevalence)

+ Common Consequences

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

ScopeImpactLikelihood
Integrity
Other

Technical Impact: Modify Application Data; Alter Execution Logic

+ Demonstrative Examples

Example 1

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

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

}

}

}
return helper;

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

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

(bad)
 
helper = new Helper();

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

+ Potential Mitigations

Phase: Implementation

While double-checked locking can be achieved in some languages, it is inherently flawed in Java before 1.5, and cannot be achieved without compromising platform independence. Before Java 1.5, only use of the synchronized keyword is known to work. Beginning in Java 1.5, use of the "volatile" keyword allows double-checked locking to work successfully, although there is some debate as to whether it achieves sufficient performance gains. See references.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingLCK10-JDo not use incorrect forms of the double-checked locking idiom
Software Fault PatternsSFP19Missing Lock
+ References
[REF-490] David Bacon et al. "The "Double-Checked Locking is Broken" Declaration". <http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html>.
[REF-491] Jeremy Manson and Brian Goetz. "JSR 133 (Java Memory Model) FAQ". <http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#dcl>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Threading Vulnerabilities", Page 815.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Context_Notes
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Demonstrative_Examples
2009-01-12CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITRE