Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types. Medium Availability: Integer coercion often leads to undefined states of execution resulting in infinite loops or crashes. Access Control: In some cases, integer coercion errors can lead to exploitable buffer overflow conditions, resulting in the execution of arbitrary code. Integrity: Integer coercion errors result in an incorrect value being stored for the variable in question. Requirements specification: A language which throws exceptions on ambiguous data casts might be chosen. Design: Design objects and program flow such that multiple or complex casts are unnecessary Implementation: Ensure that any data type casting that you must used is entirely understood in order to reduce the plausibility of error in use. See the Examples section of the problem type Unsigned to signed conversion error for an example of integer coercion errors. Several flaws fall under the category of integer coercion errors. For the most part, these errors in and of themselves result only in availability and data integrity issues. However, in some circumstances, they may result in other, more complicated security related flaws, such as buffer overflow conditions. 1000 Category ChildOf 189 1000 Weakness CanAlsoBe 195 1000 Weakness CanAlsoBe 196 1000 Weakness CanAlsoBe 197 1000 Weakness CanAlsoBe 194 Integer coercion error C C++ Java .NET Implementation Weaknesses in this category are caused by inadequately implemented protection schemes that use the STRUTS framework. 1000 Weakness ChildOf 100 Java The application uses multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect. This could introduce other weaknesses and indicates that validation logic is not up-to-date. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Two validation forms with the same name. ]]> ... ... ]]> It is critically important that validation logic be maintained and kept in sync with the rest of the application. If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations. Moreover, it indicates that the validation logic is not being maintained, and can indicate that other, more subtle validation errors are present. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities can all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Duplicate Validation Forms Java The application has a validator form that either fails to define a validate() method, or defines a validate() method but fails to call super.validate(). This could introduce other weaknesses related to missing input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) The Struts Validator uses a form's validate() method to check the contents of the form properties against the constraints specified in the associated validation form. That means the following classes have a validate() method that is part of the validation framework: ValidatorForm, ValidatorActionForm, DynaValidatorForm, and DynaValidatorActionForm. If you create a class that extends one of these classes, and if your class implements custom validation logic by overriding the validate() method, you must call super.validate() in your validate() implementation. If you do not, the Validation Framework cannot check the contents of the form against a validation form. In other words, the validation framework will be disabled for the given form. Disabling the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Erroneous validate() Method Java If a form bean does not extend an ActionForm subclass of the Validator framework, it can expose the application to other weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) In order to use the Struts Validator, a form must extend one of the following: ValidatorForm, ValidatorActionForm, DynaValidatorActionForm, and DynaValidatorForm. You must extend one of these classes because the Struts Validator ties in to your application by implementing the validate() method in these classes. Forms derived from the ActionForm and DynaActionForm classes cannot use the Struts Validator. Bypassing the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is an important component of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Form Bean Does Not Extend Validation Class Java The application has a form field that is not validated by a corresponding validation form, which can introduce other weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Ensure that you validate all form fields. If a field is unused, it is still important to constrain them so that they are empty or undefined. Omitting validation for even a single input field may give attackers the leeway they need to compromise your application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities can stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. Some applications use the same ActionForm for more than one purpose. In situations like this, some fields may go unused under some action mappings. It is critical that unused fields be validated too. Preferably, unused fields should be constrained so that they can only be empty or undefined. If unused fields are not validated, shared business logic in an action may allow attackers to bypass the validation checks that are performed for other uses of the form. 1000 Weakness ChildOf 101 Struts: Form Field Without Validator Java When an application does not use an input validation framework such as the Struts Validator, there is a greater risk of introducing weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Unchecked input is the leading cause of vulnerabilities in J2EE applications. Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. To prevent such attacks, use the Struts Validator to check all program input before it is processed by the application. Ensure that there are no holes in your configuration of the Struts Validator. Example uses of the validator include checking to ensure that: * Phone number fields contain only valid characters in phone numbers * Boolean values are only "T" or "F" * Free-form strings are of a reasonable length and composition 1000 Weakness ChildOf 101 Struts: Plug-in Framework Not In Use Java An unused validation form indicates that validation logic is not up-to-date. Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an unused validation form. 1000 Weakness ChildOf 101 Struts: Unused Validation Form Java Every Action Form must have a corresponding validation form. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) If a Struts Action Form Mapping specifies a form, it must have a validation form defined under the Struts Validator. If an action form mapping does not have a validation form defined, it may be vulnerable to a number of attacks that rely on unchecked input. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. An action or a form may perform validation in other ways, but the Struts Validator provides an excellent way to verify that all input receives at least a basic level of checking. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated. 1000 Weakness ChildOf 101 Struts: Unvalidated Action Form Java Automatic filtering via a Struts bean has been turned off, which disables the Struts Validator and custom validation logic. This exposes the application to other weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Ensure that an action form mapping enables validation. An action form mapping that disables validation. ]]>]]> Disabling validation exposes this action to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. The Action Form mapping in the demonstrative example disables the form's validate() method. The Struts bean: write tag automatically filters special HTML characters, replacing a < with &lt and a > with &gt. This action can be disabled by specifying filter="false" as an attribute of the tag to disable specified JSP pages. However, being disabled makes these pages susceptible to cross-site scripting attacks. An attacker may be able to insert malicious scripts as user input to write to these JSP pages. 1000 Weakness ChildOf 101 Struts: Validator Turned Off Java Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Example 1.a: An action form with two fields. Example 1.a shows an action form that has two fields, startDate and endDate. Example 1.b: A validation form with a third field. <]]> ]]> ]]>]]> Example 1.b lists a validation form for the action form. The validation form lists a third field: scale. The presence of the third field suggests that DateRangeForm was modified without taking validation into account. It is easy for developers to forget to update validation logic when they make changes to an ActionForm class. One indication that validation logic is not being properly maintained is inconsistencies between the action form and the validation form. It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Validator Without Form Field Java 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. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) 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. class Echo { public native void runEcho(); static { System.loadLibrary("echo"); } public static void main(String[] args) { new Echo().runEcho(); } } The following C code defines the native method implemented in the Echo class: Java #inc]]> JNIEX]]> 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 perform any bounds checking on 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 leak in the Java application that exposes its use of JNI [See Reference]. Native code is unprotected by the security features enforced by the runtime environment, such as strong typing and array bounds checking. 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. Other programming languages that may be more susceptible to buffer overflows and other attacks, such as C or C++, usually implement native code. Language-based encapsulation is broken. Fortify Software Fortify Descriptions http://vulncat.fortifysoftware.com B. Stearns The Java™ Tutorial: The Java Native Interface Sun Microsystems 2005 http://java.sun.com/docs/books/tutorial/native1.1/ 1000 Weakness ChildOf 100 Unsafe JNI Java The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result. This can happen in signed and unsigned cases. "Integer underflow" is sometimes used to identify signedness errors in which an originally positive number becomes negative as a result of subtraction. However, there are cases of bad subtraction in which unsigned integers are involved, so it's not always a signedness issue. "Integer underflow" is occasionally used to describe array index errors in which the index is negative. CVE-2004-0816 Integer underflow in firewall via malformed packet. CVE-2004-1002 Integer underflow by packet with invalid length. CVE-2005-0199 Long input causes incorrect length calculation. CVE-2005-1891 Malformed icon causes integer underflow in loop counter variable. Under-studied. 1000 Weakness ChildOf 682 1000 Category ChildOf 189 Integer underflow (wrap or wraparound) C C++ Java .NET Implementation If one extends a signed number incorrectly, if negative numbers are used, an incorrect extension may result. High Integrity: If one attempts to sign extend a negative variable with an unsigned extension algorithm, it will produce an incorrect result. Authorization: Sign extension errors -- if they are used to collect information from smaller signed sources -- can often create buffer overflows and other memory based problems. Implementation: Use a sign extension library or standard function to extend signed numbers. Implementation: When extending signed numbers fill in the new bits with 0 if the sign bit is 0 or fill the new bits with 1 if the sign bit is 1. C Sign extension errors -- if they are used to collect information from smaller signed sources -- can often create buffer overflows and other memory based problems. 1000 Weakness ChildOf 682 1000 Category ChildOf 189 Sign extension error C C++ Java .NET Implementation Truncation errors occur when a primitive is cast to a primitive of a smaller size and data is lost in the conversion. Low Integrity: The true value of the data is lost and corrupted data is used. Implementation: Ensure that no casts, implicit or explicit, take place that move from a larger size primitive or a smaller size primitive. This example, while not exploitable, shows the possible mangling of values associated with truncation errors: int main() { ]]> The above code, when compiled and run, returns the following output: Int MAXINT: 2147483647 Short MAXINT: -1 A frequent paradigm for such a problem being exploitable is when the truncated value is used as an array index, which can happen implicitly when 64-bit values are used as indexes, as they are truncated to 32 bits. When a primitive is cast to a smaller primitive, the high order bits of the large value are lost in the conversion, potentially resulting in an unexpected value that is not equal to the original value. This value may be required as an index into a buffer, a loop iterator, or simply necessary state data. In any case, the value cannot be trusted and the system will be in an undefined state. While this method may be employed viably to isolate the low bits of a value, this usage is rare, and truncation usually implies that an implementation error has occurred. Under-studied and under-reported. 1000 Weakness ChildOf 681 1000 Category ChildOf 189 1000 Weakness CanAlsoBe 195 1000 Weakness CanAlsoBe 196 1000 Category CanAlsoBe 192 1000 Weakness CanAlsoBe 194 Numeric truncation error Truncation error C C++ Java .NET Implementation The J2EE application directly manages connections, instead of using the container's connection management facilities. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) The J2EE standard forbids the direct management of connections. It requires that applications use the container's resource management facilities to obtain connections to resources. For example, a J2EE application should obtain a database connection as follows: ctx = new InitialContext(); datasource = (DataSource)ctx.lookup(DB_DATASRC_REF); conn = datasource.getConnection(); and should avoid obtaining a connection in this way: conn = DriverManager.getConnection(CONNECT_STRING); Every major web application container provides pooled database connection management as part of its resource management framework. Duplicating this functionality in an application is difficult and error prone, which is part of the reason it is forbidden under the J2EE standard. 1000 Weakness ChildOf 573 J2EE Bad Practices: getConnection() Java The J2EE application directly uses sockets instead of using framework method calls. Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Use framework method calls instead of using sockets directly. The J2EE standard permits the use of sockets only for the purpose of communication with legacy systems when no higher-level protocol is available. Authoring your own communication protocol requires wrestling with difficult security issues, including: - In-band versus out-of-band signaling - Compatibility between protocol versions - Channel security - Error handling - Network constraints (firewalls) - Session management Without significant scrutiny by a security expert, chances are good that a custom communication protocol will suffer from security problems. Many of the same issues apply to a custom implementation of a standard protocol. While there are usually more resources available that address security concerns related to implementing a standard protocol, these resources are also available to attackers. 1000 Weakness ChildOf 573 J2EE Bad Practices: Sockets Java Failing to catch an exception thrown from a dangerous function can potentially cause the program to crash. The _alloca() function allocates memory on the stack. If an allocation request is too large for the available stack space, _alloca() throws an exception. If the exception is not caught, the program will crash, potentially enabling a denial of service attack. _alloca() has been deprecated as of Microsoft Visual Studio 2005®. It has been replaced with the more secure _alloca_s(). EnterCriticalSection() can raise an exception, potentially causing the program to crash. Under operating systems prior to Windows 2000, the EnterCriticalSection() function can raise an exception in low memory situations. If the exception is not caught, the program will crash, potentially enabling a denial of service attack. 1000 Category ChildOf 389 1000 Weakness ChildOf 691 Often Misused: Exception Handling C C++ Java .NET 54 The code contains a switch statement in which the switched variable can be modified while the switch is still executing, resulting in unexpected behavior. Medium Undefined: This flaw will result in the system state going out of sync. Implementation: Variables that may be subject to race conditions should be locked for the duration of any switch statements. C C++ ]]> int]]>st_ctime); ]]>st_ctime % 2){ ]]> This issue is particularly important in the case of switch statements that involve fall-through style case statements -- ie., those which do not end with break. If the variable which we are switching on change in the course of execution, the actions carried out may place the state of the process in a contradictory state or even result in memory corruption. For this reason, it is important to ensure that all variables involved in switch statements are locked before the statement starts and are unlocked when the statement ends. 1000 Weakness ChildOf 362 1000 Weakness PeerOf 364 1000 Weakness PeerOf 366 Race condition in switch C C++ Java .NET 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. Medium System Process Integrity: The main problem is that -- if a lock is overcome -- data could be altered in a bad state. Design: Use locking functionality. This is the recommended solution. Implement some form of locking mechanism around code which alters or reads persistent data in a multi-threaded environment. Design: Create resource-locking sanity checks. If no inherent locking mechanisms exist, use flags and signals to enforce your own blocking scheme when resources are being used by other threads of execution. C C++ foo) foo = num;]]> Java 1000 Weakness ChildOf 362 1000 Category ChildOf 557 631 Category ChildOf 634 Race condition within a thread C C++ Java .NET 26 29 Sending non-cloned mutable data as an argument may result in that data being altered or deleted by the called function, thereby putting the calling function into an undefined state. Medium Integrity: Potentially data could be tampered with by another function which should not have been tampered with. Implementation: Pass in data which should not be altered as constant or immutable. Implementation: Clone all mutable data before returning references to it. This is the preferred mitigation. This way -- regardless of what changes are made to the data -- a valid copy is retained for use by the class. C C++ In this example, bar and baz will be passed by reference to doOtherStuff() which may change them. In situations where unknown code is called with references to mutable data, this external code may possibly make changes to the data sent. If this data was not previously cloned, you will be left with modified data which may, or may not, be valid in the context of execution. 1000 Category ChildOf 371 1000 Weakness ChildOf 668 Mutable objects passed by reference C C++ Java .NET Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function, thereby putting the class in an undefined state. Medium Access Control / Integrity: Potentially data could be tampered with by another function which should not have been tampered with. Implementation: Pass in data which should not be altered as constant or immutable. Implementation: Clone all mutable data before returning references to it. This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class. C C++ Java In situations where functions return references to mutable data, it is possible that this external code, which called the function, may make changes to the data sent. If this data was not previously cloned, you will be left with modified data which may, or may not, be valid in the context of the class in question. 1000 Category ChildOf 371 1000 Weakness ChildOf 668 Passing mutable objects to an untrusted method C C++ Java .NET A J2EE application uses System.exit(), which also shuts down its container. Access to a function that can shut down the application is an avenue for Denial of Service (DoS) attacks. The shutdown function should be a privileged function available only to a properly authorized administrative user. Any other possible cause of a shutdown is generally a security vulnerability. (In rare cases, the intended security policy calls for the application to halt as a damage control measure when it determines that an attack is in progress.) Web applications should not call methods that cause the virtual machine to exit, such as System.exit(). Web applications should also not throw any Throwables to the application server as this may adversely affect the container. Non-web applications may have a main() method that contains a System.exit(), but generally should not call System.exit() from other locations in the code. It is never a good idea for a web application to attempt to shut down the application container. A call to System.exit() is probably part of leftover debug code or code imported from a non-J2EE application. 1000 Weakness ChildOf 691 1000 Category ChildOf 381 J2EE Bad Practices: System.exit() Java Thread management in a Web application is forbidden in some circumstances and is always highly error prone. System Process For EJB, use framework approaches for parallel execution, instead of using threads. Thread management in a web application is forbidden by the J2EE standard in some circumstances and is always highly error prone. Managing threads is difficult and is likely to interfere in unpredictable ways with the behavior of the application container. Even without interfering with the container, thread management usually leads to bugs that are hard to detect and diagnose like deadlock, race conditions, and other synchronization errors. 1000 Category ChildOf 381 631 Category ChildOf 634 J2EE Bad Practices: Threads Java Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer. Do not extensively rely on catching exceptions (especially for validating user input) to handle errors. Handling exceptions can decrease the performance of an application. The following code mistakenly catches a NullPointerException. Programmers typically catch NullPointerException under three circumstances: 1. The program contains a null pointer dereference. Catching the resulting exception was easier than fixing the underlying problem. 2. The program explicitly throws a NullPointerException to signal an error condition. 3. The code is part of a test harness that supplies unexpected input to the classes under test. Of these three circumstances, only the last is acceptable. 1000 Category ChildOf 389 1000 Weakness ChildOf 691 Catching NullPointerException Java Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. The following code excerpt handles three types of exceptions in an identical fashion. At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows: try { doExchange(); } catch (Exception e) { logger.error("doExchange failed", e); } However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent. Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention. 1000 Category ChildOf 389 Overly-Broad Catch Block C C++ Java .NET Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities. The following method throws three types of exceptions. While it might seem tidier to write 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. Declaring a method to throw Exception or Throwable makes it difficult for callers to do good error handling and error recovery. Java's exception mechanism 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. 1000 Category ChildOf 389 Overly-Broad Throws Declaration C C++ Java .NET The product does not sufficiently clean up its state when an exception is thrown, leading to unexpected state or control flow. Medium Implementation: The code could be left in a bad state. Implementation: If one breaks from a loop or function by throwing an exception, make sure that cleanup happens or that you should exit the program. Use throwing exceptions sparsely. C++ Java In this case, you may leave a thread locked accidentally. Often, when functions or loops become complicated, some level of cleanup in the beginning to the end is needed. Often, since exceptions can disturb the flow of the code, one can leave a code block in a bad state. 1000 Weakness ChildOf 459 1000 Category ChildOf 452 Improper cleanup on thrown exception C C++ Java .NET Duplicate keys in associative lists can lead to non-unique keys being mistaken for an error. Low Design: Use a hash table instead of an alist. Design: Use an alist which checks the uniqueness of hash keys with each entry before inserting the entry. A duplicate key entry -- if the alist is designed properly -- could be used as a constant time replace function. However, duplicate key entries could be inserted by mistake. Because of this ambiguity, duplicate key entries in an association list are not recommended and should not be allowed. In Python: alist = [] while (foo()): #now assume there is a string data with a key basename queue.append(basename,data) queue.sort() Since basename is not necessarily unique, this may not sort how one would like it to be. 1000 Category ChildOf 461 Duplicate key in associative list (alist) C C++ Java .NET The application uses reflection capabilities to manage classes or code, but does not sufficiently control which classes or code can be selected based on external input. By leveraging reflection capabilities, an attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks. Example: A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection: The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher. However, the refactoring allows an attacker to instantiate any object that implements the Worker interface. If the command dispatcher is still responsible for access control, then whenever programmers create a new class that implements the Worker interface, they must remember to modify the dispatcher's access control code. If they fail to modify the access control code, then some Worker classes will not have any access control. One way to address this access control problem is to make the Worker object responsible for performing the access control check. An example of the re-refactored code follows: String ctl = request.getParameter("ctl"); Class cmdClass = Class.forName(ctl + "Command"); Worker ao = (Worker) cmdClass.newInstance(); ao.checkAccessControl(request); ao.doAction(request); Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes. This code also highlights another security problem with using reflection to build a command dispatcher. An attacker can invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the Worker interface; the default constructor for any object in the system can be invoked. If the object does not implement the Worker interface, a ClassCastException will be thrown before the assignment to ao, but if the constructor performs operations that work in the attacker's favor, the damage will already have been done. Although this scenario is relatively benign in simple applications, in larger applications where complexity grows exponentially it is not unreasonable that an attacker could find a constructor to leverage as part of an attack. If an attacker can supply values that the application then uses to determine which class to instantiate or which method to invoke, the potential exists for the attacker to create control flow paths through the application that were not intended by the application developers. This attack vector may allow the attacker to bypass authentication or access control checks or otherwise cause the application to behave in an unexpected manner. This situation becomes a doomsday scenario if the attacker can upload files into a location that appears on the application's classpath or add new entries to the application's classpath. Under either of these conditions, the attacker can use reflection to introduce new, presumably malicious, behavior into the application. 1000 Weakness ChildOf 398 1000 Weakness ChildOf 610 Unsafe Reflection Java A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. Medium Resultant (Weakness is typically related to the presence of some other weaknesses) Availability: NULL pointer dereferences usually result in the failure of the process. In very rare circumstances and environments, code execution is possible. Requirements specification: The choice could be made to use a language that is not susceptible to these issues. Implementation: If all pointers that could have been modified are sanity-checked previous to use, nearly all NULL pointer dereferences can be prevented. Example 1: NULL pointer dereference issue can occur through a number of flaws, including race conditions, and simple programming omissions. While there are no complete fixes aside from conscientious programming, the following steps will go a long way to ensure that NULL pointer dereferences do not occur. Before using a pointer, ensure that it is not equal to NULL: When freeing pointers, ensure they are not set to NULL, and be sure to set them to NULL once they are freed: If you are working with a multi-threaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the if statement; and unlock when it has finished. Example 2: In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a NULL pointer exception when it attempts to call the trim() method. Java CVE-2005-3274 race condition causes a table to be corrupted if a timer activates while it is being modified, leading to resultant NULL dereference; also involves locking. CVE-2002-1912 large number of packets leads to NULL dereference CVE-2005-0772 packet with invalid error status value triggers NULL dereference CVE-2004-0079 CVE-2004-0365 CVE-2003-1013 CVE-2003-1000 CVE-2004-0389 CVE-2004-0119 CVE-2004-0458 CVE-2002-0401 NULL pointer dereferences, while common, can generally be found and corrected in a simply way. They will always result in the crash of the process unless exception handling (on some platforms) is invoked, and even then, little can be done to salvage the process. NULL pointer dereferences are frequently resultant from rarely encountered error conditions, since these are most likely to escape detection during the testing phases. 1000 Weakness ChildOf 398 1000 Weakness PeerOf 373 630 View ChildOf 630 1000 690 Compound_Element CanPrecede 690 Null Dereference Null-pointer dereference Null Dereference (Null Pointer Dereference) C C++ Java .NET A weakness where the code path has: 1. start statement that assigns a null value to the pointer 2. end statement that dereferences a pointer 3. the code path does not contain any other statement that assigns value to the pointer The failure to account for the default case in switch statements may lead to complex logical errors and may aid in other, unexpected security-related conditions. Undefined: Depending on the logical circumstances involved, any consequences may result: e.g., issues of confidentiality, authentication, authorization, availability, integrity, accountability, or non-repudiation. Implementation: Ensure that there are no unaccounted for cases, when adjusting flow or values based on the value of a given variable. In switch statements, this can be accomplished through the use of the default label. In general, a safe switch statement has this form: This is because the assumption cannot be made that all possible cases are accounted for. A good practice is to reserve the default case for error handling. This flaw represents a common problem in software development, in which not all possible values for a variable are considered or handled by a given process. Because of this, further decisions are made based on poor information, and cascading failure results. This cascading failure may result in any number of security issues, and constitutes a significant failure in the system. In the case of switch style statements, the very simple act of creating a default case can mitigate this situation, if done correctly. Often however, the default cause is used simply to represent an assumed option, as opposed to working as a sanity check. This is poor practice and in some cases is as bad as omitting a default case entirely. 1000 Weakness ChildOf 398 Failure to account for default case in switch C C++ Java .NET The code uses an operator for assignment when the intention was to perform a comparison. In many languages the compare statement is very close in appearance to the assignment statement and are often confused. Low Pre-design: Through Build: Many IDEs and static analysis products will detect this problem. Implementation: Place constants on the left. If one attempts to assign a constant with a variable, the compiler will of course produce an error. This bug is generally as a result of a typo and usually should cause obvious problems with program execution. If the comparison is in an if statement, the if statement will always return the value of the right-hand side variable. 1000 Weakness ChildOf 480 1000 Category ChildOf 569 Assigning instead of comparing C C++ Java .NET The program omits a break statement within a switch or other construct, causing the same code to execute in multiple conditions, when it is only expected to execute in one condition. Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should not be used. Medium Omission of a break statement might be intentional, in order to support fallthrough. Semantic understanding of expected program behavior is required to interpret whether the code is correct. Pre-design through Build: Most static analysis programs should be able to catch these errors. Implementation: The functionality of omitting a break statement could be clarified with an if statement. This method is much safer. Java C C++ Now one might think that if they just tested case12, it will display that the respective month "is a great month." However, if one tested November, one notice that it would display "November December is a great month." While most languages with similar constructs automatically run only a single branch, C and C++ are different. This has bitten many programmers, and can lead to critical code executing in situations where it should not. 1000 Weakness ChildOf 398 1000 Weakness ChildOf 670 Omitted break statement C C++ Java .NET The program compares classes by name, which can cause it to use the wrong class if two different classes are treated as the same. High Authorization: If a program relies solely on the name of an object to determine identity, it may execute the incorrect or unintended code. 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. 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. 1000 Weakness ChildOf 485 Comparing Classes by Name Comparing classes by name Java Java packages are not inherently closed; therefore, relying on them for code security is not a good practice. Medium Confidentiality: Any data in a Java package can be accessed outside of the Java framework if the package is distributed. Integrity: The data in a Java class can be modified by anyone outside of the Java framework if the packages is distributed. Design through Implementation: Data should be private static and final whenever possible. This will assure that your code is protected by instantiating early, preventing access and tampering. Java The purpose of package scope is to prevent accidental access. However, this protection provides an ease-of-software-development feature but not a security feature, unless it is sealed. 1000 Weakness ChildOf 485 Relying on package-level scope Java 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. 1000 Category ChildOf 490 Mobile Code: Object Hijack Java 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. Medium Confidentiality: "Inner Classes" data confidentiality aspects can often be overcome. Implementation: Using sealed classes protects object-oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways. Implementation: Inner Classes do not provide security. Warning: Never reduce the security of the object from an outer class, going to an inner class. If your outer class is final or private, ensure that your inner class is private as well. Example: The following Java Applet code mistakenly makes use of an inner class. Java Inner classes quietly introduce several security concerns because of the way they are translated into Java bytecode. In Java source code, it appears that an inner class can be declared to be accessible only by the enclosing class, but Java bytecode has no concept of an inner class, so the compiler must transform an inner class declaration into a peer class with package level access to the original outer class. More insidiously, since an inner class can access private fields in their enclosing class, once an inner class becomes a peer class in bytecode, the compiler converts private fields accessed by the inner class into protected fields. Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running. 1000 Weakness ChildOf 668 1000 Category ChildOf 490 Mobile Code: Use of Inner Class Publicizing of private data when using inner classes Java The product has a critical public variable that is not final, which allows the variable to be modified to contain unexpected values. Declare all public fields final when possible. The following Java Applet code mistakenly declares a member variable public but not final. Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects' state and behavior by adversaries who have access to the same virtual machine where your program is running. All public member variables in an Applet and in classes used by an Applet should be declared final to prevent an attacker from manipulating or gaining unauthorized access to the internal state of the Applet. 1000 Weakness ChildOf 668 1000 Category ChildOf 490 Mobile Code: Non-Final Public Field Java The product downloads external source or binaries and executes it without sufficiently verifying the origin and integrity of the downloaded code. Medium Implementation: Avoid doing this without proper cryptographic safeguards. Java This is an unsafe practice and should not be performed unless one can use some type of cryptographic protection to assure that the mobile code has not been altered. 1000 Category ChildOf 490 1000 Weakness ChildOf 669 1000 Weakness PeerOf 79 Invoking untrusted mobile code Java The product has a method that is declared public, but returns a reference to a private array, which could then be modified in unexpected ways. Declare the method private. Clone the member data and keep an unmodified version of the data private to the object. Use public setter methods that govern how a member can be modified. 1000 Weakness ChildOf 485 Private Array-Typed Field Returned From A Public Method C C++ Java .NET