Difference between revisions of "Codereview-Error-Handling"

Revision as of 14:57, 19 August 2008

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

<exception   key=”bank.error.nowonga” 
                   path=”/NoWonga.jsp” 
                   type=”mybank.account.NoCashException”/>

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:

<error-page>
      <exception-type>UnhandledException</exception-type>
      <location>GenericError.jsp</location>
</error-page>

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

<error-page>
 <error-code>500</error-code>
 <location>GenericError.jsp</location>
</error-page>

Failing Securely

Information Leakage

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