Introduction

Web caching is a vital mechanism that enhances website performance by reducing server load and improving page load times. It acts as an intermediary between a user’s browser and the web server, storing copies of web pages for faster access. However, while web caching improves performance, it also introduces risks. For example, attackers can manipulate the cache to inject harmful content (web cache poisoning) or trick the system into serving compromised data (web cache deception). These attacks pose significant security concerns for website owners and users alike. Understanding and addressing these risks are essential topics we will explore further in this article.

Web Cache Poisoning

Web cache poisoning can occur through attack vectors that exploit vulnerabilities in web applications or misconfigurations in caching systems. One common method involves injecting malicious data into the cache by manipulating input parameters, such as URL parameters or HTTP headers. 

Attackers can send specially crafted requests containing harmful scripts. If the application does not properly validate and sanitize these inputs, it stores the malicious content in the cache. Consequently, when other users request the same URLs, they may receive the poisoned content, which can execute scripts, redirect them to phishing sites, or expose sensitive data.

Additionally, attackers can take advantage of improperly configured cache control mechanisms, allowing the poisoned content to remain in the cache for an extended period, impacting multiple users.

Explanation of The Attack

To illustrate the risks of Web Cache Poisoning, we present a penetration test scenario where we exploited it to execute unauthorized JavaScript in users’ browsers, leading to Cross-Site Scripting (XSS) attacks.

We began our research by examining the web application’s cache mechanism, including its keys and logic. Next, we appended various HTTP headers to a request, testing the server until we discovered a valid reflection using the X-Forwarded-Host header.

This caused the header’s value to be cached inside an Anchor HTML element within an href attribute. Next, we aimed to escape the Anchor element into the DOM—a tree-like structure representing web pages—so we could inject JavaScript and execute client-side code, potentially affecting users without their interaction.

Exploitation

The system filtered out essential characters like “.”, “:”, and uppercase letters needed for the attack payload. To bypass this, we used a minified JavaScript technique called “JSF*ck,” which represents code using only six characters. The payload redirected users automatically to attacker-controlled websites and was constructed as follows:

window.location.href=”https://clear-gate.com”.

Note: In this scenario, we added a random query parameter (e.g., p=1) to the request. This hid the cache poisoning from other users, since the cache key includes all query parameters.

Mitigation

If you have replicated the above attack in your application, please consider the following instructions for immediate mitigation to prevent Web Cache Poisoning attacks:

• Implement strict input validation and sanitization techniques on all user-provided data and parameters. This ensures that malicious input is detected and blocked before it can reach the cache and cause poisoning. For more information, refer to this article.
• Web applications should focus on securely generating cache keys that are resistant to manipulation. Implementing strong cryptographic hashing algorithms to generate cache keys based on the complete request, including headers, cookies, and other sensitive information, is essential. For more information, refer to this article.

Web Cache Deception

Attackers manipulate caching systems to trick users or web applications into serving unintended content. They craft malicious requests that exploit caching vulnerabilities, causing sensitive data linked to legitimate URLs to be cached. Consequently, subsequent users who request these URLs may unknowingly expose their confidential information to the attacker, putting their privacy and security at serious risk.

Explanation of The Attack

We present an attack diagram to illustrate the risks of Web Cache Deception and its potential for malicious exploitation. In this case, we demonstrate how caching non-existent JavaScript files can grant prolonged unauthorized access to sensitive pages within the application.

For this attack to be successful, three specific conditions must be met:

1. Configure the web application cache to store static files based on their extensions, ignoring any caching headers from the server.g headers provided by the server. 

2. When a user accesses a URL like “http://www.example.com/home.php/non-existent.css,” the server should serve the content of “home.php,” even though “non-existent.css” does not exist.

3. The server doesn’t require authentication to access its public static files. Consequently, the cached files become publicly accessible without needing any authentication.

Exploitation

By appending a non-existent JavaScript file to the URL, the cache stored the home page content as a static file. Sending this URL as a phishing link can expose sensitive data, since cached static files are accessible to everyone, including unauthenticated users, due to server load optimization.

Mitigation

If you have encountered the above scenario, please follow the instructions below provided by Clear Gate for immediate mitigation and to prevent Web Cache Deception attacks further:

• Design and enforce strict caching policies tailored to your application’s needs. Use private caching for sensitive data that should not be cached by intermediate proxies, and utilize public caching for safe, shareable resources. Regularly review and update caching policies to adapt to changing security threats. For more information, refer to this article.
• Adjust the web server configuration to handle pages like “http://www.example.com/MyAccount/non-existent.css” differently. When such URLs are accessed, the server should respond with a 404 or 302 response instead of serving the content of “MyAccount”. This will avoid unintentional content exposure and improve the application’s overall security. For more information, refer to this article.

Conclusion

Web cache poisoning and deception pose serious risks when caches store response copies to reduce backend load. Mismanaged caches can store malicious content, exposing unsuspecting users to attacks.

To mitigate these risks, configure strong input validation, secure caching policies, and proper headers to prevent cache poisoning. Additionally, manage cache eviction carefully to ensure cached data serves only the intended user or session. Regularly monitor and audit caches to detect deception and act promptly. By following these steps, web applications can better protect users’ data from cache poisoning and deception attacks.

Organizations should prioritize cybersecurity assessments and penetration tests to reduce risks in web caching, which is increasingly used in SaaS products. Clear Gate provides in-depth manual penetration tests to help companies strengthen web caching security and protect sensitive data from potential threats.

References

• OWASP Cache Poisoning
• James Kettle Research
• Omer Gil’s Web Cache Deception Article
• JSFu*k
• Account Takeover in ChatGPT using Web Cache Deception
• HTTP Headers, you should check injection with