Contents

Documentation - HTTP Response Splitting

Short explanation of how the cache works

To exploit this vulnerability we will need to understand how the cache works. To increase response speed, the cache stores server responses associated with requests like this:

/login => login page
/admin => admin page
/register => register page
/posts => posts page

So when we make a request on /posts for example, the cache sends us the answer of the server which is associated to /posts stored in cache.

What is the HTTP Response Splitting flaw?

The HTTP Response Splitting flaw is a type of CRLF where the goal is to inject a second response.

HTTP/1.1 302 FOUND
[...]
Set-Cookie: theme=dark

HTTP/1.1 200 OK
[...]

Here we have the response expected by the server with our cookie in the headers. Thanks to the presence of a user entry in the headers, we can exploit a CRLF to inject not a new header, but an entire response !

How to use this flaw to exploit an XSS?

By performing this injection, there is no apparent impact in our browser, but we can exploit the cache. After the injection, the second response (the injected response) is not stored in the cache because it has no associated request, so the cache will wait a few seconds to receive a request to which to attach this “single” response.

This means that if we make a request right after the injection, this request will be associated with the injected response and when other users will GET this URL, they will receive the injected response. Now we just have to add some JavaScript code in the content of our injected response.

Exploit

First, we need to flush the cache to remove all responses associated with the requests, or we will not be able to modify them. Second, we need to perform our injection. Finally, we need to make a request on the page we want to associate with our response.

Here is a pseudocode to achieve our exploit:

# Request on the page to exploit to clear the cache
# Request containing our injection
# Request on the page to exploit to associate this request with the answer waiting in the cache

How to know if the feat was successful

To know if the exploit has succeeded you just have to look at the content of the page to be exploited, if the content displayed is the injected JavaScript code then the exploit has worked, if on the contrary the content of the page is the same as the one initially planned we are good to review our exploit.

Références