CRLF Injection Lab: Inject a Header Into the Response

This article explains CRLF injection (HTTP response splitting), a vulnerability where untrusted input containing carriage-return and line-feed characters is placed into HTTP response headers without filtering. The RedirectorApp lab demonstrates how an attacker can inject new headers—such as malicious Set-Cookie headers—by terminating the intended header early with encoded CRLF bytes. Understanding this vulnerability matters because it can compromise session security, poison caches, and in older systems allow response splitting to serve attacker-controlled content.

• HTTP headers are delimited by CRLFHTTP response structure is defined by carriage-return and line-feed (CRLF) characters that separate one header from the next. When an application concatenates user input directly into a header without removing CR and LF characters, those bytes are interpreted as header delimiters by the parser, allowing the attacker's text to become structural elements rather than data values.
• RedirectorApp concatenates without filteringRedirectorApp takes a URL from the query string and places it directly into the Location response header via string concatenation without stripping CR or LF. This means a newline in the input terminates the Location header early and begins a new header line controlled by the attacker, such as a Set-Cookie header of their choosing.
• Exploitation requires encoding newline charactersTo inject CRLF into a URL parameter, an attacker must encode the carriage-return and line-feed characters so they survive transport and are then interpreted as delimiters by the response parser. Once decoded by the server, these bytes break the header structure and allow injection of attacker-supplied headers like Set-Cookie values.
• Attack impacts include cookie manipulationBy injecting a Set-Cookie header, an attacker can set arbitrary session cookies or other cookie values in the response. The article notes that response splitting can also poison caches, redirect users, and in older server stacks split the response to serve attacker-controlled content.
• Modern servers reject bare CR/LF by defaultThe vulnerability is rarer today because modern web servers and frameworks reject bare CR/LF characters in header values by default, hardening the default case. However, it still appears in applications that build headers manually through string concatenation rather than using framework APIs.
• Defense requires stripping or rejecting charactersThe article prescribes four defenses: strip or reject CR and LF from any value placed in a response header; use framework APIs that validate and encode header values instead of string concatenation; validate redirect targets against an allowlist instead of reflecting raw input; and keep servers and frameworks current to benefit from built-in protections.
• Maps to OWASP Injection vulnerabilityCRLF injection (CWE-93) is classified as an Injection vulnerability under the OWASP Top 10 (2021), reflecting its status as a fundamental input-handling flaw where untrusted data changes program behavior by supplying characters with special meaning.

Bottom line: CRLF injection remains a threat wherever applications build HTTP headers through string concatenation without filtering CR and LF characters—strip or reject these characters, use framework header APIs with built-in encoding, and validate redirect targets against an allowlist to prevent attackers from injecting malicious headers like Set-Cookie.