HTTP Response Splitting - Revision history

Jmanico at 09:10, 29 June 2016

2016-06-29T09:10:30Z

Douglasheld: corrected the example

2016-05-03T15:07:06Z

corrected the example

Wichers at 18:46, 14 November 2013

2013-11-14T18:46:10Z

KirstenS at 12:44, 7 April 2009

2009-04-07T12:44:44Z

KirstenS at 12:51, 16 February 2009

2009-02-16T12:51:03Z

KirstenS: /* References */

2009-02-16T12:50:34Z

‎References

KirstenS: /* Description */

2009-02-16T12:48:29Z

‎Description

KirstenS at 12:48, 16 February 2009

2009-02-16T12:48:17Z

KirstenS: /* Related Attacks */

2008-09-18T12:43:26Z

‎Related Attacks

KirstenS: /* Related Attacks */

2008-09-18T12:43:14Z

‎Related Attacks

@@ Line 2: / Line 2: @@
 Last revision: '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Description==
@@ Line 52: / Line 49: @@
 The ability of the attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: [[Cross-User Defacement]], [[Cache Poisoning]], [[Cross-site Scripting (XSS)]] and [[Page Hijacking]].
 [[Category: Attack]]
 __NOTOC__

@@ Line 38: / Line 38: @@
 </pre>
-However, because the value of the cookie is formed of unvalidated user input, the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form:
+However, because the value of the cookie is formed of unvalidated user input, the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nContent-Length:45\r\n\r\n...", then the HTTP response would be split into an imposter response followed by the original response, which is now ignored:
 <pre>
@@ Line 44: / Line 44: @@
 	...
 	Set-Cookie: author=Wiley Hacker
-	HTTP/1.1 200 OK
+	<html>malicious content...</html> (to 999th character in this example)
-	...
+	Original content starting with character 1000, which is now ignored by the web browser...
 </pre>
-Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of the attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: [[Cross-User Defacement]], [[Cache Poisoning]], [[Cross-site Scripting (XSS)]] and [[Page Hijacking]].
+The ability of the attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: [[Cross-User Defacement]], [[Cache Poisoning]], [[Cross-site Scripting (XSS)]] and [[Page Hijacking]].
 ==Related [[Threat Agents]]==

@@ Line 14: / Line 14: @@
 HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header.
-To mount a successful exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allow them to create additional responses entirely under their control.
+To mount a successful exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header AND the underlying platform must be vulnerable to the injection of such characters. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allow them to create additional responses entirely under their control.
-==Risk Factors==
+The example below uses a Java example, but this issue has been fixed in virtually all modern Java EE application servers. If you are concerned about this risk, you should test on the platform of concern to see if the underlying platform allows for CR or LF characters to be injected into headers. We suspect that, in general, this vulnerability has been fixed in most modern application servers, regardless of what language the code has been written in.
 ==Examples==
@@ Line 74: / Line 73: @@
 * Watchfire Whitepaper: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics Whitepaper[http://download.watchfire.com/ttl/wp/HTTPResponseSplitting.pdf?file=HTTPResponseSplitting.pdf&authToken=1214447561_257e36e250a83a8e5942584866d295ee]
 ]]

@@ Line 5: / Line 5: @@
 <br>
 [[Category:OWASP ASDR Project]]
 ==Description==

@@ Line 21: / Line 21: @@
 ==Examples==
 The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.
@@ Line 86: / Line 85: @@
 [[Category: Protocol Manipulation]]
 [[Category: Attack]]
 __NOTOC__

@@ Line 72: / Line 72: @@
 * http://www.infosecwriters.com/text_resources/pdf/HTTP_Response.pdf - HTTP Response Spliting
 * http://www.securiteam.com/securityreviews/5WP0E2KFGK.html - Introdution to HTTP Response Spliting
 * Watchfire Whitepaper: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics Whitepaper[http://download.watchfire.com/ttl/wp/HTTPResponseSplitting.pdf?file=HTTPResponseSplitting.pdf&authToken=1214447561_257e36e250a83a8e5942584866d295ee]
 ==Credit==

@@ Line 62: / Line 62: @@
 * [[Cross-User Defacement]]
 * [[Cache Poisoning]]
-* [[Cross-Site Scripting (XSS)]]
+* [[Cross-site Scripting (XSS)]]
 * [[Page Hijacking]]