Hello Folks,
This blog will focus on an advanced vulnerability called Web Cache Poisoning and dive deep into its concepts using PortSwigger’s platform. All big company websites have a web cache mechanism, which is essential for security. So, let’s begin by understanding this mechanism in detail, and then we will move forward and begin the penetration testing process to identify web cache poisoning vulnerabilities.
Assume a scenario where a web server receives all the requests and sends the required responses to the clients. This could be hectic for the server, so we have the concept of a cache server to ease the load on the web server. This cache server sits between the end user’s browser and the web server and will cache the response given to the user so that it can replay the same response to other users accessing the same webpage. This functionality reduces the latency and improves the user experience by reducing the number of similar requests.
Now we know about the web cache mechanism, let’s understand the concept of a web cache poisoning attack. The objective of this attack is to poison the cache stored on the web cache server so that the users accessing the website can get harmful responses which might result in client-side attacks like Cross-Site Scripting (XSS), DOM-based attacks, open redirection, etc.
When an HTTP request is received by the cache server, it identifies the components of the requests like the host header and resource header. This is known as the cache key. This cache key provides the response to the end user requesting access to the same resource.
Before diving practically into its concepts, let’s explore how we can construct a web cache poisoning attack. First, we have to look for unkeyed inputs which are considered as those components of a request that are not keyed. We can use a very powerful extension available on Burp Suite Professional called “Param Miner” to identify such headers and parameters. Second, we have to generate a harmful response from the web server which can exploit client-side vulnerabilities like XSS. You can visit our blogs on XSS Vulnerability and learn how can we identify and exploit different types of it. And at last, we have to get this response cached so that the users who are accessing the same web pages can be targeted.
Web Cache vulnerabilities can be exploited by identifying flaws in the design and implementation of the cache. In this blog, we will be discussing a vulnerability in the design flaw of the cache.
After knowing about this vulnerability, let’s dive into a practical to understand these concepts. We will be using the PortSwigger’s labs to learn about it.
Lab- Web cache poisoning with an unkeyed header
Web cache vulnerabilities can be performed by identifying an unkeyed header whose value is getting reflected in the response through which we might exploit other client-side vulnerabilities. After that, we have to find a way to get this cached on the cache server.
Let’s open the lab by clicking here and read the lab description. Also, we will require Burp Suite Professional to identify and exploit this vulnerability.
Let’s start the lab and load the homepage while proxying the traffic through Burp Suite. Install the “Param Miner” extension on your Burp Suite, then right-click on the homepage request and select “Extensions”. Now we have to click on Param Miner and then select “Guess headers” which will start its process and let us know the headers that can be used to perform web cache poisoning.
We will get its results on the “Target” tab and then we can click on “Site”. We can see “X-Forwarded-Host” HTTP request header can be used to perform this attack.
Let’s take this request to Repeater and then we can add this header in the request pointing towards an arbitrary domain. Also, we have to add a cache buster which will not affect the request to the homepage. Now let’s send this request and in the response, we will find that the arbitrary domain is reflecting.
Now this dynamically generated URL is importing the “/resources/js/tracking.js” file which we have to host on our exploit server. To load this script, we have to change the value of the “X-Forwarded-Host” header and point it towards our exploit server’s URL.
So, let’s open the exploit server and change the name of the file to “/resources/js/tracking.js”. Now, in the body of the request, we have to mention the following:
alert(document.cookie)
Now, let’s click on the store button. Copy the URL of the exploit server and paste it into the “X-Forwarded-Host” header present on the Burp’s repeater tab. Finally, let’s remove the cache buster and point the request toward the homepage which usually runs on the “/” resource. Now, let’s send this request repeatedly until we see the exploit server’s URL reflected in the response with X-Cache: hit in the headers.
If we go to the browser and refresh the homepage, we will find the reflection of the alert() which confirms that we have successfully exploited the XSS vulnerability using a Web Cache Poisoning attack.
This is how we have to identify and exploit web cache-related vulnerabilities. This example was a basic example but in the upcoming blogs, we will explore other techniques to target this vulnerability. If you want to dive deep into other web-related vulnerabilities, then you can visit our website.
Happy Pentesting!
Team CyberiumX