Introduction :

Embarking on a journey to demystify the world of Web Cache Poisoning vs Web Cache Deception, this blog aims to shed light on these cybersecurity threat in a way that is accessible to both the tech-savvy and those less familiar with the intricacies of the internet.

What is Web Caching ?

Web caching refers to the process of storing copies of web resources (such as web pages, images, stylesheets, and scripts) at various locations, either on the user's device or on intermediary servers.

Why HTTP Caching is so important ?

So lets discuss why HTTP caching is so important for us all well first of all it's going to make your website or web app much much faster because you're not going to make this unnecessary call to the server anymore to download this asset and the second reason is that all users are usually using mobile data and they're paying money for that mobile data so imagine a user has to download the same heavy asset let's say an image of 300 KB everytime they refresh a page and they're gonna be paying some money for that image so in order to save them money and not let them download this image over and over again you can use caching.

Here's a breakdown of how web caching works :

User's Browser Cache :

When you visit a website, your web browser stores copies of certain files, like images and stylesheets, in a local cache on your device. The next time you visit the same website, the browser checks its cache first to see if it already has a copy of the required resources. If it does, it can use those local copies instead of downloading them again from the internet.

Proxy Servers and Intermediate Caches :

In addition to browser caching, organizations often use proxy servers or content delivery networks (CDN's) that have their own caches. These intermediary caches sit between the user's device and the original web server. If a user requests a resource that the intermediary cache has stored, it can serve the cached content, reducing the load on the original server and speeding up content delivery.

Content Delivery Networks (CDN's) :

CDN's are networks of servers distributed globally to reduce latency and deliver content more efficiently. CDN's cache copies of web resources in multiple locations, allowing users to access content from a server that is geographically closer to them. This not only speeds up content delivery but also helps distribute the load across different servers.

Web Cache Poisoning : Tainting the Digital Oasis

Cache poisoning is aimed at manipulating the client-side cache to force clients to load resources that are unexpected, partial, or under the control of an attacker. The extent of the impact is contingent on the popularity of the affected page, as the tainted response is served exclusively to users visiting the page during the period of cache contamination.

Before delving into the intricacies of exploitation, it's essential to establish a clear understanding of two fundamental concepts: Keyed Input and Unkeyed Input. These terms will be recurrent throughout the subsequent sections of this blog.

What is Keyed and Unkeyed Input ?

Cache Keys or Keyed input is used to determine whether a response for particular request is stored in the cache or not. Whenever a cache receives a request for a resource, it has to check if it has the same copy to reply with or whether it has to forward to respective servers. As this is quite tricky, few components of the HTTP request are used as an identity to do so, called the cache-keys. If the cache key of an incoming request matches the key of a previous request, then the cache considers them to be equivalent

whereas Unkeyed input is not used to determine anything but it's still a part of the request and the response.

The execution of a cache poisoning assault involves several steps :

Constructing a web cache poisoning attack involves several steps, including identifying unkeyed inputs, eliciting a harmful response from the back-end server, and ensuring that the response is cached. By exploiting vulnerabilities in web caches, attackers can distribute various types of attacks to unsuspecting users.

Practical :

In this practical demonstration, we are using a vulnerable Web Cache Poisoning Lab.

1. Identification of Unkeyed Inputs :

These are parameters that, although not required for a request to be cached, can alter the response returned by the server. Identifying these inputs is crucial as they can be exploited to manipulate the cache.

You could use Param Miner or Arjun to brute-force parameters and headers that may be changing the response of the page.

Firstly, send the request to Param miner --> Guess params --> Guess headers

For example, in the following screenshot, Param Miner found an unkeyed header X-Forwarded-Host on the home page of the website :

2. Elicit a harmful response from the cache server :

Once you have identified an unkeyed input, the next step is to evaluate exactly how the website processes it. If an input is reflected in the response from the server without being properly sanitized, or is used to dynamically generate other data, then this is a potential entry point for web cache poisoning.

In the provided screenshot, it's evident that the HTTP response is being manipulated to include a malicious value from the X-Forwarded-Host header.

What is X-Forwarded-Host header ?

The X-Forwarded-Host (XFH) header is a de-facto standard header for identifying the original host requested by the client in the host request header.

Host names and ports of reverse proxies (load balancers, CDN's) may differ from the origin server handling the request, in that case the X-Forwarded-Host header is useful to determine which Host was originally used.

3. Ensuring the Poisoned Response is Cached :

Manipulating inputs to elicit a harmful response is half the battle, but it doesn't achieve much unless you can cause the response to be cached, which can sometimes be tricky.

The final step is to ensure that the manipulated response is stored in the cache. Whether or not a response gets cached can depend on all kinds of factors, such as the file extension, content type, route, status code, and response headers. You will probably need to devote some time to simply playing around with requests on different pages and studying how the cache behaves. Once you work out how to get a response cached that contains your malicious input, you are ready to deliver the exploit to potential victims.

In our case, we can determine if our malicious response is being cached just by checking the Age header in the response.

What is Age header ?

The Age header contains the time in seconds the object was in a proxy cache.

The Age header is usually close to zero. If it is Age: 0, it was probably fetched from the origin server; otherwise, it was usually calculated as a difference between the proxy's current date and the date general header included in the HTTP response.

What is the impact of a web cache poisoning attack ?

The impact of web cache poisoning is heavily dependent on two key factors :

• What exactly the attacker can successfully get cached

As the poisoned cache is more a means of distribution than a standalone attack, the impact of web cache poisoning is inextricably linked to how harmful the injected payload is. As with most kinds of attack, web cache poisoning can also be used in combination with other attacks to escalate the potential impact even further.

• The amount of traffic on the affected page

The poisoned response will only be served to users who visit the affected page while the cache is poisoned. As a result, the impact can range from non-existent to massive depending on whether the page is popular or not. If an attacker managed to poison a cached response on the home page of a major website, for example, the attack could affect thousands of users without any subsequent interaction from the attacker.

How to prevent web cache poisoning vulnerabilities ?

The definitive way to prevent web cache poisoning would clearly be to disable caching altogether. While for many websites this might not be a realistic option, in other cases, it might be feasible. For example, if you only use caching because it was switched on by default when you adopted a CDN, it might be worth evaluating whether the default caching options really do reflect your needs.

Specifically in the context of web cache poisoning, this not only means deciding whether to leave caching switched on by default, but also looking at which headers are supported by your CDN, for example. Several of the web cache poisoning vulnerabilities discussed above are exposed because an attacker is able to manipulate a series of obscure request headers, many of which are entirely unnecessary for the website's functionality. Again, you may be exposing yourself to these kinds of attacks without realizing, purely because you have implemented some technology that supports these unkeyed inputs by default. If a header isn't needed for the site to work, then it should be disabled.

You should also take the following precautions when implementing caching:

• If you are considering excluding something from the cache key for performance reasons, rewrite the request instead.

• Don't accept fat GET requests. Be aware that some third-party technologies may permit this by default.

• Patch client-side vulnerabilities even if they seem unexploitable. Some of these vulnerabilities might actually be exploitable due to unpredictable quirks in your cache's behavior. It could be a matter of time before someone finds a quirk, whether it be cache-based or otherwise, that makes this vulnerability exploitable.

Web Cache Deception : A Stealthy Intruder

The Anatomy of Web Cache Deception :

Web Cache Deception exploits a loophole in how web caches interpret and serve requests for dynamic content. Typically, web caches differentiate between static and dynamic content based on URL patterns. Static resources, such as images and CSS files, are cached with longer expiration times, while dynamic content, such as personalized pages or data-driven responses, is served fresh for each request.

The attack unfolds when an adversary manipulates the URL structure to deceive the cache into caching dynamic content. By appending a cacheable URL path to a dynamic URL, the attacker tricks the cache into storing the dynamic response under a static URL. Subsequent requests to the manipulated URL result in the cache serving cached content, potentially exposing sensitive information to unauthorized users.

Let us consider having an application which is user specific and non-cached, and contains a profile section (https://www.example.com/my_profile).

And the attacker lures the victim to open the malicious crafted link (https://www.example.com/my_profile/test.css), where the file “test.css” does not exist on the web server.

Since it is a non-existent file, the application ignores the “test.css” part of the URL and loads the victim’s profile page. Also, the caching mechanism identifies the resource as a style sheet, and caches it.

Then the attacker sends a GET request to the cached page (https://www.example.com/my_profile/test.css), and the victim profile page will be returned.

An anecdote :

Usually websites don't require authentication to access their public static files. Therefore, the cached files are publicly-accessible – no authentication required.

Conditions :

So basically, following conditions are required for this vulnerability to exist

• When https://www.example.com/my_profile/test.css is requested, the content of https://www.example.com/my_profile should be returned as the response.

• The web caching functionality is configured to cache files based on their extensions.

• And the victim must be authenticated while accessing the maliciously crafted URL.

Other things to test :

• example.com/my_profile/.js

• example.com/my_profile/.css

• example.com/my_profile/test.js

• example.com/my_profile/../test.js

• example.com/my_profile/%2e%2e/test.js

Mitigation Strategies :

Web cache deception is easier to exploit and hence it belongs to the group of the most critical vulnerabilities.

The best part is that there are plenty of ways to implement security in the sensitive content of the website from being cached and from getting revealed to the unauthorized users.

The following are the most opted mitigation methodologies :

1. Note that the cache proxy should be configured to cache files based on the extension of the file (.css) and not base on the content-type. In the example https://www.example.com/my_profile/non-existent.css will have a text/html content-type instead of a text/css mime type (which is the expected for a .css file).

2. Configure the cache mechanism to cache files only if their HTTP caching headers allow. That will solve the root cause of this issue.

3. Configure the web server so that for pages such as https://www.example.com/my_profile/non-existent.css, the web server doesn’t return the content of "my_profile" with this URL. Instead, for example, the server should respond with a 404 or 302 response.

In Conclusion

Web Cache Poisoning and Web Cache Deception are two important concepts that every web developer should be familiar with. By understanding the differences between these two types of attacks and implementing the necessary security measures, you can help ensure that your web application is secure and protected against these types of attacks.

Thanks for reading, and happy hacking!