|
|
Status: Incomplete Weakness ID: 391 (Weakness Base)Description Summary Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed. Likelihood of Exploit Medium Potential Mitigations Requirements Specification: The choice between a language which has named or unnamed exceptions needs to be done. While unnamed exceptions exacerbate the chance of not properly dealing with an exception, named exceptions suffer from the up call version of the weak base class problem. Requirements Specification: A language can be used which requires, at compile time, to catch all serious exceptions. However, one must make sure to use the most current version of the API as new exceptions could be added. Implementation Catch all relevant exceptions. 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. Demonstrative Examples The following code excerpt ignores a rarely-thrown exception from doExchange(). try { doExchange(); } catch (RareException e) { // this can never happen }
If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior. Other Notes Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break. Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions. Relationships
Taxonomy Mappings
Applicable Platforms Languages All Time of Introduction  Architecture and Design ImplementationWhite Box Definitions A weakness where code path has: 1. start statement that changes a state of a system resource 2. end statement that accesses the system resource, where the changed and the assumed state of the system resource are not equal. Maintenance Notes This entry needs significant modification. It currently combines information from three different taxonomies, but each taxonomy is talking about a slightly different issue. Content History Submissions PLOVER. (Externally Mined) Modifications Eric Dalci. Cigital. 2008-07-01. (External) updated Time_of_Introduction KDM Analytics. 2008-08-01. (External) added/updated white box definitions Veracode. 2008-08-15. (External) Suggested OWASP Top Ten 2004 mapping CWE Content Team. MITRE. 2008-09-08. (Internal) updated Maintenance_Notes, Relationships, Other_Notes, Taxonomy_Mappings |
|
|
|||
