HTTP Splitting

csharp.http_splitting

Severity

critical

Resource

Injection

Language

CSharp

Description

Improper Neutralization of CR/LF Sequences in HTTP Headers ('HTTP Request/Response Splitting').

HTTP response splitting occurs when user input is unsafely incorporated into HTTP response headers. Attackers exploit these vulnerabilities by injecting CR/LF (Carriage Return plus Line Feed) characters, effectively splitting the HTTP response into two separate responses.

This vulnerability is often referred to as HTTP Header Manipulation.

Rationale

Here is a simplified example of the vulnerability:

using Microsoft.AspNetCore.Mvc;
using System;

public class DownloadController : Controller
{
    [HttpGet]
    public IActionResult Download(string filename)
    {
        // VULNERABLE: User-controlled input directly in header
        Response.Headers.Add("Content-Disposition", $"attachment; filename={filename}");
        return File(load(filename), "application/octet-stream", "application/octet-stream");
    }

    // Assume this safely loads the contents for the requested file,
    // without path traversal vulnerabilities ;)
    private byte[] load(string filename) { /* ... */ }
}

In the example above, if the user parameter is not properly sanitized, an attacker can inject an input like "John%0D%0ASet-Cookie:%20SESSIONID=malicious" allowing them to split the HTTP response and perform malicious actions.

HTTP response splitting can lead to serious security concerns such as:

Cross-Site Scripting (XSS): Leveraging the split response to inject script content into another user’s browser.
Web Cache Poisoning: Exploiting vulnerable proxy servers or caching mechanisms to cache a poisoned response.
Session Fixation: Forcing a user into a session where the session ID is specified by the attacker.

Mitigating this requires diligent input validation and proper handling of HTTP headers to ensure that malicious headers cannot be injected.

Remediation

The best practice is to sanitize all user input to prevent HTTP response splitting:

using Microsoft.AspNetCore.Mvc;
using System;

public class DownloadController : Controller
{
    [HttpGet]
    public IActionResult Download(string filename)
    {
        // FIXED: Sanitize input
        string safeFilename = SanitizeFilename(filename);

        Response.Headers.Add("Content-Disposition", $"attachment; filename={filename}");
        return File(load(filename), "application/octet-stream", "application/octet-stream");
    }

    private byte[] load(string filename) { /* ... */ }

    // Sanitize input. Better use a whitelist of allowed files to download
    private string SanitizeFilename(string filename)
    {
        // Remove all CR/LF and potentially other unsafe characters
        // Optionally, you can also restrict to specific allowed characters
        string safe = Regex.Replace(filename, @"[\r\n]", "");
        // Replace quotes if you want (optional, but sometimes recommended)
        safe = safe.Replace("\"", "'");
        return safe;
    }
}

For encoding URLs that depend on untrusted input, you can use System.Web.HttpUtility.UrlEncode method (for .NET Framework) or System.Net.WebUtility.UrlEncode (for .NET Core and .NET 5+ applications). These methods URL-encodes the string to be included in the HTTP header, preventing HTTP response splitting. The CR/LR characters are replaced with %0D%0A so they will not split the HTTP response.

If it is not possible to use untrusted input in HTTP headers, consider the following strategies to avoid HTTP response splitting:

Input Validation: Ensure all user inputs are validated and sanitized before inclusion in HTTP response headers. Either filter out or encode CR/LF characters, or better use a strict whitelist validation to enforce the expected data format for the header.
Output Encoding: Properly encode or replace any special characters in user input embedded within HTTP headers.
Library and Framework Use: Utilize security libraries for validation. Some frameworks include built-in protection against CR/LF injection in HTTP headers.
Security Testing: Implement automatic security testing mechanisms such as Static Application Security Testing (SAST) tools to detect HTTP response splitting vulnerabilities during the development phase.

By validating input, encoding output, and leveraging security libraries, the risk of HTTP response splitting can be significantly reduced in C# applications.

Configuration

The detector has the following configurable parameters:

sources, that indicates the source kinds to check.
neutralizations, that indicates the neutralization kinds to check.

Unless you need to change the default behavior, you typically do not need to configure this detector.

References

CWE-113 : Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting').
OWASP Top 10 2021 - A03 : Injection.
HTTP Response Splitting attack.