Codereview-Error-Handling

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.

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