ASP.NET 2.0 Security Guidelines - Exception Management

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan

Use Structured Exception Handling

Use structured exception handling and catch exception conditions. Doing this improves robustness and avoids leaving your application in an inconsistent state that may lead to information disclosure. It also helps protect your application from denial of service attacks. Use finally blocks to ensure that resources are cleaned up and closed even in the event of an exception condition. Decide how to propagate exceptions internally in your application and give special consideration to what occurs at the application boundary.

Do Not Reveal Exception Details to the Client

When exceptions occur, return concise error messages to the client and log specific details on the server. Do not reveal internal system or application details, such as stack traces, SQL statement fragments, and table or database names to the client. 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.

Prevent detailed error messages from displaying by setting the mode attribute of the <customErrors> element to On, so that all callers receive filtered exception information. Do not use mode="Off" because this allows detailed error pages intended for application developers that contain system-level information to be returned to the client.

You should also use the <customErrors> section of the Web.config file as shown in the following code example to specify a default error page to display, along with other required error pages for specific HTTP response codes that indicate errors.

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

The defaultRedirect attribute allows you to use a custom error page for your application, which. for example, might include support contact details. Use these application-wide error pages to provide user-friendly responses for errors that are not caught in a structured event handling.

Use a Global Error Handler to Catch Unhandled Exceptions

Define an application-level global error handler in Global.asax to catch any exceptions that are not handled in code. Do this to avoid accidentally returning detailed error information to the client. 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, 

   // Optional e-mail or other notification here...
Personal tools