This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Codereview-Error-Handling"

From OWASP
Jump to: navigation, search
Line 7: Line 7:
 
When reviewing code it is recommended to assess the commonality within the  application from a error/exception handling perspective.
 
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.
 
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===
 
===Declaritive Exception Handling===
Line 15: Line 17:
  
 
This could be found in the struts-config.xml file, a key file when reviewing the wired-up struts environment
 
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.
 +
 +
  
 
===Failing Securely===
 
===Failing Securely===

Revision as of 14:05, 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.


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