Exception Handling - Revision history

Bill Sempf: Promoted.

2014-10-29T15:58:24Z

Promoted.

Bricex: /* Where to Catch Exceptions */

2014-10-03T16:53:36Z

‎Where to Catch Exceptions

Bricex: /* Web API Global Error Handling (Added in Web API 2.1) */

2014-10-03T16:44:48Z

‎Web API Global Error Handling (Added in Web API 2.1)

Bricex: /* ASP.NET Web API */

2014-10-03T16:44:14Z

‎ASP.NET Web API

Bricex: Including "Where to Catch Exceptions" section

2014-10-03T16:24:00Z

Including "Where to Catch Exceptions" section

Bricex: /* Displaying Errors */

2014-10-03T15:41:57Z

‎Displaying Errors

Bricex: /* References */

2014-10-03T15:39:30Z

‎References

Bricex: /* Logging Exception Details */

2014-10-03T15:36:28Z

‎Logging Exception Details

Bricex: Include warning on use of Server.ClearError

2014-10-03T14:34:00Z

Include warning on use of Server.ClearError

Bricex: /* Application Level */

2014-10-02T13:59:48Z

‎Application Level

@@ Line 1: / Line 1: @@
-= DRAFT DOCUMENT - WORK IN PROGRESS =
+=Description=
 An exception is any error condition or unexpected behavior that is encountered by your application. There are several key security concerns to be aware of when handling exceptions in .NET web applications:
 *Preventing system information leakage that could aid a malicious user.
@@ Line 8: / Line 6: @@
 *Log when exceptions are thrown and include sufficient detail for security auditing.
-==Displaying Errors==
+=Displaying Errors=
 When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application fails while attempting to connect to a database, it should not display an error message that includes the connection string being used.
@@ Line 18: / Line 16: @@
 </customErrors></pre>
-===HTTP Status Codes===
+==HTTP Status Codes==
 When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.
-==Where to Catch Exceptions==
+=Where to Catch Exceptions=
 There are a variety of places within a typical web application where exceptions can be caught and logged. First and foremost you want to catch exceptions at an application level and ensure they are handled properly. Often this may be the only location necessary to catch exceptions. In addition to this, handling exceptions at lower levels in the application will give you more control and may provide you with more detailed contextual information.
@@ Line 39: / Line 37: @@
 }</pre>
-==Logging Exception Details==
+=Logging Exception Details=
 Logging exception details is important when you need to properly diagnose error conditions with the system. You don't want this detail to be displayed on an error page because it may inadvertently aid a malicious user in an attack. Logging allows your error pages to display a simple generic message alerting end users that an error has occurred, with possibly some options for contacting support. The detail you need for assisting with these issues will be kept securely in the log store.
@@ Line 58: / Line 56: @@
 For detailed security guidance specific to logging see [[Reviewing Code for Logging Issues]].
-===Application Level===
+==Application Level==
 The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.
@@ Line 71: / Line 69: @@
 }</pre>
-===Server.ClearError===
+==Server.ClearError==
 Use the ''Server.ClearError()'' method with caution when handling exceptions. This method will clear the exception state and allow execution to continue rather than displaying an error message to the end user. There are valid scenarios where this is needed, but in general you should avoid this as it could allow a malicious user to bypass security controls if they are somehow able to force an error condition.
-===ASP.NET Web Forms===
+==ASP.NET Web Forms==
 ASP.NET web form pages provide the ability to capture exceptions at the page level in a similar fashion to the application level. This may be useful if you need to perform failure handling logic or log additional detail unique to the page.
@@ Line 87: / Line 85: @@
 }</pre>
-===ASP.NET MVC===
+==ASP.NET MVC==
 The MVC Controller class provides an ''OnException'' method similar to the ''Page_Error'' method in ASP.NET Web Forms. It allows you to process all unhandled exceptions thrown by actions of the controller. One option for implementing exception logging is to create a base controller class and defining the ''OnException'' method in this one central location.
@@ Line 117: / Line 115: @@
 <h2 class="text-danger">An error occurred while processing your request.</h2></pre>
-===ASP.NET Web API===
+==ASP.NET Web API==
 When handling exceptions for your API endpoints you generally want to return a JSON or XML response rather than redirect to an HTML page. ASP.NET Web API provides exception filters to customize how exceptions are handled. A good way of adding exception logging is to derive your own class from ''System.Web.Http.Filters.ExceptionFilterAttribute'' and override the ''OnException'' method as shown.
@@ Line 133: / Line 131: @@
 <pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>
-====HttpResponseException====
+===HttpResponseException===
 By default any exception thrown within Web API will return an HTTP response status code of 500 (Internal Server Error). For more control over the response you can use ''HttpResponseException'' as shown.
@@ Line 150: / Line 148: @@
 }</pre>
-====Web API Global Error Handling (Added in Web API 2.1)====
+===Web API Global Error Handling (Added in Web API 2.1)===
 There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.
@@ Line 162: / Line 160: @@
 <pre>System.Web.Http.GlobalConfiguration.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());</pre>
-==Logging Sensitive Data==
+=Logging Sensitive Data=
 Be careful when logging exception details that you do not inadvertently expose sensitive data to a logging system or external reports that may have relaxed access controls compared to the primary system. For example if a ''SqlException'' is thrown and the details contain a connection string, you may want to mask the password attribute before logging the event. Use care when logging exception details that may contain the following types of data:
@@ Line 171: / Line 169: @@
 *Credit card data
-==References==
+=References=
 *[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
 *[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
@@ Line 181: / Line 179: @@
 *[http://www.asp.net/web-api/overview/testing-and-debugging/web-api-global-error-handling Web API 2 .1 Global Error Handling]
-[[Category:OWASP .NET Project]][[Category:Stub]]
+[[Category:OWASP .NET Project]]

@@ Line 26: / Line 26: @@
 If you use try/catch blocks to handle exceptions be aware of two concerns:
-#Avoid using the ''Exception'' class but instead use a descendant class this the most applicable to the condition you are expecting. This may require you to write your own descendant class.
+#Avoid using the ''Exception'' class but instead use a descendant class that is the most applicable to the condition you are expecting.
-#Be careful not to catch an exception and continue processing. Always use the ''throw'' statement to re-throw the exception unless you are certain that this will not leave the application in an unexpected and potentially vulnerable state.
+#Be careful not to just catch an exception and continue processing. Always use the ''throw'' statement to re-throw the exception unless you are certain that this will not leave the application in an unexpected and potentially vulnerable state.
 <pre>try

@@ Line 150: / Line 150: @@
 }</pre>
-===Web API Global Error Handling (Added in Web API 2.1)===
+====Web API Global Error Handling (Added in Web API 2.1)====
 There are a number of cases in Web API where an exception can occur that falls outside of what exception filters can handle. These include exceptions in controller construction, message handlers, routing, and response content serialization. To handle these exceptions you will need to register a class that implements the ''IExceptionLogger'' interface, or derives from the ''ExceptionLogger'' base class.

← Older revision		Revision as of 16:44, 3 October 2014
Line 132:		Line 132:

	<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>		<pre>System.Web.Http.GlobalConfiguration.Configuration.Filters.Add(new LogExceptionFilterAttribute());</pre>
		+
		+	====HttpResponseException====
		+	By default any exception thrown within Web API will return an HTTP response status code of 500 (Internal Server Error). For more control over the response you can use ''HttpResponseException'' as shown.
		+
		+	<pre>public Product GetProduct(int id)
		+	{
		+	Product item = repository.Get(id);
		+	if (item == null)
		+	{
		+	throw new HttpResponseException(HttpStatusCode.NotFound)
		+	{
		+	Content = new StringContent(string.Format("No product with ID = {0}", id)),
		+	ReasonPhrase = "Product ID Not Found"
		+	};
		+	}
		+	return item;
		+	}</pre>

	===Web API Global Error Handling (Added in Web API 2.1)===		===Web API Global Error Handling (Added in Web API 2.1)===

@@ Line 20: / Line 20: @@
 ===HTTP Status Codes===
 When reviewing error responses be careful that a malicious user is not able to glean any potentially sensitive information about the system from the status code returned. For example: an API search that takes a tenant ID parameter and returns an HTTP 404 response for no results, and an HTTP 500 response if the tenant ID does not exist. An attacker could potentially leverage this information to determine if a tenant ID is valid or not. One solution would be to catch the exception thrown when a supplied tenant ID does not exist, and return an HTTP 404 status code with the error response.
 ==Logging Exception Details==
-There are a variety of places within a typical web application where exceptions can be caught and logged. Ideally, you should handle exceptions in as many of the locations described in this section that are applicable to your application. You can use several methods to log exception events, including popular third party libraries: log4net, nlog, Common.Logging, etc. An out-of-the-box solution included with .NET is System.Diagnostics Tracing as shown in the code examples in this article. These trace messages can then be written out using ''trace listeners'' such as the TextWriterTraceListener configured here.
+Logging exception details is important when you need to properly diagnose error conditions with the system. You don't want this detail to be displayed on an error page because it may inadvertently aid a malicious user in an attack. Logging allows your error pages to display a simple generic message alerting end users that an error has occurred, with possibly some options for contacting support. The detail you need for assisting with these issues will be kept securely in the log store.
 <pre><system.diagnostics>

@@ Line 9: / Line 9: @@
 ==Displaying Errors==
-When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application unsuccessfully tries to log in to a database, it should not display an error message that includes the connection string being used.
+When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application fails while attempting to connect to a database, it should not display an error message that includes the connection string being used.
 The default display mechanism for unhandled exceptions in ASP.NET is controlled via the ''<customErrors>'' element in the web.config file. This element includes a ''mode'' attribute that can be set to: ''Off'', ''On'', or ''RemoteOnly''. This mode setting should never be set to ''Off'' in a production environment because it will cause exception details to be displayed to the end user which may include sensitive information about the system.

@@ Line 137: / Line 137: @@
 *[http://www.asp.net/web-forms/tutorials/deployment/deploying-web-site-projects/displaying-a-custom-error-page-cs Displaying a Custom Error Page]
 *[http://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx customErrors Element (ASP.NET Settings Schema)]
 *[http://msdn.microsoft.com/en-us/library/ed577840(v=vs.100).aspx How to: Handle Page-Level Errors]
 *[http://msdn.microsoft.com/en-us/library/system.web.mvc.controller.onexception(v=vs.118).aspx Controller.OnException Method]

@@ Line 25: / Line 25: @@
 ===Application Level===
-The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. In this example ''Server.ClearError()'' is not called so that the exception will continue to be processed by the error display mechanism defined by the ''<customErrors>'' element in web.config. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.
+The following code example shows how to create an error handler in the Global.asax.cs file that will catch and log all unhandled ASP.NET errors at the application level. Unhandled exceptions must be logged within ''Application_Error'' rather than in a subsequent page defined by ''<customErrors>'', because the exception details are only available at this point.
 <pre>void Application_Error(object sender, EventArgs e)
@@ Line 36: / Line 36: @@
    System.Diagnostics.Trace.TraceError(exception.ToString());
 }</pre>
 ===ASP.NET Web Forms===
@@ Line 48: / Line 51: @@
    // address and current authenticated user if applicable.
    System.Diagnostics.Trace.TraceError(exception.ToString());
 }</pre>