New Cache Key Injection Technique Bypasses Web Security Defenses
A novel web cache poisoning method, cache key injection, allows attackers to manipulate web server caching mechanisms to serve restricted data or inject malicious content without user interaction.
Researchers have uncovered a sophisticated web cache poisoning technique dubbed 'cache key injection' that circumvents traditional security measures by exploiting how web servers like Nginx construct cache keys. Unlike prior methods that often focused on unkeyed HTTP request values, this new approach targets values already incorporated into a cache key, manipulating their combination to create collisions.
Web caches are designed to enhance performance by storing responses to frequently requested resources. When a subsequent request generates an identical cache key, the cached response is served, reducing server load. However, the research by Alex Brumen demonstrates that if a web server, such as Nginx, concatenates various components of an HTTP request—like the scheme, host, URI, query string, cookies, or headers—without clear delimiters, different requests can inadvertently produce the same cache key.
A common Nginx configuration might define a cache key as $scheme$host$request_uri$http_accept. If the components are joined directly, a legitimate request for /home with an Accept: / header could generate the same cache key as an attacker's crafted request for /h with an Accept: ome*/* header. This collision allows an attacker to store a malicious or sensitive response under a key that will later be served to legitimate users requesting different, but colliding, URIs.
One significant impact demonstrated is the potential to access restricted endpoints, such as an administrative dashboard typically accessible only from localhost. By manipulating a request to collide with the cache key for the /admin page, an external attacker could trick the server into serving the cached administrative response, bypassing access controls. This technique enables a form of web cache deception that does not rely on users clicking malicious links.
Furthermore, the cache key injection method can lead to Cache Poisoned Denial-of-Service (CPDoS) attacks. An attacker could request a non-existent resource, like /h, while crafting a header that causes its cache key to match that of a legitimate resource, such as /home. If the attacker's request results in a cached 404 error response, subsequent legitimate requests for /home will receive this poisoned error until the cache is cleared or expires.
The research also highlights a critical vulnerability involving HTTP and HTTPS scheme confusion. If a cache key begins with $scheme$host$request_uri, an attacker could exploit this by sending an HTTP request to a malicious host (e.g., s-dummywebsite.localhost) while a legitimate HTTPS request targets dummywebsite.localhost. If the backend server reflects the Host header within script sources, the poisoned cached page could load JavaScript from the attacker's domain, leading to stored cross-site scripting (XSS).
Even when services like Cloudflare are used, this attack remains a threat. Attackers can use headers like Authorization to bypass Cloudflare's edge cache, forwarding the request to the origin Nginx server. If the origin server caches the response, it can be directly targeted. A poisoned entry cached by Nginx could then be served to users, especially if the Cloudflare edge cache entry expires or is not present.
The primary mitigation involves redesigning cache key configurations to use clear delimiters or structured encoding, such as $scheme|$host|$request_uri|$http_accept, instead of direct concatenation. Organizations should also avoid caching authenticated or access-controlled responses, strictly validate Host headers, enforce HTTPS, and ensure consistent caching behavior between CDN and origin layers. This research underscores that including request values in cache keys is insufficient for security if not properly delimited, turning a performance feature into a significant risk.