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.