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

<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

Types of errors: The result of business logic conditions not being met The result of the environment wherein the business logic resides fails. The result of upstream or downstream systems upon which the application depends fail. Technical hardware / physical failure

A failure is never expected but they do occur such like much in life. In the event of a failure it is important not to leave the "doors" of the application open and they keys to other "rooms" within the application sitting on the table. In the course of a logical workflow which is designed based upon requirements errors may occur which can be programatically handled such as a connection pool not being available or a down stream server not being contactable.

Such areas of failure should be examined during the course of the code review. It should be examined if all resources should be released in the case of a failure and during the thread of execution is there any potential for resource leakage, resources being memory, connection pools, file handles etc.

The review of code should also include pinpointing areas where the user session should be terminated or invalidated. Sometimes errors may occur which do not make any logical sense from a business logic perspective or a technical standpoint;

Eg: "A logged in user looking to access an account which is not registered to that user and such data could not be inputted in the normal fashion."

Such conditions reflect possible malicious activity. Here we shoudl review if the code is in any way defenseive and kills the users session object and forwards the user to the login page. (Keep in mind that the session object should be examined upon every HTTP request)

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.