Crlf Injection in Aspnet with Bearer Tokens

Crlf Injection occurs when user-controlled data is inserted into HTTP headers without proper sanitization, allowing an attacker to inject carriage return (CR, \r) and line feed (\n) sequences. In ASP.NET applications that accept Bearer Tokens—typically passed via the Authorization header as Bearer <token>—developers may inadvertently trust the token value or mirror it into other response headers for logging or routing purposes. If the token or any related header value is reflected into a downstream header without validation, an attacker can terminate the current header and inject a new header or response body. This can lead to HTTP response splitting, cache poisoning, or header manipulation.

For example, if an ASP.NET middleware copies the Authorization header value into a custom header such as X-Forwarded-Token without sanitization, a token like abc\r\nSet-Cookie: session=attacker can break header structure. Because Bearer Tokens are often handled as opaque strings, developers may assume they are safe, but any reflection of untrusted input into headers is risky. In addition, if the token is logged or echoed in error messages that are later included in headers, CRLF injection can be used to manipulate logging or monitoring systems that parse headers line-by-line. The combination of ASP.NET’s flexible header handling and the common practice of passing Bearer Tokens in headers creates a scenario where untrusted data reaches sensitive control positions in the protocol flow.

Another relevant pattern is when APIs accept Bearer Tokens via query parameters or cookies and then forward them to backend services, reflecting values into headers such as Authorization or Proxy-Authorization. If the reflected value contains CRLF sequences, an attacker can inject additional headers like Location or Content-Type, potentially enabling cross-protocol attacks or response splitting. Because the Bearer Token format is standardized as Bearer <string>, parsers may focus on the token extraction logic and overlook the need to sanitize the entire header value when it is reused. This underscores the importance of validating and encoding any user-influenced data before it is placed into HTTP headers, regardless of whether it originates from an Authorization header, a query parameter, or a cookie.

To mitigate Crlf Injection in ASP.NET when working with Bearer Tokens, ensure that any user-influenced data—especially values extracted from headers, query strings, or cookies—is validated and sanitized before being used in header construction. Never directly reflect the Authorization header or any part of the Bearer Token into other headers. Instead, treat the token as an opaque value and avoid reusing it in downstream headers unless absolutely necessary. When headers must be set based on token metadata, extract only the required claims using a trusted parser and encode the output appropriately.

Below are code examples demonstrating secure handling of Bearer Tokens in ASP.NET Core. The first example shows unsafe reflection of the Authorization header, and the second shows a corrected approach.

// Unsafe example: reflecting Authorization header into a custom header (vulnerable)
var authHeader = Request.Headers["Authorization"].ToString();
Response.Headers.Add("X-Forwarded-Token", authHeader); // Risk: CRLF injection if token contains \r\n

In the unsafe example, if the Authorization header contains Bearer abc\r\nSet-Cookie: session=attacker, the injected CRLF can create an additional header, leading to response splitting or header manipulation.

// Safe example: extract and validate the token, avoid direct reflection
var authHeader = Request.Headers["Authorization"].ToString();
if (authHeader.StartsWith("Bearer ", StringComparison.OrdinalIgnoreCase)) {
    var token = authHeader.Substring("Bearer ".Length).Trim();
    // Validate token format (e.g., length, characters) before any use
    if (IsValidBearerToken(token)) {
        // Use token only for authentication, not for header reflection
        // If you must set a custom header, use a sanitized value
        Response.Headers.Add("X-Token-Present", "true");
    } else {
        Response.StatusCode = 400;
        return;
    }
} else {
    Response.StatusCode = 401;
    return;
}

The safe example ensures that the token is treated as an opaque string and not reflected into headers. If you need to propagate information, use predefined, trusted values rather than user input. Additionally, implement input validation for the token format and enforce strict parsing to avoid accepting malformed or malicious inputs. This approach aligns with secure coding practices for handling credentials and helps prevent CRLF Injection and related header injection attacks.