Format String in Aspnet

Format string vulnerabilities in ASP.NET applications arise when user-controlled input is passed directly to string formatting methods like String.Format, Console.WriteLine, or logging frameworks without proper validation. Unlike C/C++ where format strings can lead to memory corruption, in .NET the primary risks are information disclosure, denial of service, and unexpected behavior due to exception throwing or excessive resource consumption.

In ASP.NET Core, a common vulnerable pattern occurs in custom middleware or error handlers where exception details or user input are logged using formatting methods. For example:

public async Task InvokeAsync(HttpContext context)
{
    try
    {
        await _next(context);
    }
    catch (Exception ex)
    {
        // VULNERABLE: user-controlled 'context.Request.Path' used in format string
        _logger.LogError("Error processing request {Path}: {Message}", context.Request.Path, ex.Message);
    }
}

While this example is safe because the format string is static, vulnerability appears when the format string itself is sourced from user input:

[ApiController]
[Route("api/[controller]")]
public class LogController : ControllerBase
{
    private readonly ILogger _logger;
    public LogController(ILogger logger) => _logger = logger;

    [HttpGet("debug")]
    public IActionResult Get([FromQuery] string format)
    {
        // VULNERABLE: user input directly used as format string
        return Ok(string.Format(format, "safe", "values"));
    }
}

An attacker could supply a format string like {0:{}} to cause a FormatException, leading to application crashes or information leakage through detailed error pages if customErrors is off. In logging scenarios, malicious format strings can cause excessive CPU usage (e.g., {0:{((((((((((0}}}) leading to denial of service. ASP.NET's built-in model binding and validation do not automatically protect against format string injection in developer-written code that manually uses formatting APIs.

Detecting format string vulnerabilities in ASP.NET requires identifying points where user input flows into formatting methods without sanitization. middleBrick performs black-box scanning by sending crafted payloads to API endpoints and analyzing responses for anomalies indicative of format string exploitation, such as exceptions, unexpected output, or performance degradation.

During a scan, middleBrick tests for format string injection by submitting payloads designed to trigger System.FormatException or cause abnormal behavior. For example, it may send:

• {0:{}} – attempts to trigger a format exception via invalid format specifier
• {0:{{{{{{{{{{{{0}}}} – tests for excessive resource consumption in format parsing
• {1} when only one argument is provided – attempts to access out-of-bounds format items

If the application returns a 500 error with a stack trace containing System.FormatException or System.IndexOutOfRangeException in response to these payloads, middleBrick flags a potential format string vulnerability. The scanner also monitors response times; a significant increase when sending complex format strings may indicate a denial-of-service vector.

middleBrick’s OpenAPI/Swagger analysis enhances detection by identifying endpoints that accept string parameters likely to be used in formatting contexts (e.g., parameters named format, template, message) and prioritizing them for active testing. The tool correlates runtime findings with spec definitions to confirm whether user-controlled input reaches formatting sinks.

Findings are reported with severity based on impact: crashes or information disclosure are rated High, while potential DoS via CPU exhaustion may be Medium depending on exploitability and presence of error handling that masks exceptions.

Remediating format string vulnerabilities in ASP.NET involves ensuring that user input is never used as a format string. The .NET framework provides safe alternatives and patterns to prevent injection.

The primary fix is to avoid passing user input to the format parameter of String.Format, Console.WriteLine, or logger methods. Instead, treat user input as a value to be formatted, not as the format specification itself. For example, the vulnerable controller from earlier should be rewritten as:

[ApiController]
[Route("api/[controller]")]
public class LogController : ControllerBase
{
    private readonly ILogger _logger;
    public LogController(ILogger logger) => _logger = logger;

    [HttpGet("safe")]
    public IActionResult Get([FromQuery] string userInput)
    {
        // SAFE: static format string, user input as value
        return Ok(string.Format("Received: {0}", userInput));
        // Or better, use interpolated string (still safe if format is static)
        // return Ok($"Received: {userInput}");
    }
}

When using logging frameworks like Microsoft.Extensions.Logging, always use parameterized logging:

// SAFE: parameters passed separately
_logger.LogError("Error processing request {Path}: {Message}", context.Request.Path, ex.Message);

// DANGEROUS: NEVER do this if any part comes from user input
// _logger.LogError($"Error processing request {context.Request.Path}: {ex.Message}");
// Only safe if you control and validate the entire string

If dynamic format strings are truly necessary (rare in web APIs), implement strict validation:

private static readonly Regex SafeFormatRegex = new Regex(@"^\\{[0-9]+\}(?:\\{[0-9]+\})*$", RegexOptions.Compiled);

public string SafeFormat(string format, params object[] args)
{
    if (!SafeFormatRegex.IsMatch(format))
    {
        throw new ArgumentException("Format string contains unsafe constructs");
    }
    return string.Format(format, args);
}

This regex ensures the format string contains only numbered placeholders like {0}, {1}, etc., preventing malicious specifiers. However, avoiding dynamic format strings altogether is the preferred and simplest approach in ASP.NET applications.