This technique builds upon the scenario that user-supplied data is inserted into the headers of an HTTP response message. When this occurs, a misbehaving web server/application may cause adverse affects of an intermediary cache.
Scenario 1: Vulnerable web site
GET /redirect%0aX-Test:%20foo_test HTTP/1.0
HTTP/1.1 302 Found Date: Fri, 05 Mar 2004 16:41:31 GMT Server: Apache/1.3.29 Location: http://foo.com/redirect X-Test-Header: foo_test Connection: close Content-Type: text/html; charset=iso-8859-1
In this case, the web server/application unescaped the user-supplied data destined for the Location header. The result added a new "X-Test" header to the response. The new header could have easily been anything else, including "Set-Cookie". The important part is that an attacker has the ability to force the web site to serve up altered or invalid HTTP responses. Including making the result look like two separate HTTP Responses (Hence HTTP Response splitting). I have found a few places in the wild that exhibit this behavior.
Example:
GET /redirect%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/ 1.0%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent- Length:%200%0d%0a%0d%0a
The result would "look like" two independent HTTP responses.
HTTP/1.1 302 Moved Temporarily Date: Wed, 24 Dec 2003 15:26:41 GMT Location: http://foo.com/redirect Content-Length: 0
HTTP/1.0 200 OK Content-Type: text/html Content-Length: 0
A cache may improperly parse the response since it looks like two independent messages. The next HTTP request recieved might be attached to the seemingly second HTTP response. If it does, then you have the cache poisioning scenarios outlined in the white paper.
Scenario 2: Not-Vulnerable web site
GET /redirect%0aX-Test:%20foo_test HTTP/1.0
HTTP/1.1 302 Found Date: Fri, 05 Mar 2004 16:41:31 GMT Server: Apache/1.3.29 Location: http://foo.com/redirect /redirect%0aX-Test:%20foo_test Connection: close Content-Type: text/html; charset=iso-8859-1
In this case, the web server/application did NOT unescape the user-supplied data. The URL encoded data remains, as is, within the Location header. I would say the web site should have done some addition sanity checking by not allowing certain URL encoded characters to pass. But its hard to classify this as a vulnerability. If the cache is still confused, then the issue is there.
Here are the vulnerability requirements. 1) User-supplied data is inserted in the headers of an HTTP Response 2) User input is unescaped.
The results could have the ability to poison the cache in an intermediary device or a web browser.
Regards,
Jeremiah-
On Thursday, March 4, 2004, at 10:12 AM, Amit Klein wrote:
Hi
Today, Sanctum released a new whitepaper, titled "Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics". The full paper can be found in the following link: http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf
The paper's abstract is copied below:
