What Is CRLF Injection?
CRLF Injection, short for Carriage Return Line Feed Injection, is an often-overlooked web vulnerability that arises when user‑supplied input is included in HTTP headers, log files, or other text‑based streams without proper sanitization.
By inserting the special characters CR (\r, ASCII 13) and LF (\n, ASCII 10`), an attacker can break or split lines in ways the developer never intended. In HTTP, where each header line must end with a CRLF sequence, such manipulation can lead to HTTP response splitting, malicious header injection, log poisoning, and even cross site scripting (XSS) or phishing attacks.
At its core, CRLF Injection happens whenever an application takes untrusted input and directly embeds it into a text-based protocol or file format that uses CRLF as line delimiters. Common targets include:
- HTTP response headers (e.g., Set-Cookie, Location)
- Web server logs (Common Log Format or custom formats)
- Email headers (SMTP messages such as Subject: or To:)
- File contents and exports where CRLF marks record boundaries
If an attacker can successfully inject \r\n into any of these contexts, they may be able to:
- Split headers, causing new, attacker controlled‑ headers to appear.
- Inject a fake response body, for example, HTML or JavaScript, by terminating headers prematurely.
- Forge log entries, hiding malicious activities or misleading administrators.
Why Is It Called “CRLF”?
- CR (Carriage Return) – ASCII code 13, moves the cursor back to the start of the line (\r)
- LF (Line Feed) – ASCII code 10, moves the cursor down to the next line (\n)
- CRLF Together – On Windows and in HTTP, each line ends with \r\n
- Windows text files use CRLF.
- Unix/Linux/macOS text files typically use only LF (\n).
- HTTP/1.x mandates CRLF as the separator between each header line and between headers and body.
When you see a header like:
Set-Cookie: sessionId=abc123\r\n
Content-Type: text/html\r\n
that \r\n is CRLF. Injecting extra CRLF in user data can break out of the intended header structure.
How CRLF Injection Works
- User Input Submission:
The attacker locates a parameter, such as a URL query, form field, or header value, and injects encoded (%0D%0A) or raw (\r\n) CRLF sequences. - Unsanitized Inclusion:
The application concatenates this input directly into an HTTP header, log entry, or text-based export without filtering out control characters. - Protocol Manipulation:
- Asingle CRLF (\r\n) appends a new header line.
- Adouble CRLF (\r\n\r\n) terminates the header section and initiates a new response body, allowing arbitrary content injection.
Because HTTP and many logging formats treat these characters as protocol delimiters, this simple insertion can fundamentally alter how clients, proxies, and servers parse and handle the data.
Types of CRLF Injection Attacks
1. HTTP Response Splitting
Mechanism: By including %0D%0A (URL‑encoded CRLF) in parameters, an attacker can prematurely terminate the server’s headers and start a new response block.
- Inject Malicious Headers: The attacker can add their own Set-Cookie to hijack sessions or Location to redirect users.
- Insert Script Content: A double CRLF (\r\n\r\n) signals the end of headers and start of body, so the attacker can inject malicious HTML or JavaScript, triggering XSS in victims’ browsers.
Example URL:
https://example.com/search?q=foo%0d%0aSet-Cookie:%20admin=true%0d%0a%0d%0a<script>alert(1)</script>
When the server echoes that parameter into a header, the browser processes the fake cookie and script.
2. Log Poisoning (Log Injection)
Mechanism: Web servers and applications write user inputs directly into log files. If CRLF reaches the logger, it can create fake log entries or split existing entries.
- Hide Malicious Activity: An attacker injects a false “200 OK” entry after their malicious request.
- Forge Entries: Insert error messages or admin level actions that never occurred, misleading audits.
Consequence: Security teams relying on log analysis may overlook real attacks or chase ghosts.
3. HTTP Header Injection
Mechanism: When building headers (e.g., in PHP with header(“X-User: $input”)), unsanitized CRLF lets attackers inject additional headers.
- Cookie Manipulation: Craft Set-Cookie: session=attacker to hijack sessions.
- Redirects & Phishing: Add Location: https://phish.example.com to redirect victims.
4. Email Header Injection
Mechanism: Like HTTP headers, email headers are line‑based. Unsanitized fields (e.g., “To:” or “Subject:”) allow attackers to add new headers or even alter message bodies.
- Spam & Phishing: Mass‑mail spam campaigns by forging “BCC” recipients, hide origin.
- Header Tampering: Change “From:” or “Reply-To:” to impersonate trusted senders.
Learn more about other injection attacks.
Real‑World Impact of CRLF Injection
- Cross Site Scripting (XSS): Inject arbitrary scripts that are executed in victims’ browsers.
- Cookie Injection: Set cookies for victims, hijacking their authenticated sessions.
- Web Cache Poisoning: Poison shared caches (e.g., CDNs, proxies) so many users get malicious content.
- Phishing Redirects: Seamlessly redirect users from a legitimate site to a phishing domain.
- Logging Evasion: Obscure or falsify logs, hampering incident response.
Even though CRLF injection may seem lower severity, compared to SQLi or RCE, its chaining potential with XSS, session hijacking, and cache poisoning makes it critically dangerous.
How to Prevent CRLF Injection Attacks: Five Best Practices
1. Input Validation and Sanitization
- Validate Early: As soon as input arrives, check it against strict rules.
- Whitelist Characters: Only allow alphanumeric, hyphens, underscores, reject control characters.
- Strip/Encode CRLF: Remove \r and \n, or replace them with safe encodings before use.
2. Secure Header Construction and Safe Libraries
- Use Framework APIs: Most web frameworks provide safe header builders (response.setHeader()), which internally validate values.
- Avoid String Concatenation: Don’t assemble headers by hand (e.g., “Location: ” + userInput).
- Employ Safe Libraries: Leverage libraries that auto escape control characters.
3. Least Privilege Principle
- Minimal Rights: Run web servers and logging processes under low privilege accounts.
- Service Isolation: Keep header building and logging in separate, constrained contexts.
4. OS‑Level and Web Server Protections
- Harden Configurations: Disable unusual header names or suspicious methods in Apache/Nginx.
- Reverse Proxy Filtering: Use a proxy or Web Application Firewall (WAF) at the edge to strip control characters before they hit your app.
- Mandatory Access Controls: Enforce SELinux/AppArmor policies to limit file writes and system calls.
5. Logging Hardening
- Sanitize Before Logging: Always escape or remove CRLF from any log‑bound data.
- Structured Logging: Adopt JSON or XML logs, where fields are explicitly delimited and safely encoded.
- Monitor for Anomalies: Alert on unexpected line breaks or duplicated timestamps in log streams.
How AppTrana WAAP Prevents CRLF Injection
AppTrana WAAP provides robust protection against CRLF injection attacks by employing multiple layers of defense. It begins by inspecting every incoming HTTP request in real time, looking for malicious carriage return (\r) and line feed (\n) characters that attackers attempt to inject to manipulate HTTP headers or logs. AppTrana normalizes inputs by decoding any encoded characters such as %0d and %0a, ensuring that attempts to bypass filters using encoding tricks are detected effectively.
AppTrana uses a continuously updated, signature-based detection system combined with behavioral analysis to identify suspicious patterns associated with CRLF injection. When it detects inputs containing unexpected or unauthorized CRLF sequences, it either sanitizes the input by removing these control characters or blocks the request entirely, preventing header injection, HTTP response splitting, and log poisoning attacks.
Moreover, AppTrana enforces strict policies that disallow the inclusion of control characters in headers, cookies, and URL parameters. Its intelligent anomaly detection capabilities flag unusual request patterns and alert security teams, enabling rapid incident response.
