ASP.NET 2.0 Security Practices - Exception Management

From Guidance Share

Jump to: navigation, search


How to handle exceptions securely

Do not reveal internal system or application details, such as stack traces, SQL statement fragments, and table or database names. Ensure that this type of information is not allowed to propagate to the end user or beyond your current trust boundary. A malicious user could use system-level diagnostic information to learn about your application and probe for weaknesses to exploit in future attacks.

If an exception is thrown, make sure your application fails securely, denies access, and is not left in an insecure state. Do not log sensitive or private data, such as passwords, that could be compromised. When you log or report exceptions, if user input is included in exception messages, validate it or sanitize it. For example, if you return an HTML error message, you should encode the output to avoid possible script injection.

How to prevent detailed errors from returning to the client

By default, in ASP.NET the mode attribute of the <customErrors> element is set to remoteOnly, which returns complete exception information (including the stack trace) only to callers on the same computer as the server. Remote callers receive filtered exception information. In a production environment, you should set the mode attribute to On, so that all callers receive filtered exception information. You should also specify a default redirect page as shown here.

<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />

The defaultRedirect attribute allows you to use a custom error page for your application, which, for example, might include support contact details. Do not use mode="Off" because this allows detailed error pages that contain system-level information to be returned to the client.

Also set pageOutput="false" on the <trace> element to disable trace output. To prevent trace being accidentally being re-enabled, consider locking this for all applications on a server by applying the following configuration in the machine-level Web.config file. Enclose the <trace> element in a <location> element and set allowOverride to false.

<location path="" allowOverride="false">
    <trace pageOutput="false" ... />

How to use structured exception handling

Use try/catch/finally structured exception handling blocks around code to avoid unhandled exceptions. Use finally blocks to execute code that runs whether an exception is trapped; this is useful for releasing resources such as closing files or disposing of objects.

How to create a global error handler for your application

Define a global error handler in Global.asax to catch any exceptions that are not handled in code. You should log all exceptions in the event log to record them for tracking and later analysis. Use code similar to the following.

<%@ Application Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>

<script language="C#" runat="server">
void Application_Error(object sender, EventArgs e)
   //get reference to the source of the exception chain
   Exception ex = Server.GetLastError().GetBaseException();

   //log the details of the exception and page state to the
   //Event Log
   EventLog.WriteEntry("My Web Application",
     "MESSAGE: " + ex.Message + 
     "\nSOURCE: " + ex.Source +
     "\nFORM: " + Request.Form.ToString() + 
     "\nQUERYSTRING: " + Request.QueryString.ToString() +
     "\nTARGETSITE: " + ex.TargetSite +
     "\nSTACKTRACE: " + ex.StackTrace, 

   //Optional email or other notification here...

Note that you need to give your ASP.NET account the necessary permissions to write to the event log. For more information, see How to write to the event log in the Auditing and Logging topic.

How to specify a default error page

Use the <customErrors> section of the Web.config file and set mode to On to specify a default error page to display, along with other required error pages for specific HTTP response codes that indicate errors. Use these custom error pages, as shown in the following example, to provide user friendly responses for errors not caught in a structured event handling block.

<customErrors mode="On" defaultRedirect="ErrDefault.aspx">
    <error statusCode="401" redirect="ErrUnauthorized.aspx" />
    <error statusCode="404" redirect="ErrPageNotFound.aspx" />
    <error statusCode="500" redirect="ErrServer.htm" />

When debugging your application, the mode attribute of the <customErrors> element must be set to RemoteOnly (the default) to view the custom errors on remote clients and ASP.NET errors on the localhost.

Personal tools