This document describes a web cache deception attack where an attacker can exploit how web servers and caching mechanisms handle requests for non-existent files. Specifically, if a request is made for a page plus a non-existent file extension, like http://www.example.com/account.php/stylesheet.css, some systems will return the content of the page rather than a 404. This allows an authenticated user's private page to be cached and then accessed by an attacker. The document provides examples of frameworks like Django and servers like IIS that can be exploited this way. It also discusses how caching services like Cloudflare have addressed this issue. Mitigations are proposed like only caching files if headers allow it and returning 302/404
27. Conditions
• Web cache functionality is set for the web application to cache static files
based on their extensions, disregarding any caching header.
• When accessing a page like
http://www.example.com/home.php/nonexistent.css, the web server will
return the content of home.php for that URL.
• Victim has to be authenticated while accessing the triggering URL.
28. Why the HELL #1
would a web application react like this?
29. Why the HELL #1
Django:
http://www.sampleapp.com/inbox/
30. Why the HELL #1
Django:
http://www.sampleapp.com/inbox/test.css
urls.py
31. Why the HELL #1
Django:
urls.py
http://www.sampleapp.com/inbox.css
32. Why the HELL #1
Django:
http://www.sampleapp.com/inbox/test.css
urls.py
33. Why the HELL #2
would a caching mechanism react like this?
38. Why the HELL #2
Cloudflare:
• Disqualification phase
‘Edge cache expire TTL’ to the rescue!
39. Why the HELL #2
Cloudflare:
https://blog.cloudflare.com/edge-cache-expire-ttl-easiest-way-to-override/
40. Mitigation
• Only cache files if their HTTP caching headers allow
• Store all static files in a designated directory
• Cache files by their content type
• Don’t accept this! http://www.example.com/home.php/non-existent.css.
Return 302 or 404 instead