CRLF Injection and HTTP Response Splitting
In 2020, a security researcher discovered that several major CDN providers improperly handled CRLF sequences in redirect parameters, allowing attackers to inject arbitrary response headers for any cached resource. Similar issues have surfaced in Django, Ruby on Rails, and Go's standard library — frameworks used by millions of applications worldwide. CRLF injection is not a theoretical curiosity: it is a practical, widely-exploited vulnerability with real consequences.
What Are CRLF Characters?
CR (Carriage Return, \r, ASCII 0x0D) and LF (Line Feed, \n, ASCII 0x0A) are control characters inherited from typewriter and teletype conventions. Together, written as \r\n or abbreviated CRLF, they are the standard line terminator in HTTP/1.1.
Every HTTP response header field ends with a CRLF sequence. A blank line — two consecutive CRLF sequences — separates the headers from the response body. This is not a convention; it is a protocol requirement defined in RFC 7230. Every HTTP client in every browser relies on these exact bytes to know where one header ends and the next begins.
Why Injecting CRLF Into Headers Is Dangerous
If a web application takes a user-supplied value — such as the destination URL in a redirect — and writes it directly into a response header without stripping CRLF characters, an attacker can:
- Terminate the current header early by inserting
\r\n(or its URL-encoded form,%0d%0a). - Inject an entirely new header immediately after. For example, a
Set-Cookie:header with an attacker-chosen session token. - Split the response by injecting a double CRLF followed by a fabricated response body, causing caches and some clients to process two separate responses from a single server reply.
This class of attack is known as HTTP response splitting, and its consequences include session fixation, cross-site scripting via injected content types, and cache poisoning that affects all users of a shared cache.
What You Will Do in This Lab
In the interactive panel on the right, you will observe how a redirect endpoint reflects the url parameter directly into the Location: header. You will then craft a payload that injects %0d%0a into the parameter value to terminate the Location: header and append a Set-Cookie: header you control. Finally, you will learn the correct mitigation techniques and test your understanding with two quiz questions.
By the end of this lab you will be able to identify CRLF injection vulnerabilities, construct a working exploit payload, and apply the correct server-side defences.