ASP.NET Misconfiguration: Missing Error Handling

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.

Explanation:

ASP .NET applications should be configured to use custom error pages instead of the framework default page. The default error

page gives detailed information about the error that occurred, and should not be used in production environments. The mode

attribute of the <customErrors> tag defines whether custom or default error pages are used.

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.

Recommendations:

Always enable custom error pages for production deployment. This can be accomplished by setting the mode attribute to On on

the <customErrors> tag in your application's configuration file and setting the property to point to your custom error page, such

as error.aspx in the example below.

<configuration>

<customErrors mode="On" defaultRedirect="error.aspx"/>

...

</configuration>

Custom error pages can also be configured at a more granular level in the <appSettings> section of the ASP .NET configuration

file. When you customize these settings and implement your custom error pages, be certain they do not leak any of the system

information that you are trying to protect by replacing the framework defaults. Error pages should never display specific

information about the application or any of the resources it uses. In particular, displaying stack traces and other execution

specifics should always be avoided.