An attacker can use Web Cache Poisoning technique to send malicious response to other users. The poisoning will happen when certain unkeyed inputs are not validated by the application and allowing the malicious response to be cached.
Basic Example: Unkeyed Header
In the request, the attacker discovered that the X-Forwarded-Host value will be reflected in response. The application tries to load a tracking.js file from cache resources. When the attacker passes a specific host in X-Forwarded-Host parameter, the tracking.js file will be loaded from another path
<malicious host>/resources/js/tracking.js. Consequently, this allows the attacker to control the content of
Case of Unknown Header
In most situations, you will need to guess the unkeyed header. If you are using Burp Suite, then Paraminer will be a useful plugin to use.
First, go to the
Target tab and select the paths in scope. Then right click on all these selected paths and click
If you are using Burp Pro, then you can see the result appearing in
Dashboard - Issue activity.
Some sites may use the
Vary header in the response to decide when to use the cached response or to refresh the response from the server. In the lab example, we can see that User-Agent is used to decide when the cached is used. To target your victim, you will need to know their User-Agent and then use the User-Agent values in your poison payload.
DOM XSS from Web Cache Poisoning
In this example, we see how Web Cache Poisoning can cause DOM XSS in an application. In some cases, an application is taking some properties value from a JSON and then use the value dynamically in a DOM. The assumption is that these properties values can be trusted since they are controlled by the application. However if an application is susceptible to Web Cache Poisoning, then these properties value can be controlled by the attacker.
In the example, we first see that that there is a host injection issue. If you use
X-Forwarded-Host, then the injected host value will be reflected in the response.
In the response, we can also see that the injected host name will be used for retrieving a JSON value. Using the given exploit server (in the lab), we can see the access log showing that a user is making a
GET request to retrieve
After doing some tracing of the original JSON value, we can see that there is a property called ‘country’ which contains the value that will be passed to the innerHTML.
Since we found the attack surface, we can now create a JSON file in the exploit server. This will return a JSON which contains the DOM XSS payload.
Access-Control-Allow-Origin need to be wildcard in order for the object to be shared with the application.
After this is completed, then we can see that the Web Cache Poisoning will be successful and the DOM-XSS payload will be executed.