View: Weaknesses in Software Written in Java
Draft
Type: Implicit
Objective
This view (slice) covers issues that are found in Java programs that are not common to all languages.
Membership
| ID | Name | Description |
|---|---|---|
| CWE-102 | Struts: Duplicate Validation Forms | This vulnerability occurs when an application defines multiple Struts validation forms with identical names. The framework then unpredictably selects only one form for validation, potentially bypassing intended security checks. |
| CWE-103 | Struts: Incomplete validate() Method Definition | This vulnerability occurs in a Struts application when a validator form either completely omits a validate() method or includes one but fails to call super.validate() within it. |
| CWE-104 | Struts: Form Bean Does Not Extend Validation Class | This vulnerability occurs in Apache Struts applications when a form bean class does not properly extend the framework's validation class. This bypasses the built-in Validator framework, leaving the application without structured input validation and open to various injection and data manipulation attacks. |
| CWE-105 | Struts: Form Field Without Validator | This vulnerability occurs when a Struts application form contains an input field that lacks a corresponding validator, leaving it open to unverified user input. |
| CWE-106 | Struts: Plug-in Framework not in Use | This weakness occurs when a Java application, particularly one using the Struts framework, does not implement a structured input validation plugin like the Struts Validator. Skipping this framework forces developers to write custom validation logic, which is often error-prone and increases the risk of security flaws from improperly handled user input. |
| CWE-107 | Struts: Unused Validation Form | This vulnerability occurs when a Struts application contains validation form definitions that are no longer linked to any active form or action, leaving outdated security rules in the codebase. |
| CWE-108 | Struts: Unvalidated Action Form | In Apache Struts, every Action Form that processes user input must have a corresponding validation form configured. Missing this validation exposes the application to unvalidated data. |
| CWE-109 | Struts: Validator Turned Off | This vulnerability occurs when an application built with Apache Struts intentionally disables its built-in validation framework. By turning off the Struts Validator bean, developers remove critical automatic input filtering and custom validation rules, leaving the application unprotected against malicious or malformed data. |
| CWE-110 | Struts: Validator Without Form Field | This vulnerability occurs when a Struts application's validation configuration file references form fields that no longer exist in the corresponding ActionForm class. This mismatch indicates outdated validation logic that can fail to properly check user input. |
| CWE-111 | Direct Use of Unsafe JNI | This weakness occurs when a Java application directly calls native code through the Java Native Interface (JNI), exposing the entire application to security risks present in that external code, even if Java itself is safe from those specific flaws. |
| CWE-1235 | Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations | This weakness occurs when a program relies on automatic boxing and unboxing of primitive types within performance-sensitive code sections, causing unnecessary computational overhead and potential resource strain. |
| CWE-1335 | Incorrect Bitwise Shift of Integer | This vulnerability occurs when a program attempts to shift an integer's bits by an invalid amount—either a negative number or a value equal to or greater than the integer's bit width (e.g., shifting a 32-bit integer by 32 or more places). This leads to unpredictable and platform-dependent results. |
| CWE-1336 | Improper Neutralization of Special Elements Used in a Template Engine | This vulnerability occurs when an application uses a template engine to process user-controlled input but fails to properly sanitize special syntax characters. Attackers can inject template expressions or directives that the engine executes, leading to unintended code execution. |
| CWE-1341 | Multiple Releases of Same Resource or Handle | This vulnerability occurs when a program incorrectly tries to close or release the same system resource—like memory, a file, or a network connection—more than once. This double-free or double-close violates the API's contract and leads to unpredictable and often dangerous behavior. |
| CWE-191 | Integer Underflow (Wrap or Wraparound) | Integer underflow occurs when a subtraction operation results in a value smaller than the data type's minimum limit, causing the value to wrap around to a large, incorrect number. |
| CWE-192 | Integer Coercion Error | An integer coercion error occurs when a program incorrectly converts, extends, or truncates a number between different data types, leading to unexpected values. |
| CWE-197 | Numeric Truncation Error | A numeric truncation error happens when a program converts a number to a smaller data type, cutting off its higher-order bits and corrupting the original value. |
| CWE-209 | Generation of Error Message Containing Sensitive Information | This vulnerability occurs when an application reveals sensitive details about its internal systems, user data, or environment within error messages shown to users. |
| CWE-245 | J2EE Bad Practices: Direct Management of Connections | This vulnerability occurs when a J2EE application handles database connections directly instead of using the container's built-in connection management system. |
| CWE-246 | J2EE Bad Practices: Direct Use of Sockets | This vulnerability occurs when a J2EE application creates network sockets directly, bypassing the container-managed communication framework provided by the platform. |
| CWE-248 | Uncaught Exception | This vulnerability occurs when a function throws an error or exception, but the calling code does not have a proper handler to catch and manage it. |
| CWE-362 | Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') | A race condition occurs when multiple processes or threads access a shared resource simultaneously without proper coordination, creating a timing window where the resource's state can be unexpectedly altered, leading to unpredictable behavior or security vulnerabilities. |
| CWE-366 | Race Condition within a Thread | This vulnerability occurs when two or more threads within the same application access and manipulate a shared resource (like a variable, data structure, or file) without proper synchronization. Because the threads can execute in an unpredictable order, they can corrupt the resource's state, leading to crashes, incorrect calculations, or data loss. |
| CWE-374 | Passing Mutable Objects to an Untrusted Method | This vulnerability occurs when a function receives a direct reference to mutable data, such as an object or array, instead of a safe copy of that data. |
| CWE-375 | Returning a Mutable Object to an Untrusted Caller | This vulnerability occurs when a method directly returns a reference to its internal mutable data, allowing untrusted calling code to modify that data unexpectedly. |
| CWE-382 | J2EE Bad Practices: Use of System.exit() | This vulnerability occurs when a J2EE application directly calls System.exit(), which forcibly terminates the entire application server process, not just the application itself. |
| CWE-383 | J2EE Bad Practices: Direct Use of Threads | Creating or managing threads directly within a J2EE application is a risky practice that violates the platform's standards and often leads to unstable applications. |
| CWE-395 | Use of NullPointerException Catch to Detect NULL Pointer Dereference | Using a try-catch block for NullPointerException as a substitute for proper null checks is an anti-pattern. This approach masks the root cause of null pointer dereferences instead of preventing them, leading to unstable and difficult-to-debug code. |
| CWE-396 | Declaration of Catch for Generic Exception | This weakness occurs when code catches a generic exception type like 'Exception' or 'Throwable', which can hide specific errors and create insecure error handling logic. |
| CWE-397 | Declaration of Throws for Generic Exception | This vulnerability occurs when a method is declared to throw an overly broad exception type, such as a generic 'Exception' or 'Throwable'. This practice masks the specific error conditions that can occur, making it difficult for calling code to handle failures appropriately. |
| CWE-460 | Improper Cleanup on Thrown Exception | This vulnerability occurs when a program fails to properly restore its state or release resources after an exception is thrown, leaving the application in an inconsistent or unexpected condition. |
| CWE-462 | Duplicate Key in Associative List (Alist) | This vulnerability occurs when an associative list (alist) contains duplicate keys, which can cause unexpected behavior when software incorrectly handles or interprets these duplicates. |
| CWE-470 | Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') | This vulnerability occurs when an application uses unvalidated external input, like a URL parameter or form field, to dynamically decide which class to load or which method to execute via reflection. An attacker can manipulate this input to force the application to load unexpected, potentially malicious code. |
| CWE-476 | NULL Pointer Dereference | This vulnerability occurs when a program attempts to access or manipulate memory using a pointer that is set to NULL, causing a crash or unexpected behavior. |
| CWE-478 | Missing Default Case in Multiple Condition Expression | This vulnerability occurs when code with multiple conditional branches, like a switch statement, lacks a default case to handle unexpected values. |
| CWE-481 | Assigning instead of Comparing | This flaw occurs when a developer accidentally uses the assignment operator (=) instead of the comparison operator (== or ===). The code assigns a value when it was meant to check for equality, which fundamentally changes the program's logic. |
| CWE-484 | Omitted Break Statement in Switch | This vulnerability occurs when a developer forgets to include a 'break' statement inside a switch-case block. Without it, the code execution 'falls through' and unintentionally runs the logic for subsequent cases, leading to unexpected behavior. |
| CWE-486 | Comparison of Classes by Name | This vulnerability occurs when an application determines an object's trustworthiness or behavior solely by checking its class name. Since multiple classes can share identical names across different packages or classloaders, this comparison can lead to using the wrong, potentially malicious, class. |
| CWE-487 | Reliance on Package-level Scope | This weakness occurs when a Java application mistakenly treats package-level access as a security boundary, assuming it can prevent unauthorized access to code. |
| CWE-491 | Public cloneable() Method Without Final ('Object Hijack') | This vulnerability occurs when a class implements a public clone() method without declaring it final. This allows attackers to create copies of objects without invoking their constructors, potentially leaving the cloned object in an inconsistent or insecure state. |
| CWE-492 | Use of Inner Class Containing Sensitive Data | Using inner classes to handle sensitive data can unintentionally expose that data because of how Java compiles them. The compiler transforms inner classes into separate, package-visible classes, which can bypass the intended private access restrictions. |
| CWE-493 | Critical Public Variable Without Final Modifier | This vulnerability occurs when a security-sensitive variable is declared as public but not marked as final, allowing untrusted code to unexpectedly change its value after initialization. |
| CWE-495 | Private Data Structure Returned From A Public Method | This vulnerability occurs when a public method directly returns a reference to a private, internal data structure. Because the reference is live, external callers can bypass intended controls and modify the data unexpectedly, corrupting the application's state. |
| CWE-496 | Public Data Assigned to Private Array-Typed Field | This vulnerability occurs when a developer stores sensitive data in a private array, but then assigns a publicly accessible reference to that same array. This effectively makes all the private array's contents available to unauthorized code, bypassing intended access controls. |
| CWE-498 | Cloneable Class Containing Sensitive Information | This vulnerability occurs when a class containing sensitive information, such as credentials or personal data, is made cloneable. Attackers can bypass normal initialization and access the sensitive data by creating a copy of the object. |
| CWE-499 | Serializable Class Containing Sensitive Data | This vulnerability occurs when a class containing sensitive information, such as credentials or personal data, is left serializable by default. Because the class does not explicitly prevent serialization, its internal data can be accessed and extracted by other parts of the application or external processes. |
| CWE-5 | J2EE Misconfiguration: Data Transmission Without Encryption | This vulnerability occurs when a J2EE application transmits sensitive data, like login credentials or session tokens, across a network without using strong encryption. Attackers monitoring the network can easily intercept, read, or even alter this information if it's sent in plain text or protected by weak cryptographic methods. |
| CWE-500 | Public Static Field Not Marked Final | This vulnerability occurs when a class exposes a public static field without declaring it as final, allowing unintended modification from anywhere in the application. |
| CWE-502 | Deserialization of Untrusted Data | This vulnerability occurs when an application accepts and processes serialized data from an untrusted source without proper validation, allowing an attacker to manipulate the data to execute malicious code or cause unexpected behavior. |
| CWE-537 | Java Runtime Error Message Containing Sensitive Information | This vulnerability occurs when a Java application's runtime error messages reveal sensitive details about the system, such as file paths, internal IP addresses, or stack traces. Attackers can exploit these overly informative error messages to map the application's structure and gather intelligence for further attacks. |
| CWE-543 | Use of Singleton Pattern Without Synchronization in a Multithreaded Context | This vulnerability occurs when a singleton pattern is implemented in a multithreaded application without proper synchronization, potentially leading to multiple instances or corrupted state. |
| CWE-567 | Unsynchronized Access to Shared Data in a Multithreaded Context | This vulnerability occurs when multiple threads in an application can read and modify shared data, like static variables, without proper coordination. This unsynchronized access corrupts data, causes crashes, and leads to unpredictable, often security-critical, behavior. |
| CWE-568 | finalize() Method Without super.finalize() | This vulnerability occurs when a Java class overrides the finalize() method but fails to call super.finalize() within it. |
| CWE-572 | Call to Thread run() instead of start() | This vulnerability occurs when a program incorrectly calls a thread's `run()` method directly, instead of using the `start()` method. This mistake causes the thread's code to execute within the caller's current thread, bypassing the creation of a new, concurrent thread of execution. |
| CWE-574 | EJB Bad Practices: Use of Synchronization Primitives | This vulnerability occurs when an Enterprise JavaBeans (EJB) component improperly uses thread synchronization primitives, violating the EJB specification's design principles. |
| CWE-575 | EJB Bad Practices: Use of AWT Swing | This vulnerability occurs when an Enterprise JavaBeans (EJB) component incorrectly uses AWT or Swing UI toolkits, violating the EJB specification's design principles. |
| CWE-576 | EJB Bad Practices: Use of Java I/O | This vulnerability occurs when an Enterprise JavaBeans (EJB) component incorrectly uses Java I/O (java.io) operations to access the file system, violating the EJB specification's design principles. |
| CWE-577 | EJB Bad Practices: Use of Sockets | This vulnerability occurs when an Enterprise JavaBeans (EJB) component breaks the EJB specification by directly creating or using network sockets. |
| CWE-578 | EJB Bad Practices: Use of Class Loader | This vulnerability occurs when an Enterprise JavaBeans (EJB) component directly manipulates the Java class loader, violating the EJB specification's security and portability rules. |
| CWE-579 | J2EE Bad Practices: Non-serializable Object Stored in Session | This vulnerability occurs when a Java application stores an object in the user's session that cannot be serialized, which can break critical application features and hurt reliability. |
| CWE-580 | clone() Method Without super.clone() | This vulnerability occurs when a class's clone() method creates a new object directly instead of calling super.clone(). |
| CWE-581 | Object Model Violation: Just One of Equals and Hashcode Defined | This vulnerability occurs when a Java class defines either the equals() method or the hashCode() method, but not both, breaking a fundamental contract of object equality. |
| CWE-582 | Array Declared Public, Final, and Static | This vulnerability occurs when an array is declared as public, final, and static, which does not protect the data inside the array from being altered. |
| CWE-583 | finalize() Method Declared Public | This vulnerability occurs when a Java class declares its finalize() method as public, violating secure coding practices for mobile code. |
| CWE-585 | Empty Synchronized Block | An empty synchronized block is a Java code construct where a synchronized block exists but contains no executable statements inside it. |
| CWE-586 | Explicit Call to Finalize() | This vulnerability occurs when code directly calls an object's finalize() method from outside its designated finalizer context. |
| CWE-594 | J2EE Framework: Saving Unserializable Objects to Disk | This vulnerability occurs when a J2EE application framework attempts to save objects to disk that cannot be properly serialized, risking application failure. |
| CWE-595 | Comparison of Object References Instead of Object Contents | This vulnerability occurs when code incorrectly checks if two object references point to the same memory location, rather than comparing the actual data or values contained within the objects. This mistake prevents the software from correctly identifying when two separate objects hold equivalent content. |
| CWE-6 | J2EE Misconfiguration: Insufficient Session-ID Length | This vulnerability occurs when a J2EE application uses session identifiers that are too short, making them easier for attackers to predict or capture. |
| CWE-607 | Public Static Final Field References Mutable Object | This vulnerability occurs when a class exposes a public or protected static final field that points to a changeable object. Because the field's reference is constant but the object itself is not, malicious code or even accidental code in other packages can modify the object's contents, violating the intended immutability. |
| CWE-608 | Struts: Non-private Field in ActionForm Class | This vulnerability occurs when an Apache Struts ActionForm class exposes a field without declaring it as private. This allows other parts of the application to directly read or modify the field's data, bypassing the intended setter and getter methods. |
| CWE-609 | Double-Checked Locking | Double-checked locking is an insufficient synchronization pattern where a program checks a resource's state, acquires a lock, and checks the state again before initialization, failing to guarantee thread safety across all systems. |
| CWE-7 | J2EE Misconfiguration: Missing Custom Error Page | This vulnerability occurs when a J2EE application uses the server's default error pages instead of custom ones, potentially leaking sensitive system details. |
| CWE-766 | Critical Data Element Declared Public | This vulnerability occurs when a critical piece of data—like a variable, field, or class member—is mistakenly declared as public when it should be kept private according to the application's security design. |
| CWE-767 | Access to Critical Private Variable via Public Method | This vulnerability occurs when a class exposes a public method that directly accesses or alters a private variable. |
| CWE-917 | Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') | Expression Language Injection occurs when an application uses untrusted, external input to build an expression language statement—common in frameworks like Java Server Pages (JSP)—without properly sanitizing it. This allows an attacker to inject malicious expressions that alter the intended logic and execute arbitrary code when the statement is processed. |
| CWE-95 | Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') | This vulnerability occurs when an application takes user input and passes it directly into a dynamic code execution function, like eval(), without properly sanitizing it. This allows an attacker to inject and execute arbitrary code within the application's context. |
Mapping Notes
Usage: Prohibited
Reasons: View
Rationale:
This entry is a View. Views are not weaknesses and therefore inappropriate to describe the root causes of vulnerabilities.
Comment:
Use this View or other Views to search and navigate for the appropriate weakness.