Abstract

An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in error responses.

Description

ASP.NET applications should be configured to use custom error pages instead of the framework default page. In the event of an application exception, use the <customErrors> element to configure custom, generic error messages that should be returned to the client. The default error page provides detailed information about the error that occurred, and should not be used in production environments. Attackers can leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application.

Make sure that the mode attribute is set to "RemoteOnly" in the web.config file as shown in the following example. <customErrors mode="RemoteOnly" />

The mode attribute of the <customErrors> tag in the Web.config file defines whether custom or default error pages are used. It should be configure to use a custom page as follows:

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

Examples

Two typical misconfigurations:

• <customErrors ... mode="Off" />

Custom error message mode is turned off. An ASP.NET error message with detailed stack trace and platform versions will be returned.

• <customErrors mode="RemoteOnly" />

Custom error message mode for remote user only. No defaultRedirect error page specified. The local user on the web server will see a detailed stack trace. For remote users, an ASP.NET error message with the server customError configuration setting and the platform version will be returned.

 

Related Threats

Information leakage is the major threat due to the improper error handling. Error messages provide quite useful information to the attacker that can be used to launch further attacks such as SQL Injection. Below is few examples of threats because of the improper error handling:

A. Error messages can be used by an attackers to extract specific information about the System and Application.
B. An unexpected errors can be used to crack the application off line thus creating a denial-of-service attack by an attacker.
C. Unexpected errors may provide an attacker with a buffer or stack overflow condition that sets the stage for an arbitrary code execution.

Countermeasures

• Follow a common and standard approach for exception handling.
• Do not display detailed error message to the end-user such as Path Information, Database related information, stack traces etc. In short, disable or limit error messages.
• Override the default error handler so that it should always return "200 OK" error message. This will reduce the ability of automated vulnerability scanning tools from concluding in case of any serious error message.
• Always provide customized error pages for any kind of error (i.e. Database of application error). Configure the Web Server for redirecting to the customized error page in the event of an error.