CRLF Injection / HTTP Response Splitting

CRLF Injection happens when user input ends up inside an HTTP header (or a log, or a redirect) without sanitizing the line-ending characters \r\n (CRLF, %0d%0a). Since those two bytes separate headers from each other and from the body, injecting them lets us add our own headers and even split the response in two (HTTP Response Splitting).

The typical case is a value reflected into Location, Set-Cookie or a custom header:

GET /redir?url=/home%0d%0aSet-Cookie:%20session=attacker HTTP/1.1
Host: victim

If the server emits Location: /home with our value, the %0d%0a closes the header and adds a Set-Cookie we control (session fixation). Taken further, a double CRLF closes the headers and injects a whole body:

/redir?url=x%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0a%0d%0a<script>alert(1)</script>

From there you get an XSS reflected through the split response, an open redirect (open redirect), or fake lines injected into logs (log poisoning) to muddy analysis.

How to detect it. The signature is a request whose parameters contain %0d%0a (or raw \r\n) right before header names (Set-Cookie, Location, Content-Length), and a response with duplicate headers or a second HTTP/1.1 200 status block. In proxy logs, split request lines or unexpected headers on a response from a route that should only redirect.

Defence. Do not reflect user input into headers; if unavoidable, strip or encode \r and \n before building them. Modern frameworks reject CRLF in their header APIs, so the bug almost always lives in code that concatenates headers by hand. It is a cousin of Host header injection and often precedes a cache poisoning.