Codereview-Error-Handling - Revision history

Ari Elias-Bachrach: minor cleanup, a LOT more is needed.

2011-06-22T20:23:32Z

minor cleanup, a LOT more is needed.

Thomas Herlea: Added navigation to facilitate sequential reading online

2010-09-09T16:00:10Z

Added navigation to facilitate sequential reading online

KirstenS: /* Web.config */

2009-05-05T12:11:40Z

‎Web.config

KirstenS: /* JAVA */

2009-05-05T12:09:37Z

‎JAVA

KirstenS: /* Try & Catch (Java/ .NET) */

2009-02-11T00:52:42Z

‎Try & Catch (Java/ .NET)

KirstenS: /* Centralised exception handling (Struts Example) */

2009-01-27T17:31:18Z

‎Centralised exception handling (Struts Example)

KirstenS: /* Classic ASP */

2009-01-27T17:29:54Z

‎Classic ASP

KirstenS: /* Try & Catch (Java/ .NET) */

2009-01-27T17:29:07Z

‎Try & Catch (Java/ .NET)

KirstenS: /* Page_Error */

2009-01-27T17:26:50Z

‎Page_Error

KirstenS: /* Page_Error */

2009-01-27T17:26:39Z

‎Page_Error

@@ Line 7: / Line 7: @@
 ==Error Handling==
-Error Handling is important in a number of ways. It may affect the state of the application, or leak system information to a user. The initial failure to cause the error may cause the application to traverse into an insecure state. Weak error handling also aids the attacker, as the errors returned may assist them in constructing 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 successful attacks. There are methods which can circumvent systems with leading practice error handling semantics which should be kept in mind; Attacks such as blind SQL injection using booleanization or response time characteristics can be used to address such generic responses.
+Error Handling is important in a number of ways. It may affect the state of the application, or leak system information to a user. The initial failure to prevent the error may cause the application to traverse into an insecure state. Weak error handling also aids the attacker, as the errors returned may assist them in constructing correct attack vectors. A generic error page for most errors is recommended. This approach makes it more difficult for attackers to identify signatures of potentially successful attacks. There are methods which can circumvent systems with leading error handling practices which should be kept in mind; Attacks such as blind SQL injection using booleanization or response time characteristics can be used to address such generic responses.
 The other key area relating to error handling is the premise 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).
@@ Line 70: / Line 70: @@
 *Technical hardware / physical failure.
-A failure is never expected,  but they do occur. In the event of a failure, it is important not to leave the "doors" of the application open and the 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 programmatically handled, such as a connection pool not being available, or a downstream server not being contactable.
+Failures are never expected, but they do occur. In the event of a failure, it is important not to leave the "doors" of the application open and the 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 programmatically handled, such as a connection pool not being available, or a downstream 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 if there is any potential for resource leakage, resources being memory, connection pools, file handles etc.

@@ Line 1: / Line 1: @@
-[[OWASP Code Review Guide Table of Contents]]__TOC__
+{{LinkBar
-[[Category:OWASP Code Review Project]]
+  | useprev=PrevLink | prev=Codereview-Input Validation | lblprev=Input Validation
 ==Error Handling==
@@ Line 304: / Line 308: @@
 ===Classic ASP===
 For classic ASP pages you need to do some IIS configuration, follow the same link for more information http://support.microsoft.com/kb/299981
 [[Category:OWASP Code Review Project]]

@@ Line 173: / Line 173: @@
 ===Web.config===
-Web.config has a custom error tags which can be used to handle errors. This is called last and if Page_error or Application_error is called and has functionality, that functionality shall be executed first. As long as the previous two handling mechanisms do not redirect or clear (Response.Redirect or a Server.ClearError), this will be called and you shall be forwarded to the page defined in web.config.
+Web.config has custom error tags which can be used to handle errors. This is called last and if Page_error or Application_error is called and has functionality, that functionality shall be executed first. As long as the previous two handling mechanisms do not redirect or clear (Response.Redirect or a Server.ClearError), this will be called and you shall be forwarded to the page defined in web.config.
   <customErrors defaultRedirect="error.html" mode="On|Off|RemoteOnly">

@@ Line 96: / Line 96: @@
 getStackTrace()
-Also important to know is that the output of these methods is printed in System console, the same as System.out.println(e) where e is an Exception. Be sure to not redirect the outputStream to PrintWriter object of JSP, by convention called "out". Ex. printStackTrace(out);
+Also important to know is that the output of these methods is printed in System console, the same as System.out.println(e) where there is an Exception. Be sure to not redirect the outputStream to PrintWriter object of JSP, by convention called "out". Ex. printStackTrace(out);
 Also another object to look at is the java.lang.system package:

@@ Line 244: / Line 244: @@
   End Function
-The second is using an error handler on an error page, to use this method please go to the following URL:
+The second is using an error handler on an error page (http://support.microsoft.com/kb/299981).
   Dim ErrObj

@@ Line 283: / Line 283: @@
 # Register, instantiate the errors under the appropriate severity
-# Identify these messages and show them in a constant manner.
+# Identify these messages and show them in a consistent manner.
 Struts ActionErrors class makes error handling quite easy:

@@ Line 275: / Line 275: @@
 ===Classic ASP===
-For Classic ASP pages it is recommended to enclose all the cleaning in a function and call it into an error handling statement after an "On Error Resume Next".
+For Classic ASP pages it is recommended to enclose all cleaning in a function and call it into an error handling statement after an "On Error Resume Next".
 ===Centralised exception handling (Struts Example)===

@@ Line 227: / Line 227: @@
+          }
-IIn general, it is best practice to catch a specific type of exception rather than use the basic catch(Exception) or catch(Throwable) statement in the case of Java.
+In general, it is best practice to catch a specific type of exception rather than use the basic catch(Exception) or catch(Throwable) statement in the case of Java.
-In classic ASP there are 2 ways to do error handling, the first is using the err object with an On Error Resume Next.
+In classic ASP there are two ways to do error handling, the first is using the err object with an On Error Resume Next.

@@ Line 150: / Line 150: @@
 The text in the example above has a number of issues: Firstly, it redisplays the HTTP request to the user in the form of Request.Url.ToString() Assuming there has been no data validation prior to this point, we are vulnerable to cross site scripting attacks!! Secondly, the error message and stack trace is displayed to the user using Server.GetLastError().ToString() which divulges internal information regarding the application.
-After the Page_Error is called, the Application_Error sub is called:
+After the Page_Error is called, the Application_Error sub is called.
 ===Global.asax===

@@ Line 148: / Line 148: @@
    </script>
-The text in the example above has a number of issues: Firstly, it redisplays the HTTP request to the user in the form of Request.Url.ToString() Assuming there has been no data validation prior to this point, we are vulnerable to cross site scripting attacks!! Secondly the error message and stack trace is displayed to the user using Server.GetLastError().ToString() which divulges internal information regarding the application.
+The text in the example above has a number of issues: Firstly, it redisplays the HTTP request to the user in the form of Request.Url.ToString() Assuming there has been no data validation prior to this point, we are vulnerable to cross site scripting attacks!! Secondly, the error message and stack trace is displayed to the user using Server.GetLastError().ToString() which divulges internal information regarding the application.
 After the Page_Error is called, the Application_Error sub is called: