Web Cache Deception

In a web cache deception attack, an attacker persuades a victim to visit a malicious URL, inducing the victim's browser to make an ambiguous request for sensitive content. The cache misinterprets this as a request for a static resource and stores the response. The attacker can then request the same URL to access the cached response, gaining unauthorized access to private information.

Cache Keys: Subset of the request's components to determine whether there is a cached response. Unkeyed: Components of the request that are not included in the cache key.

Steps:

  • Identify a target endpoint that returns a dynamic response containing sensitive information (GET, HEAD, or OPTIONS methods)

  • Identify a discrepancy in how the cache and origin server parse the URL path.

    • Try delimiter

    • Try static extansion

    • Try directory traversal encoding from static dir to dynamic (encode /)

    • Try directory traversal encoding from dynamic to static dir (encode all) + delimeter

    • Try common filename cached

    In all steps note if caching.

  • Craft a malicious URL that uses the discrepancy to trick the cache into storing a dynamic response. When the victim accesses the URL, their response is stored in the cache and we can get the response.

Attacks

Exploiting Static Extension Cache Rules

Cache rules often target static resources by matching common file extensions like .css or .js. If there are discrepancies in how the cache and origin server map the URL path to resources or use delimiters, an attacker may be able to craft a request for a dynamic resource with a static extension that is ignored by the origin server but viewed by the cache.

http://example.com/user/123/profile http://example.com/user/123/profile/<IGNORED> http://example.com/user/123/profile/random.js

The cache could interpret it as a static file and store it in the cache.

Caches may have rules based on specific static extensions. Try a range of extensions, including .css, .ico, and .exe.

Try to inject static extension with delimiter discrepancies (turn off Burp Intruder's automated character encoding). ex. ; . %00

http://example.com/user/123/profile<DELIMITER>random.js

Note

Some delimiter characters may be processed by the victim's browser before it forwards the request to the cache. This means that some delimiters can't be used in an exploit. For example, browsers URL-encode characters like {, }, <, and >, and use # to truncate the path. If the cache or origin server decodes these characters, it may be possible to use an encoded version in an exploit.

Exploiting Static Directory Cache Rules

It's common practice for web servers to store static resources in specific directories. Cache rules often target these directories by matching specific URL path prefixes, like /static, /assets, /scripts, or /images.

If the origin server resolves encoded dot-segments, but the cache doesn't

You can attempt to exploit the discrepancy by constructing a payload according to the following structure:

/<static-directory-prefix>/..%2f<dynamic-path>

For example, consider the payload /assets/..%2fprofile:

  • The cache interprets the path as: /assets/..%2fprofile

  • The origin server interprets the path as: /profile

The origin server returns the dynamic profile information, which is stored in the cache.

If the cache server resolves encoded dot-segments but the origin server doesn't

You can attempt to exploit the discrepancy by constructing a payload according to the following structure:

/<dynamic-path>%2f%2e%2e%2f<static-directory-prefix>

In this situation, path traversal alone isn't sufficient for an exploit. You'll need to also identify a delimiter that is used by the origin server but not the cache. For example, consider the payload/profile;%2f%2e%2e%2fstatic:

  • The cache interprets the path as: /static

  • The origin server interprets the path as: /profile

Exploiting file name cache rules

Certain files such as robots.txt, index.html, and favicon.ico are common files found on web servers. They're often cached due to their infrequent changes. Cache rules target these files by matching the exact file name string.

Because the response is only cached if the request matches the exact file name, you can only exploit a discrepancy where the cache server resolves encoded dot-segments, but the origin server doesn't. Use the same method as for static directory cache rules - simply replace the static directory prefix with the file name.

Last updated

Was this helpful?