Information Exposure Through Error Message

ID

csharp.information_exposure_through_error_message

Severity

low

Resource

Information Leak

Language

CSharp

Tags

CWE:209, NIST.SP.800-53, OWASP:2021:A4, PCI-DSS:6.5.5

Description

Generation of error messages containing sensitive information.

Rationale

Error messages are an integral part of application development, used to communicate issues in the code to the developers. However, in a production environment, overly detailed error messages can become a security liability. For example, stack traces or database exception messages can disclose information about file paths, internal IP addresses, stack traces, database structure, or library versions, all of which can be exploited if in the hands of a malicious user.

For an example, consider the following C# action method that creates a new user in a database, generating a too-detailed error message in case of an SQL exception:

[HttpPost]
public async Task<IActionResult> CreateUser([FromBody] CreateUserRequest request)
{
    try
    {
        using var connection = new SqlConnection(connectionString);
        await connection.OpenAsync();
        // .... rest of sql processing code
        return Ok("User created successfully");
    }
    catch (SqlException ex)
    {
        return BadRequest(new
        {
            Error = "Failed to create user",
            Details = ex.ToString(),  // FLAW - This may leak sensitive connection info!
            Timestamp = DateTime.UtcNow
        });
    }
}

In the example above, SqlException.ToString() can reveal information about the application’s connection string or database structure, potentially aiding an attacker. Consider replacing this with logging mechanisms that don’t expose implementation details to users.

Remediation

To remediate instances of information exposure through error messages, the primary action is to limit the detail provided in exceptions sent to the end-user. Consider the following steps:

  1. Generic Error Messages: Ensure that user-facing error messages do not reveal detailed system information. Use generic language and avoid technical specifics.

  2. Centralized Error Handling: Employ a global exception handling strategy using a framework that standardizes error responses across your applications.

  3. Logging: Utilize logging frameworks to log detailed error information securely, ensuring logs do not expose sensitive data.

  4. Security Review: Review all instances where exceptions are caught and handled, ensuring they follow the guidelines above, particularly in areas of code that are publicly accessible.

Following these steps reduces the risk of sensitive data exposure through error messages, thereby strengthening the security posture of the application.

The most idiomatic way to handle errors in ASP.NET Core is to use a custom middleware that captures and handles exceptions (registered with app.UseExceptionHandler()), ensuring that sensitive information is not exposed to the end-user. Full stack traces and technical details can be sent to the end-user only in development environments, but they can be logged using a logging framework for troubleshooting.

Another option is to use the Microsoft.AspNetCore.Mvc.ProblemDetails(RFC-7807) for exposing error details in REST APIs.

Configuration

The detector has the following configurable parameters:

  • allow_explicitly_thrown_errors to allow .

References