CRLF injection occurs when unescaped carriage return and line feed characters enter an HTTP header. This breaks the header boundary, allowing an attacker to insert new headers. You stop it by encoding these characters or validating input against control characters.
The Protocol Boundary Failure
HTTP responses consist of a header section followed by a blank line and a body. The browser parses this structure strictly. The sequence of a carriage return and a line feed character marks the end of a header line. If an application accepts user input into a header value without sanitization, it creates a boundary failure. The attacker inserts the control characters to force the parser to treat subsequent data as a new header rather than part of the original value. This mechanism is distinct from cross-site scripting (XSS) because it manipulates the protocol structure rather than injecting executable scripts into the page content.
Stage 1: Input Collection
The attacker identifies a parameter that reflects user input into an HTTP response header. Common targets include redirect URLs, cookie values, or content-type headers. The application accepts the string and prepares to include it in the response. At this point, the data is treated as opaque text. The flaw relies on the assumption that all input is safe alphanumeric data. The attacker crafts a payload containing the specific byte sequence for carriage return and line feed. This payload looks like normal text to a casual observer but carries structural intent for the HTTP parser.
Stage 2: Payload Construction
The attacker constructs a string that includes the CRLF sequence followed by a malicious header. For example, the payload might include a carriage return, a line feed, and then the text "Set-Cookie: admin=true". This string is encoded to bypass simple web filters that look for visible text matches. The goal is to ensure the web server decodes the string back into raw bytes before processing the HTTP response. If the server decodes the input before parsing the headers, the injection succeeds.
| Stage | What happens | Where it can be stopped |
|---|---|---|
| 1. Input | Attacker sends malicious string in a request parameter | Input validation at the application layer |
| 2. Processing | Server decodes the string into raw bytes | Encoding checks before header assignment |
| 3. Parsing | HTTP parser splits headers using CRLF boundaries | Strict header validation libraries |
| 4. Response | Browser receives and processes injected headers | Browser security policies and CORS |
Stage 3: Server-Side Processing
The web server receives the request and processes the input. If the application uses a framework that automatically handles encoding, it may protect against the attack. However, many legacy systems or custom frameworks pass raw strings directly to the HTTP response object. The server interprets the carriage return and line feed bytes as structural delimiters. It splits the original header line and begins a new line with the attacker's data. This step is invisible to the application logic, which believes it is sending a single, safe header. The vulnerability exists because the application trusts the input to remain within the value field of the header.
Stage 4: Protocol Split
The HTTP response is assembled with the injected header. The structure now contains two headers where the application intended only one. The first header is the original, benign one. The second header is the attacker's injection. The blank line that separates headers from the body may also be manipulated to inject arbitrary body content. This allows for cache poisoning attacks where the server caches a malicious response for all users. It treats the injected header as a legitimate part of the response.
Stage 5: Client-Side Execution
The browser processes the injected header. If the header is Set-Cookie, the browser stores the cookie for the domain. This enables session fixation attacks where the attacker forces a victim to use a known session ID. If the header is Content-Type, the browser may render the page as HTML instead of JSON, enabling reflected XSS. The attacker does not need to execute code on the server. The damage occurs on the client side through the browser's trust of the server's headers. This stage highlights why input validation is critical for security operations teams managing web applications.
Stage 6: Impact and Persistence
The injected data persists in the browser's state. Cookies remain until they expire or are deleted. Cache poisoning affects other users who request the same resource. The attacker achieves their goal without directly compromising the server's operating system or database. This makes CRLF injection a powerful primitive for broader attacks. It can bypass web application firewalls that inspect body content but ignore header manipulation. Understanding this flow helps defenders recognize that header injection is not just a reflection issue but a structural protocol violation.
Defensive Interruption Points
You can interrupt this chain at multiple stages. The most effective point is at input collection. Implement strict input validation that rejects control characters. Do not allow characters with ASCII values below 32 in header values. This prevents the CRLF sequence from ever reaching the parser. Another point is during server-side processing. Use libraries that automatically sanitize header values. These libraries escape or reject dangerous characters before they are added to the response object. Finally, browser security features like Content Security Policy can mitigate some effects, but they do not prevent the injection itself.
Common Misconceptions
Many teams believe that output encoding stops CRLF injection. This is incorrect if the server decodes the input before sending it. You must validate the decoded input. Another misconception is that CRLF injection requires code execution. It does not. It relies on the browser's interpretation of headers. This makes it dangerous even in environments with strict server-side sandboxing. The attack vector is the protocol itself, not a software bug in the application logic.
Broader Security Context
CRLF injection often serves as an initial step in larger attack chains. It can be combined with other vulnerabilities to amplify impact. For instance, an attacker might use CRLF injection to bypass CORS restrictions, enabling data exfiltration. It can also be used to inject headers that confuse security tools. Understanding this mechanism is vital for defending against complex threats. While less common than input validation failures in general, CRLF injection remains a persistent risk in web applications that handle user input in headers. Regular testing for header injection is necessary to maintain a secure posture.
Key takeaways
- CRLF injection relies on the strict separation of HTTP headers and bodies defined by RFC standards.
- Attackers use this flaw to inject headers like Set-Cookie for session fixation or Content-Type for cache poisoning.
- Defense requires strict input validation that rejects or encodes control characters before they reach the protocol layer.
CRLF injection exploits the HTTP protocol's reliance on control characters to separate headers. Stop it by validating input and rejecting control characters before they reach the server.
Frequently asked questions
Does HTTPS prevent CRLF injection?
No, HTTPS encrypts the data in transit but does not validate the content. The server still processes the headers and can be tricked into sending malformed responses if the application logic is flawed.
Is CRLF injection the same as HTTP response splitting?
Yes, HTTP response splitting is another name for CRLF injection. The term describes the result of the attack, where the response is split into multiple parts by the injected characters.
Can a WAF stop CRLF injection?
A Web Application Firewall can block known CRLF patterns, but it may miss encoded variants. Input validation in the application is more reliable because it checks the data before it reaches the network layer.
How this guide was produced: written by the Vuln Post editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
