Web Cache Poisoning
Cachebuster
Accept-Encoding: gzip, deflate, cachebuster
Accept: */*, text/cachebuster
Cookie: cachebuster=1
Origin: https://cachebuster.vulnerable-website.comLab: Web cache poisoning with an unkeyed header
First, we will see if there any unkeyed header that is being used by using param miner on the home page request.
After running the param miner, we can see there is an unkeyed header that is being used.
After putting the header into the request, we can see the value is being reflected.
We will put the payload and the path to use into the exploit server as shown below
Now, we just need to re-poison the cache to put the exploit server URL in.
Finally, we just need to keep re-poisoning the cache until the victim opens the home page.
Lab: Web cache poisoning with an unkeyed cookie
We can see that the fehost cookie is being reflected in the website
So, we can modify our request such as the one shown below to invoke the XSS payload.
After which, keep poisoning the cache to solve the lab.
Lab: Web cache poisoning with multiple headers
By using param miner, we can see that there is 2 unkeyed header: X-Forwarded-Hostand X-Forwarded-Scheme.
After adding the 2 headers into it, we can see that the X-Forwarded-Host's value get reflected into the Locationin the response body
After playing around even more, we will notice that the parameters that is added on the path will be appended to the back.
After looking in the proxy history, we can poison the cache to return a malicious /resources/js/tracking.js.
First, we will need to modify the content in the exploit server to what is shown below
Next, we will just need to modify the request as what is shown below.
To solve the lab, we will just need to keep poisoning the cache until the victim visits the home page.
Lab: Targeted web cache poisoning using an unknown header
By using the Param miner, we can see that there is header X-Host
After paying around for a bit, we can see that the X-Hostvalue gets reflected into the response body
After which, we will set the payload on the exploit server
However, this is to target a specific group of User-Agent, so we still need to find a way to get them
To get the victim's User-Agent, we wil just need to put an image tag so that it will send a request to the exploit server
In the access log, we are able to see the victim's User-Agent.
Finally, we just need to replace it and ensure the cache is poisoned to solve the lab
Cache probing methodology
Identify a suitable cache oracle
The first step is to identify a suitable "cache oracle" that you can use for testing. A cache oracle is simply a page or endpoint that provides feedback about the cache's behavior. This needs to be cacheable and must indicate in some way whether you received a cached response or a response directly from the server. This feedback could take various forms, such as:
An HTTP header that explicitly tells you whether you got a cache hit
Observable changes to dynamic content
Distinct response times
If you can identify that a specific third-party cache is being used, you can also consult the corresponding documentation. This may contain information about how the default cache key is constructed. You might even stumble across some handy tips and tricks, such as features that allow you to see the cache key directly. For example, Akamai-based websites may support the header Pragma: akamai-x-get-cache-key, which you can use to display the cache key in the response headers:
GET /?param=1 HTTP/1.1 Host: innocent-website.com Pragma: akamai-x-get-cache-key HTTP/1.1 200 OK X-Cache-Key: innocent-website.com/?param=1
Probe key handling
If you're fortunate enough to have direct access to the cache key, you can simply compare the key after injecting different inputs. Otherwise, you can use your understanding of the cache oracle to infer whether you received the correct cached response. For each case that you want to test, you send two similar requests and compare the responses.
Let's say that our hypothetical cache oracle is the target website's home page. This automatically redirects users to a region-specific page. It uses the Host header to dynamically generate the Location header in the response:
To test whether the port is excluded from the cache key, we first need to request an arbitrary port and make sure that we receive a fresh response from the server that reflects this input:
Next, we'll send another request, but this time we won't specify a port:
Identify an exploitable gadget
By now, you should have a relatively solid understanding of how the target website's cache behaves and might have found some interesting flaws in the way the cache key is constructed. The final step is to identify a suitable gadget that you can chain with this cache key flaw. This is an important skill because the severity of any web cache poisoning attack is heavily dependent on the gadget you are able to exploit.
Last updated