CWE-12: ASP.NET Misconfiguration: Missing Custom Error Page

What is ASP.NET Misconfiguration: Missing Custom Error Page?

• Overview: ASP.NET Misconfiguration: Missing Custom Error Page refers to the absence of custom error pages in an ASP.NET application, which allows attackers to gather information from default error responses.

• Exploitation Methods:

• Attackers can trigger errors intentionally to view stack traces and detailed error messages.
• Common attack patterns include input manipulation to cause exceptions and discovering system configurations.

• Security Impact:

• Direct consequences include exposure of sensitive information such as server paths, code snippets, or database structure.
• Potential cascading effects involve attackers using disclosed information for further exploitation like SQL injection or cross-site scripting.
• Business impact includes reputational damage, compliance violations, and increased risk of data breaches.

• Prevention Guidelines:

• Implement custom error pages by configuring in the Web.config file.
• Follow security best practices like handling exceptions gracefully and logging detailed errors internally.
• Use recommended tools and frameworks that enforce secure error handling and provide guidance on secure configurations.

Corgea can automatically detect and fix ASP.NET Misconfiguration: Missing Custom Error Page in your codebase. Try Corgea free today.

Technical Details

Likelihood of Exploit: Not specified

Affected Languages: ASP.NET

Affected Technologies: Not specified

The mode attribute of the tag defines whether custom or default error pages are used.

Vulnerable Code Example

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.web>
    <!-- Vulnerable configuration: Custom errors are not enabled. 
         This can expose stack traces and sensitive information to attackers. -->
    <customErrors mode="Off" />
  </system.web>
</configuration>

Explanation:

• Vulnerability: The configuration sets customErrors mode to "Off", which means detailed error messages, including stack traces, are displayed to all users. This can lead to information disclosure, allowing attackers to gain insights into the application's internal workings and potentially exploit other vulnerabilities.
• Impact: Exposing detailed error messages can reveal sensitive information such as file paths, server details, or even code snippets, making it easier for attackers to plan further attacks.

How to fix ASP.NET Misconfiguration: Missing Custom Error Page?

To prevent attackers from gaining sensitive information through default error messages, it is crucial to configure custom error pages in ASP.NET. The customErrors element in the web.config file should have the mode attribute set to "On" or "RemoteOnly".

• "On": Custom error pages are shown to both local and remote users. This is typically used in production environments.
• "RemoteOnly": Custom error pages are shown only to remote users, while local users will see detailed error information. This is useful during development.

Additionally, specify a default error page to handle any unhandled exceptions and provide user-friendly error messages. This helps in avoiding the leakage of stack traces and other internal details of the application.

Fixed Code Example

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.web>
    <!-- Fixed configuration: Custom errors are enabled to prevent information leakage to attackers -->
    <customErrors mode="On" defaultRedirect="~/ErrorPages/GeneralError.aspx">
      <!-- Optionally, you can specify specific error codes and their corresponding pages -->
      <error statusCode="404" redirect="~/ErrorPages/NotFound.aspx" />
      <error statusCode="500" redirect="~/ErrorPages/ServerError.aspx" />
    </customErrors>
  </system.web>
</configuration>

Explanation:

• Fix: The customErrors mode is set to "On", ensuring that custom error pages are displayed to all users. This prevents the exposure of detailed error information.
• Default Redirect: A default error page (GeneralError.aspx) is specified to handle any unhandled exceptions, providing a generic error message to users.
• Specific Error Handling: Specific error pages are configured for common HTTP status codes like 404 and 500, directing users to friendly error pages (NotFound.aspx, ServerError.aspx).

Additional Best Practices:

• Create Custom Error Pages: Design user-friendly custom error pages (e.g., GeneralError.aspx, NotFound.aspx, and ServerError.aspx) that do not reveal sensitive information.
• Logging: Implement error logging on the server-side to keep track of any exceptions and investigate potential issues without exposing details to users.
• Testing: Regularly test your error handling configuration to ensure that error pages are displayed correctly and sensitive information is not leaked.