Vulnerability Tutorial - HTTP Response Splitting
  Updated: 06/22/09     (YELLOW light)  
Impact
An attacker could cause an erroneous page, possibly including malicious script, to be placed in a web cache or browser cache.
Background
According to the HTTP protocol, when a web browser sends a request to a web server, the response consists of a header, followed by a blank line, followed by the content of the page. The header begins with a response code, such as HTTP/1.0 200 OK, followed by information such as content type, content length, redirection information, and cookies.
The Problem
Some programs on web servers place user-supplied parameters into certain HTTP headers. For example, a user who selects the language English from a web form may receive the following HTTP response from the web server:
HTTP/1.0 302 Moved
Content-type: text/html
Location: http://hostname/index.php?language=English

<html>Your browser will be redirected to the English page.</html>
If a web program does not filter newline characters from input parameters before placing them into the HTTP header, it is possible for an attacker to split the HTTP response into two separate responses. For example, if the user supplied the following language value:
English

HTTP/1.0 200 OK
Content-type: text/html

<html>This is my page</html>
then the web server response would be:
HTTP/1.0 302 Moved
Content-type: text/html
Location: http://hostname/index.php?language=English

HTTP/1.0 200 OK
Content-type: text/html

<html>This is my page</html>

<html>Your browser will be redirected to the English page.</html>
Thus, the web server issues two separate responses to one query. The target will believe that the second response, beginning with HTTP/1.0 200 OK, is in response to the next query, which could be an entirely different URL, such as /index.html. This would cause /index.html to become erroneously cached, such that users who subsequently request /index.html would see a defaced page, reading This is my page. Furthermore, malicious script on the defaced page would be executed in the user's browser in the context of the real web site.
Resolution
User-supplied parameters which are placed into HTTP headers should be checked for illegal characters such as carriage returns (%0d) and newlines (%0a).

Fix information for specific products can be found in the references below.

More Information
More information on HTTP response splitting can be found in Divide and Conquer by Sanctum, Inc.

For more information on specific HTTP response splitting vulnerabilities, see the following references: