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
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.
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