What is cache poisoning?

In this article, We will learn about cache poisoning.

Cache poisoning is a type of attack that involves manipulating the content stored in a web cache to serve malicious or unauthorized content to users.

Web caches are used to improve website performance by storing copies of web pages or resources (such as images, CSS files, or JavaScript) closer to the user, reducing the load on the web server and speeding up subsequent requests.

In a cache poisoning attack, an attacker injects malicious or unauthorized content into the cache, which is then served to unsuspecting users. This can lead to various security risks and potential exploits, such as:

Content manipulation: By poisoning the cache, an attacker can modify the content displayed to users.

For example, they can inject malicious scripts or misleading information into cached pages, leading to phishing attacks or spreading malware.

Session hijacking: If the cache stores authenticated session data, an attacker can hijack a user’s session by injecting a crafted session ID into the cache. This enables the attacker to impersonate the user and perform unauthorized actions.

Cache poisoning chain attacks: Attackers can target intermediate systems, such as load balancers or reverse proxies, which act as caches themselves. By poisoning these intermediate caches, the attacker can compromise a large number of users who rely on them.

Web cache poisoning attacks often exploit vulnerabilities in the caching infrastructure or misconfigurations in the caching mechanisms.

For example, if a web cache does not properly validate the content it receives from the origin server, it may cache malicious or unauthorized responses. Similarly, if the cache does not properly distinguish between different users’ requests, it can serve one user’s private data to another user.

How does cache poisoning work?

A web cache is a mechanism used to store copies of web pages or resources temporarily, allowing subsequent requests for those resources to be served faster. The cache is typically located closer to the user, either on the user’s device (browser cache) or on intermediary servers (such as proxy servers or content delivery networks).

Here’s a general overview of how a web cache works:

User requests a web page: When a user enters a URL or clicks on a link to access a web page, their web browser sends a request to the web server hosting the page.

Checking the cache: Before forwarding the request to the web server, the browser or an intermediary server checks if the requested resource is already present in the cache. It does this by comparing the requested URL or resource identifier with the stored cache entries.

Cache hit: If the requested resource is found in the cache and is still valid (not expired), the cache serves the resource directly to the user, bypassing the need to contact the web server. This improves the response time and reduces the load on the server.

Cache miss: If the requested resource is not found in the cache or is expired, it is considered a cache miss. In this case, the cache forwards the request to the web server, retrieves the resource, and stores a copy in the cache for future use.

Serving the response: The web server returns the requested resource to the cache, which in turn delivers it to the user’s browser. The cache also updates its stored copy of the resource with the new version received from the server.

Cache expiration and validation: Each cached resource has an associated expiration time or validation mechanism. When a resource’s expiration time is reached or a validation condition is met, the cache considers the resource stale. Subsequent requests for the resource will result in cache misses, and the cache will fetch a fresh copy from the server.

Web caches operate based on the principle of caching commonly accessed resources to improve performance and reduce network traffic. They are especially effective for static content that doesn’t change frequently, such as images, stylesheets, or JavaScript files. However, caching dynamic content requires additional considerations to ensure data accuracy and freshness.

Web cache management can be controlled through HTTP headers like “Cache-Control” and “Expires,” which dictate caching behavior, expiration times, and cache validation mechanisms.

Impact of cache poisoning?

Web cache poisoning can result in the delivery of unauthorized or malicious content to users, compromising their security. It can lead to financial losses, reputation damage, compromised user sessions, and operational disruptions. Trust in the affected organization may be lost, impacting its brand image and customer base.

Prevent cache poisoning

To prevent web cache poisoning vulnerabilities: regularly update and patch caching systems, properly validate and sanitize user input, implement secure cache configurations, use secure coding practices, employ web application firewalls (WAFs) to detect and block malicious requests, and conduct security testing and assessments.

For example, it is possible to inject an HTTP 404 (Not Found) error page in place of some page ( storefront home page), which can lead to a potential denial-of-service (DoS). The malicious page URLs are cached by Varnish or Redis, hence the name page cache poisoning.

These types of attacks can be difficult to detect because they do not result in errors in web server logs.

Varnish Cache In Magento 2 (Adobe Commerce)

Please check above link to know more about varnish cache.

Description

The issue results if URL rewrites are enabled on the IIS server, and any of the following HTTP headers are altered before the request reaches the Varnish or Redis caching service:

• X-Rewrite-Url
• X-Original-Url
• IIS-wasurlrewritten
• Unencoded-URL
• Orig-path-info

If these headers are changed, the resulting URL and content are cached, resulting in potential vulnerabilities.

How to forbid the X-Original-URL and X-Rewrite-URL headers

The X-Original-URL and X-Rewrite-URL headers let users override the path in the request URL using the X-Original-URL or X-Rewrite-URL HTTP request header and allows a user to access one URL but have web application return a different URL, which can bypass restrictions on higher level caches and web servers.

Resolution

• Log in to the Online Store node using SSH.
• Modify the 0ssl.conf file:
  vim /etc/httpd/conf.d/0ssl.conf
• Add the following lines to the <VirtualHost *:443> section:
  RequestHeader unset X-Original-URL
RequestHeader unset X-Rewrite-URL
• Save the changes.
• Restart the httpd service:
  service httpd restart

IIS-wasurlrewritten

URL rewriting’s purpose is to change the appearance of the URL to a more user-friendly URL.

Unencoded-URL

URL encoding is a mechanism for translating unprintable or special characters to a universally accepted format by web servers and browsers.

Orig-path-info

ORIG_PATH_INFO is the PATH_INFO as it was in the original request before any rewriting or other manipulation was done to the string.

You can get more articles on Caching in Magento2 here.

Hope this will help you.

Thanks 🙂