In this section we will discuss some HTTP Misconfigurations that can lead to web Security Vulnerabilities Like Web Cache Poisoning, Host Header Attacks and Session Puzzling
In this section we will talk about the Web Cache Poisoning and how it actually works
Before talking about the Web Cache bugs we need to know first the benefits of caching?
The web cache is primarily used for websites with a high volume of user interactions. Instead of placing all the load directly on the web server, the traffic is distributed across Content Delivery Networks (CDNs) and reverse proxies. These systems sit between the client and the server, serving content from their local storage (cache) rather than repeatedly requesting it from the origin web server. This approach significantly improves performance, reduces server load, and enhances the user experience.
Now let’s see how the Cache works?
As mentioned earlier, web caches store resources to reduce the load on web servers. These resources can be static files like stylesheets and scripts, or dynamic content generated based on user input, such as search results. To serve cached content correctly, the cache must decide whether two requests can use the same stored response or if it needs to get a new one from the server.
Comparing requests exactly as they are is inefficient because different browsers send extra headers that don’t affect the response, such as the User-Agent header. Similarly, browsers often send a Referer header to show where a request came from, but this usually doesn’t change the server’s response.
But now how the server know that he need to serve the same cached response!? In web applications, cache servers use request parameters to determine how to serve cached responses. These request parameters are known as cache keys, as they are used to identify and retrieve the appropriate cached content.
Now let’s see two requests that will server the same content.
Please note that in the first request, the User-Agent indicates a Windows system, while in the second request, it indicates a macOS system. Despite this difference, both requests receive the same cached content.
This happens because, by default, the cache server serves responses based on the Host header and the GET request parameters. Since these values are identical in both requests, the cache server treats them as the same request and returns the same cached content.
Now let’s see a request that will serve a different cache content?
