Guide to Web Cache Poisoning Exploitation

Web cache poisoning is an increasingly significant vulnerability in the world of web security. Bug bounty hunters can find this vulnerability rewarding to exploit because it allows attackers to deliver malicious content to users via the cached data of a web server. This extensive guide covers what web cache poisoning is, how to find and exploit it, the tools you need, and how to stay safe from this vulnerability.

What is Web Cache Poisoning?

Web cache poisoning occurs when an attacker tricks a caching system into storing and serving harmful data to legitimate users. Caching systems, used by web servers to improve performance, store copies of frequently accessed pages or resources to reduce the server’s workload and load times. However, if caching policies are improperly configured, attackers can manipulate the stored content and replace it with malicious data.

When users later request the cached page, they receive the poisoned version rather than the legitimate one. This can lead to phishing, cross-site scripting (XSS), or other dangerous exploits.

Key Concepts:

• Caching: A technique that temporarily stores copies of web pages to serve them faster.
• Web Cache: A system (like Varnish, Squid, or CDN providers) that stores copies of resources requested by users.
• Poisoning: Injecting malicious content into the cache that is then served to subsequent users.

How Web Cache Poisoning Works

At a high level, web cache poisoning works in three steps:

1. Identify Cacheable Content: The attacker locates a resource that the caching system stores.
2. Send a Malicious Request: The attacker sends a specially crafted HTTP request that manipulates the cache’s storage mechanism.
3. Exploit Poisoned Cache: When future users request the resource, they receive the malicious content from the cache.

Example:

Consider a caching system that stores the response of a web page as follows:

GET /profile?user=admin HTTP/1.1
Host: example.com

If the caching system is improperly configured, the attacker might send a request with malicious parameters, such as:

GET /profile?user=<script>alert(1)</script> HTTP/1.1
Host: example.com

Now, every subsequent user who requests /profile?user=admin will see the page with the injected script, resulting in an XSS attack.

How to Find Web Cache Poisoning Vulnerabilities

1. Identify Cacheable Resources

Start by identifying which pages or resources are being cached. Look for headers like Cache-Control or Expires in the server responses. If caching is enabled, these headers might indicate how long the resource will be stored and served from the cache.

2. Test for Unkeyed Inputs

Cache keys determine which requests are cached. A caching system might consider only certain parameters in the URL or headers when determining what to cache. If non-keyed parameters or headers (such as User-Agent) are used by the application but not by the cache, the attacker can poison the cache by manipulating those values.

For example, test variations like:

• User-Agent: Sending different user agents (like Chrome or Firefox) in requests can check if responses are cached based on user agent alone.
• X-Forwarded-For: Modify the X-Forwarded-For header to inject malicious content.

3. Inject Malicious Content

Once you’ve identified a cacheable resource and discovered which parts of the request are not factored into the cache key, try injecting payloads that will be stored in the cache. These payloads can be anything from XSS payloads to redirects to malicious websites.

Common injection points:

• URL parameters
• HTTP headers (such as X-Forwarded-For, User-Agent)
• Cookies

4. Analyze Cache Behavior

After sending the malicious request, check if the server serves the poisoned content to other users. You can do this by making subsequent requests to the same cacheable resource and seeing if your injected payload is returned.

Example of Exploiting Web Cache Poisoning

Scenario: An e-commerce website caches the contents of product pages based on URL parameters like product_id. The cache does not factor in other HTTP headers, such as User-Agent.

1. Initial Request:

GET /product?product_id=123 HTTP/1.1
Host: shop.com
User-Agent: Mozilla/5.0

The server returns the product page and caches it for future requests.

2. Poisoning the Cache:

GET /product?product_id=123 HTTP/1.1
Host: shop.com
User-Agent: <script>alert(1)</script>

The caching system ignores the User-Agent header and caches this poisoned response.

3. Exploitation:
   The next user who requests /product?product_id=123 will receive the page with the injected script. This can be used to execute XSS or redirect the user to a malicious site.

Tools for Finding Web Cache Poisoning

Several tools can help you discover and exploit web cache poisoning vulnerabilities:

1. Burp Suite

• Why Use It: Burp Suite is an essential tool for intercepting and modifying HTTP requests. With its proxy and repeater features, you can test different requests and headers to identify cache poisoning vulnerabilities.
• How to Use: Use Burp’s proxy to capture and manipulate headers like X-Forwarded-For, Referer, or User-Agent to see if you can poison the cache. Repeater lets you send modified requests to test cache behavior.

2. OWASP ZAP

• Why Use It: OWASP ZAP is a free and open-source alternative to Burp Suite. It helps intercept and modify requests while analyzing cache headers.
• How to Use: Use the proxy to monitor and manipulate traffic. OWASP ZAP can also scan for potential cache poisoning vulnerabilities automatically.

3. Cache Poisoning Scanner

• Why Use It: This is a specialized Burp Suite plugin created specifically to identify cache poisoning vulnerabilities.
• How to Use: Install the plugin and run it against target URLs to automatically detect misconfigurations that could lead to cache poisoning.

4. Smuggler

• Why Use It: This tool detects HTTP request smuggling, which can often lead to cache poisoning if the caching system doesn’t properly handle malformed requests.
• How to Use: Smuggler automates the process of testing for HTTP request smuggling attacks, which can indirectly result in cache poisoning.

5. Ffuf (Fuzz Faster U Fool)

• Why Use It: Ffuf is a powerful fuzzing tool that can help you brute-force parameters and headers to test cache behavior.
• How to Use: Use ffuf to fuzz URL parameters, headers, or any other input that might affect the caching behavior of the target server.

Preventing Web Cache Poisoning

To defend against web cache poisoning, organizations must implement the following best practices:

1. Use the Vary Header Correctly

The Vary header tells the caching system which parts of the HTTP request should affect the cached response. If you allow different responses based on User-Agent, cookies, or other headers, ensure that the Vary header reflects this. For example:

Vary: User-Agent

This ensures that different versions of the content are cached for different user agents.

2. Restrict Cacheable Content

Be very selective about what content is cached. Dynamic or user-specific content (like user profiles, shopping carts) should never be cached. Use headers like:

Cache-Control: no-store

This tells the caching system not to store the response at all.

3. Sanitize User Inputs

Always sanitize inputs in URLs, headers, and parameters to prevent malicious payloads from being injected into cacheable resources. Use proper input validation and sanitization for every part of a request.

4. Implement Strict Cache Control Policies

Use Cache-Control headers properly to enforce strict caching rules. For example:

Cache-Control: private, max-age=3600

This ensures that only private (user-specific) data is stored for a limited time.

5. Monitor and Log Cache Behavior

Implement logging and monitoring for abnormal caching behavior. If you notice that certain resources are being requested unusually frequently or that malicious content is being served from the cache, investigate immediately.

Conclusion

Web cache poisoning is a dangerous vulnerability that can be challenging but rewarding to find and exploit. By understanding how caching works and how to manipulate it, bug bounty hunters can uncover significant security risks. Use tools like Burp Suite, OWASP ZAP, and Cache Poisoning Scanner to assist in your testing, and always ensure that your findings are reported responsibly.

Organizations can protect themselves by implementing strong cache control policies, sanitizing user input, and correctly using the Vary header. With proper defenses in place, the risk of cache poisoning can be significantly reduced.