fortify scan: 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 may 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.

Example 1:  The following shows how to enable custom errors and redirect to our custom error page, "error.aspx".

<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.