How to remediate – Web Cache Poisoning

Contents

1. Introduction

Web Cache Poisoning is a vulnerability where an attacker manipulates a web cache, causing it to store and serve malicious content to users. This can lead to defacement of websites, theft of sensitive information, or redirection to phishing sites. It typically affects applications using caching systems like proxy servers or CDNs. A successful attack could compromise confidentiality, integrity, and availability of the application.

2. Technical Explanation

The root cause is often unkeyed inputs in a web cache – headers or cookies not included when generating the cache key. This allows attackers to craft requests that bypass the cache and inject malicious responses. An attacker could, for example, use a specially crafted HTTP header to poison the cache with content containing JavaScript code that redirects users to a harmful website.

Root cause: Unkeyed inputs in the caching system allow manipulation of cached responses based on user-controlled data.
Exploit mechanism: An attacker sends a request with malicious input not included in the cache key, forcing the cache to store a poisoned response. Subsequent users receive this malicious content. For example, an HTTP header like ‘X-Forwarded-Host’ might be unkeyed.
Scope: Applications using caching systems (proxies, CDNs) are affected. Specific versions aren’t usually at fault but configuration is key.

3. Detection and Assessment

Confirming vulnerability involves checking for unkeyed inputs and testing if they affect cached responses. A quick check is to examine the application’s caching configuration. Thorough assessment requires sending crafted requests and observing the response served from the cache.

Quick checks: Review web server or CDN configurations for caching rules, paying attention to which headers/cookies are included in cache keys.
Scanning: Burp Suite’s active scanner can identify potential web cache poisoning vulnerabilities. This is an example only and requires careful review of results.
Logs and evidence: Examine proxy server logs for unusual HTTP requests with unexpected headers or cookies. Look for responses served from the cache that contain user-controlled input.

curl -I https://example.com -H "X-Forwarded-Host: attacker.com" | grep Cache-Control

4. Solution / Remediation Steps

The primary solution is to disable caching for affected inputs or pages. If both the input and caching are required, configure the cache to include the input in the cache key. This prevents attackers from injecting malicious content into the cache.

4.1 Preparation

Ensure you have access to revert the configuration if issues arise. A roll back plan is to restore the original configuration from the snapshot.
Change windows may be needed for complex configurations, requiring approval from relevant teams.

4.2 Implementation

Step 1: Identify affected inputs (headers or cookies).
Step 2: Disable caching for those specific inputs in the web server configuration. For example, in Nginx, remove the cache directive for that input.
Step 3: If caching is required, modify the cache key to include the identified input. This usually involves adding the header/cookie name to the `proxy_cache_key` directive.
Step 4: Restart the web server or CDN service to apply changes.

4.3 Config or Code Example

Before

proxy_cache_key "$scheme$request_method$host$request_uri";

After

proxy_cache_key "$scheme$request_method$host$request_uri$http_x_forwarded_host";

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent web cache poisoning. Input validation is crucial for blocking malicious data. Safe defaults, such as excluding unkeyed inputs from the cache key by default, reduce risk. Secure headers also play a role in controlling caching behavior.

Practice 1: Input validation to ensure only expected values are processed, preventing injection of malicious content into cached responses.
Practice 2: Least privilege for cache access to limit the impact if an attacker poisons the cache.

4.5 Automation (Optional)

Configuration management tools can automate changes to caching rules across multiple servers. For example, Ansible playbooks can update Nginx configurations and restart services.

---
- hosts: webservers
  tasks:
    - name: Update Nginx cache key
      lineinfile:
        path: /etc/nginx/nginx.conf
        regexp: 'proxy_cache_key "$scheme$request_method$host$request_uri";'
        line: 'proxy_cache_key "$scheme$request_method$host$request_uri$http_x_forwarded_host";'
    - name: Restart Nginx
      service:
        name: nginx
        state: restarted

5. Verification / Validation

Confirm the fix by sending a crafted request and verifying that it does not poison the cache. Check the response headers to ensure caching is behaving as expected. A simple service smoke test should confirm core functionality remains operational.

Post-fix check: Send a request with the malicious header/cookie again. Verify the response served from the cache does *not* contain the injected content.
Re-test: Repeat the initial detection steps (curl command) and confirm that the vulnerability is no longer present.
Smoke test: Confirm users can still access core application features, such as login or product browsing.
Monitoring: Monitor proxy server logs for unexpected HTTP requests with unusual headers/cookies. This is an example; tailor to your environment.

curl -I https://example.com -H "X-Forwarded-Host: attacker.com" | grep Cache-Control

6. Preventive Measures and Monitoring

Baselines: Update your CIS benchmark or internal security policy to require including all relevant headers/cookies in the cache key.
Pipelines: Integrate a SAST tool into your CI pipeline to scan code for potential caching vulnerabilities.
Asset and patch process: Review web server and CDN configurations quarterly, applying security patches promptly.

7. Risks, Side Effects, and Roll Back

Risk or side effect 2: Including too many inputs in the cache key can reduce cache effectiveness. Test thoroughly to ensure acceptable performance.

8. References and Resources

Vendor advisory or bulletin: N/A – configuration issue, no specific vendor advisory.
NVD or CVE entry: N/A – typically a configuration flaw rather than a software defect.
Product or platform documentation relevant to the fix: Updated on October 26, 2025

Was this article helpful?

Yes No