What is the difference between web cache poisoning and web cache deception?
- In web cache poisoning, the attacker causes the application to store some malicious content in the cache, and this content is served from the cache to other application users.
- In web cache deception, the attacker causes the application to store some sensitive content belonging to another user in the cache, and the attacker then retrieves this content from the cache.
\:as a header. Note that sometimes these kind of status code aren't cached so this test will be useless.
X-Forwarded-Forto indicate the client to load script from there:
X-Cachein the response could be very useful as it may have the value
misswhen the request wasn't cached and the value
hitwhen it is cached. The header
Cache-Controlis also interesting to know if a resource is being cached and when will be the next time the resource will be cached again:
Cache-Control: public, max-age=1800Another interesting header is
Vary. This header is often used to indicate additional headers that are treated as part of the cache key even if they are normally unkeyed. Therefore, if the user knows the
User-Agentof the victim he is targeting, he can poison the cache for the users using that specific
User-Agent. One more header related to the cache is
Age. It defines the times in seconds the object has been in the proxy cache.
X-Forwarded-Foris being reflected in the response unsanitized> You can send a basic XSS payload and poison the cache so everybody that access page will be XSSed:
X-Forwarded-Hostto a domain controlled by you and
http.If the server is forwarding all the HTTP requests to HTTPS and using the header
X-Forwarded-Schemeas domain name for the redirect. You can control where the pagepointed by the redirect.
X-Hostheader is being used as domain name to load a JS resource but the
Varyheader in the response is indicating
User-Agent. Then, you need to find a way to ex-filtrate the User-Agent of the victim and poison the cache using that user agent:
wcvs -u example.com
x-http-method-override. So it was possible to send the header
x-http-method-override: HEADand poison the cache into returning an empty response body. It could also support the method
x-forwarded-schemevalue and uses it as the scheme of the request.
x-forwarded-scheme: httpheader would result into a 301 redirect to the same location which will cause a DoS over that resource as in this example:
sizeparameter in the request but if you sent also the
siz%65parameter with a bad value, the cache key was constructed with the well written size param, but the backend used the value inside the URL encoded param.
sizeparameter caused it to be ignored by the cache, but used by the backend. Giving the parameter a value of 0 would result in a cacheable 400 Bad Request.
\would cause a cacheable 400 Bad Request error. This was one of the most commonly identified patterns throughout my testing.
.pngetc are usually configured to be saved in the cache. Therefore, if you access
www.example.com/profile.php/nonexistent.jsthe cache will probably store the response because it sees the
.jsextension. But, if the application is replaying with the sensitive user contents stored in www.example.com/profile.php, you can steal those contents from other users. Other things to test:
text/htmlcontent-type instead of a
text/cssmime type (which is the expected for a .css file).