Basic of Web cache and web cache poisoning

Hi everyone,

I am Nishan Ghimire, developer, engineering student and security researcher

Today we are diving deep in to the world of web cache and how web cache poisoning vulnerability work in detail. so let’s start,

so what is web cache ? we can consider web cache like the assistant of a server who helps to reduce the load of server. but how ?? okay lets understand this through a simple example.

Suppose I have a website hosted on a server then if there are many user who visit my site regularly then server have a lot to process, here comes the role of web cache where it acts as helping hand of server. web cache is situated in between a user and server so whenever the user request the page for the first time web cache forward request to server and keeps the copies of the response with itself and whenever another user request the same page, web cache check the page and return the response without contacting the server. so this way server processing load decreases and also decreasing the latency issues and a poor user experience of client.

As we can see the working of web cache in above diagram too !!

Now let put our hacker hat and think how this feature might be misused if web cache feature is not properly implemented. As shown in diagram client-1’s request response has been saved in cached and same cache served to all other client until the cache expires.

Yes, you can poisoned the cache with something malicious and that malicious dish is served to other users if web cached is not configured properly.

So what impact can it create if this vulnerability exist ??

Let’s understand this with a simple example. Suppose we have website example.com and the vulnerability exist in its home page so what attacker can do it they can use web cache to inject javascript . So injected javascript code can be code to steal cookie or session which can lead to account takeover. The impact of this vulnerability depends how popular is the page, the more the user visited more number of user affected.

Now let’s learn in detail the working of this vulnerability.

The web cache identify whether it has response to serve or not by cache key. cache key is made of request line and Host header (might also include other header according to situation). The other parts of header not included in host key is called unkeyed.

So now first part is to identify if the request is vulnerable to web cache poisoning or not. Any web cache poisoning attack relies on manipulation of unkeyed inputs, such as headers. so we need to find the unkeyed inputs because Web caches ignore unkeyed inputs when deciding whether to serve a cached response to the user. Therefore, the first step when constructing a web cache poisoning attack is identifying unkeyed inputs that are supported by the server. so to identify the unkeyed inputs manually we need to test different random input to request and observe the response to see if input cause any changes or reflection in the response.

For Automation of unkeyed detection we have the extension called param miner in Burpsuite.

Once we understand how it the unkeyed is processed then we can processed forward. if the input is reflected in the response or is being dynamically being processed then it might be potential entry point.

The Exploitation technique we will discuss in next part with example labs.

Till then see you !!