HTTP Response Splitting

HTTP headers are terminated by carriage return + line feed (CRLF: \r\n). When user input is placed in a response header without stripping CRLF characters, attackers can inject additional headers or even a second HTTP response body.

Vulnerable redirect (PHP):

$redirect = $_GET["url"];
header("Location: " . $redirect);

An attacker sends: https://example.com/%0d%0aSet-Cookie:%20session=evil

This produces the response headers:

Location: https://example.com/
Set-Cookie: session=evil

Cache poisoning: By injecting a full second response body, attackers can poison shared caches with malicious content served to all users. This is known as HTTP Response Splitting.

The primary defense is to strip or reject CRLF characters from any user input that will be used in HTTP response headers.

Safe redirect (Node.js/Express):

function safeRedirect(res, url) {
  // Strip CRLF characters
  const safe = url.replace(/[\r\n]/g, "");
  // Additionally validate against an allowlist
  const allowed = ["https://example.com", "https://app.example.com"];
  if (!allowed.some(a => safe.startsWith(a))) {
    return res.status(400).send("Invalid redirect");
  }
  res.redirect(safe);
}

Framework protections:

• Express.js: res.redirect() sanitizes the Location header since v4
• Django: HttpResponseRedirect encodes the URL
• Spring: Use UriComponentsBuilder to construct safe URIs

Defense checklist:

• Strip \r and \n from all header values
• Validate redirect URLs against an allowlist
• Use framework redirect methods rather than raw header setting
• Set appropriate Cache-Control headers