Codereview-Error-Handling

OWASP Code Review Guide Table of Contents

Error Handling
Error Handling important in a number of ways. It may effect the state of the application, leak system information to a user, the initial failure to cause the error may cause the application be traverse into an insecure state. Weak error handling also aids the attacked as the errors returned may assist the attacked in constructung correct attack vectors. A generic error page for most errors is recommended when developing code. This approach makes it more difficult for attackers to identify signatures of potentially successfull attacks. There are methods which can circumvent systems with leading practice error handling semantica which should be kept in mind; Attacks such as bling SQL injection using booleanization or response time charictaristics can be used to address such generic responses.

The other key area relaitng to error handling is the premis of "fail securely". Errors induced should not leave the application in an insecure state. Resources should be locked down and released, sessions terminated (if required) and calculations or business logic should be halted (depending on the type of error of course).

Error Handling should be centralised
When reviewing code it is recommended to assess the commonality within the application from a error/exception handling perspective. Frameworks have error handling resources which can be exploited to assist in secure programming and such resources within the framework should be reviewed to assess if the error handling is "wired-up" correctly.

A generic error page should be used for all exceptions if possible. This prevents the attacker identifying internal responses to error states. This also makes it more difficult for automated tools to identify successfull attacks.

Declaritive Exception Handling


This could be found in the struts-config.xml file, a key file when reviewing the wired-up struts environment

Java Servlets and JSP

Specification can be done in web.xml in order to handle unhandled exceptions. When Unhandled exceptions occur but not caught in code the user if forwarded to a generic error page:

 UnhandledException GenericError.jsp 

Also in the case of HTTP 404 or HTTP 500 errors during the review you may find:

 500 GenericError.jsp 

Information burial
Swallowing exceptions into an empty catch block is not advised as an audit trail of the cause of the exception would be incomplete. Actions to take upon an error