CRV2 ErrorHandlingMessages - Revision history

Gary David Robinson at 10:11, 12 October 2014

2014-10-12T10:11:08Z

Gary David Robinson at 16:37, 28 September 2014

2014-09-28T16:37:59Z

Gary David Robinson at 12:12, 5 August 2013

2013-08-05T12:12:15Z

Gary David Robinson at 00:03, 24 July 2013

2013-07-24T00:03:47Z

Gary David Robinson at 23:51, 23 July 2013

2013-07-23T23:51:25Z

Gary David Robinson at 23:42, 23 July 2013

2013-07-23T23:42:44Z

Gary David Robinson at 23:19, 23 July 2013

2013-07-23T23:19:42Z

Gary David Robinson at 22:45, 23 July 2013

2013-07-23T22:45:25Z

Gary David Robinson at 09:19, 26 June 2013

2013-06-26T09:19:49Z

Gary David Robinson at 09:00, 26 June 2013

2013-06-26T09:00:47Z

@@ Line 1: / Line 1: @@
 __TOC__
@@ Line 4: / Line 5: @@
 ==Error Handling==
-Proper error handling is important in two ways: ''<are these the only 2 ways?>''
+Proper error handling is important in two ways:
 # It may affect the state of the application

← Older revision		Revision as of 16:37, 28 September 2014
Line 1:		Line 1:
−	~~= CodeReview - Error Handling =~~

−	~~{{LinkBar~~
−	~~\| useprev=PrevLink \| prev=Codereview-Input Validation \| lblprev=Input Validation~~
−	~~\| usemain=MainLink \| main=OWASP Code Review Guide Table of Contents \| lblmain=Table of Contents~~
−	~~\| usenext=NextLink \| next=Codereview-Deployment \| lblnext=Secure Deployment~~
−	}}
	__TOC__		__TOC__

← Older revision		Revision as of 12:12, 5 August 2013
Line 156:		Line 156:

	There are many logging libraries for C++, so if your codebase uses a particular logging class look for usages of that logger for anywhere sensitive information can be written to the logs.		There are many logging libraries for C++, so if your codebase uses a particular logging class look for usages of that logger for anywhere sensitive information can be written to the logs.
−
−	~~If you are writing a module for Apache or thttpd then also be aware that anything written to standard out (using std::out or a printf to file descriptor 1) will be written as part of the response.~~

@@ Line 352: / Line 352: @@
      } catch (IOException e) {
          System.err.println("Input exception ");
-−
      } catch (Exception e) {
          System.err.println("Error occurred!”);

@@ Line 13: / Line 13: @@
 # It may affect the state of the application
-:The initial failure to prevent the error may cause the application to traverse into an insecure state.  This covers the key premise of '''failing securely''' ''<include reference to antipatterns>'', 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).
+## The initial failure to prevent the error may cause the application to traverse into an insecure state.  This covers the key premise of '''failing securely''' ''<include reference to antipatterns>'', 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).
 # It may leak system information to a user
-:An important aspect of secure application development is to prevent information leakage. Error messages give an attacker great insight into the inner workings of an application. Weak error handling also aids the attacker, as the errors returned may assist them in constructing correct attack vectors.
+## An important aspect of secure application development is to prevent information leakage. Error messages give an attacker great insight into the inner workings of an application. 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 such as blind SQL injection using booleanization ''<should include reference>'' or analysis of response time characteristics.
@@ Line 35: / Line 34: @@
 Regardless of whether the development language provide checked exceptions or not, reviewers should remember:
 # Not all errors are exceptions
-: Don't rely on exception handling to be your only way of handling errors, handle all case statement 'default' sections, ensure all 'if' statements have their 'else' clauses covered, ensure that all exits from a function (e.g. return statements, exceptions, etc) are covered.  RAII concepts (e.g. auto pointers and the like) are an advantage here.  In languages like Java and C#, remember that errors are different from exceptions (different hierarchy) and should be handled.
+## Don't rely on exception handling to be your only way of handling errors, handle all case statement 'default' sections, ensure all 'if' statements have their 'else' clauses covered, ensure that all exits from a function (e.g. return statements, exceptions, etc) are covered.  RAII concepts (e.g. auto pointers and the like) are an advantage here.  In languages like Java and C#, remember that errors are different from exceptions (different hierarchy) and should be handled.
 # Catching an exception is not automatically handling it
-: You've caught your exception, so how do you handle it?  For many cases this should be obvious enough, based on your business logic, but for some (e.g. out of memory, array index out of bounds, etc) the handling many not be so simple.
+## You've caught your exception, so how do you handle it?  For many cases this should be obvious enough, based on your business logic, but for some (e.g. out of memory, array index out of bounds, etc) the handling many not be so simple.
 # Don't catch more that you can handle
-: Catch all clauses (e.g. 'catch(Exception e)' in Java & C# or 'catch(...) in C++) should be avoided as you will not know what type of expcetion you are handling, and if you don't know the exception type, how do you accurately handle it? It could be that the downstream server is not responding, or a user may have exceeded their quota, or you may be out of memory, these issues should be handled in different ways and thus should be caught in exception clauses that are specific.
+## Catch all clauses (e.g. 'catch(Exception e)' in Java & C# or 'catch(...) in C++) should be avoided as you will not know what type of expcetion you are handling, and if you don't know the exception type, how do you accurately handle it? It could be that the downstream server is not responding, or a user may have exceeded their quota, or you may be out of memory, these issues should be handled in different ways and thus should be caught in exception clauses that are specific.
@@ Line 227: / Line 226: @@
 In Apache you have two choices in how to return error messages to the client:
-) You can write the error status code into the req object and write the response to appear the way you want, then have you handler return 'DONE' (which means the Apache framework will not allow any further handlers/filters to process the request and will send the response to the client.
+# You can write the error status code into the req object and write the response to appear the way you want, then have you handler return 'DONE' (which means the Apache framework will not allow any further handlers/filters to process the request and will send the response to the client.
-) Your handler or filter code can return pre-defined values which will tell the Apache framework the result of your codes processsing (essentially the HTTP status code).  You can then configure what error pages should be returned for each error code.
+# Your handler or filter code can return pre-defined values which will tell the Apache framework the result of your codes processsing (essentially the HTTP status code).  You can then configure what error pages should be returned for each error code.
 In the interest of centralizing all error code handling, option 2 can make more sense.  To return a specific pre-defined value from your handler, refer to the Apache documentation for the list of values to use, and then return from the handler function as shown in the following example:
@@ Line 238: / Line 237: @@
         return HTTP_INTERNAL_SERVER_ERROR;
+      }
-−
       ... continue processing request ...
+  }
@@ Line 304: / Line 303: @@
     try {
        // Perform work here
-−
     } catch ( const MyClassExtendedFromStdException& e) {
        // Log the exception and continue
@@ Line 323: / Line 322: @@
    explicit non_even_argument (const string& what_arg);
   };
-−
   void do_fn()
+  {

@@ Line 274: / Line 274: @@
               Console.WriteLine("Reading line {0}", sr.ReadLine());
+          }
-          catch(Exception e) {
+          catch(MyClassExtendedFromException e) {
               Console.WriteLine("An error occurred. Please leave to room”);
   	     logerror(“Error: “, e);
@@ Line 305: / Line 305: @@
        // Perform work here
-    } catch (
+    } catch ( const MyClassExtendedFromStdException& e) {
 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.
-''<discuss the finally block, or the order in which these exceptions are listed?>''
+===The Order Of Catching Exceptions===
@@ Line 338: / Line 392: @@
 ===Releasing resources and good housekeeping===
 ====RAII====

@@ Line 225: / Line 225: @@
 ==Vulnerable Patterns for Error Handling in Apache==
-''<TODO>''
+In Apache you have two choices in how to return error messages to the client:
@@ Line 235: / Line 263: @@
 Code that might throw exceptions should be in a try block and code that handles exceptions in a catch block. The catch block is a series of statements beginning with the keyword catch, followed by an exception type and an action to be taken.
 '''Example:'''
@@ Line 277: / Line 301: @@
 '''C++ Try–Catch'''
-''<TODO>''
+ void perform_fn() {

@@ Line 89: / Line 89: @@
 * The result of business logic conditions not being met.
-* The result of the environment wherein the business logic resides fails ''<might need to explain exactly what this means, or give an example>''.
+* 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.
@@ Line 169: / Line 169: @@
   <script language="C#" runat="server">
   Sub Page_Error(Source As Object, E As EventArgs)
-  Dim message As String = <Font Color="red">Request.Url.ToString()& Server.GetLastError().ToString()</font>
+  Dim message As String = Request.Url.ToString()& Server.GetLastError().ToString()
   Response.Write(message) // display message
   End Sub
@@ Line 179: / Line 179: @@
 After the Page_Error is called, the Application_Error sub is called.
 ===Global.asax===
-When an error occurs, the Application_Error function is called. In this method we can log the error and redirect to another page.
+When an error occurs, the Application_Error function is called. In this method we can log the error and redirect to another page. In fact catching errors in Application_Error instead of Page_Error would be an example of centralizing errors as described earlier,
   <%@ Import Namespace="System.Diagnostics" %>
@@ Line 205: / Line 200: @@
 Above is an example of code in Global.asax and the Application_Error method. The error is logged and then the user is redirected. Non-validated parameters are being logged here in the form of Request.Path. Care must be taken not to log or display non-validated input from any external source. ''<link to XSS>''
 ===Web.config===
@@ Line 214: / Line 210: @@
   </customErrors>
-The “On" directive means that custom errors are enabled whilst the "Off" directive means that custom errors are disabled. This allows the displaying of detailed errors. "RemoteOnly" specifies that custom errors are shown only to remote clients, and ASP.NET errors are shown to the local host. "RemoteOnly" is the default value for the defaultRedirect attribute. An example of the customErrors section completed for an application is as follows:
+The "mode" attribute value of "On" means that custom errors are enabled whilst the "Off" value means that custom errors are disabled.  The "mode" attribute can also be set to "RemoteOnly" which specifies that custom errors are shown only to remote clients and ASP.NET errors are shown to requests coming from the the local host.  If the "mode" attribute is not set then it defaults to "RemoteOnly".
   <customErrors mode="On" defaultRedirect="error.html">
@@ Line 221: / Line 221: @@
       <error statusCode="403" redirect="notAuthz.aspx"/>
   </customErrors>

@@ Line 31: / Line 31: @@
 # Good error handling does not give an attacker any information which is a means to an end, attacking the application
 # A proper centralised error strategy is easier to maintain and reduces the chance of any uncaught errors “bubbling up” to the front end of an application.
-# Information leakage could lead to social engineering exploits ''<we should explain how this is done - i'm unsure how this is accomplished>''.
+# Information leakage could lead to social engineering exploits, for example if the hosting companies name is returned, or some employees name can be seen.
 Regardless of whether the development language provide checked exceptions or not, reviewers should remember:
@@ Line 54: / Line 54: @@
 For JSP structs this could be controlled in the struts-config.xml file, a key file when reviewing the wired-up struts environment:
-  <exception   key=”bank.error.nowonga”
+  <exception key=”bank.error.nowonga”
                      path=”/NoWonga.jsp”
                      type=”mybank.account.NoCashException”/>
@@ Line 102: / Line 102: @@
 ==How to Locate the Potentially Vulnerable Code==
-===JAVA===
+===Java===
 In Java we have the concept of an error object; the Exception object. This lives in the Java package java.lang and is derived from the Throwable object. Exceptions are thrown when an abnormal occurrence has occurred. Another object derived from Throwable is the Error object, which is thrown when something more serious occurs. The Error object can be caught in a catch clause, but cannot be handled, the best you can do is log some information about the Error and then re-throw it.
@@ Line 154: / Line 154: @@
 ===C++===
-''<TODO>''
+In the C++ language, any object or built in type can be thrown.  However there is a STL type std::exception which is supposed to be used as the parent of any user defined exception, indeed this type is used in the STL and many libraries as the parent type of all exceptions.  Having std::exception encourages developers to create a hierarchy of exceptions which match the exception usage and means all exceptions can be caught by catching a std::exception object (instead of a 'catch (...)' block).  Unlike Java, even errors that you can't recover from (e.g. std::bad_alloc which means your out of memory) derive from std::exception, so a 'catch( std::exception& e)' is similar to 'catch (...)' except that it allows you access to the exception so you can know what occurred and possibly print some error information using e.what().
@@ Line 305: / Line 309: @@
   set ErrObj = Server.GetLastError()
   'Now use ErrObj as the regular err object
@@ Line 354: / Line 345: @@
 ===Classic ASP===
 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)===
 Building an infrastructure for consistent error reporting proves more difficult than error handling. Struts provides the ActionMessages and ActionErrors classes for maintaining a stack of error messages to be reported, which can be used with JSP tags like <html: error> to display these error messages to the user.
@@ Line 383: / Line 376: @@
 ===Classic ASP===
 For classic ASP pages you need to do some IIS configuration, follow http://support.microsoft.com/kb/299981 for more information.

@@ Line 321: / Line 321: @@
 ===Releasing resources and good housekeeping===
 If the language in question has a finally method, use it. The finally method is guaranteed to always be called. The finally method can be used to release resources referenced by the method that threw the exception. This is very important. An example would be if a method gained a database connection from a pool of connections, and an exception occurred without finally, the connection object shall not be returned to the pool for some time (until the timeout). This can lead to pool exhaustion. finally() is called even if no exception is thrown.
@@ Line 343: / Line 345: @@
 A Java example showing finally() being used to release system resources.
 ===Classic ASP===
@@ Line 374: / Line 383: @@
 ===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
+For classic ASP pages you need to do some IIS configuration, follow http://support.microsoft.com/kb/299981 for more information.
 {{LinkBar