On Web Cache Deception Attacks: What is that, and how to repel them?
Recently, web masters and IT security specialists have started being concerned about data exfiltration method called a "Web Cache Deception Attack." Such attack spoils web caching functionality and makes sensitive information vulnerable. Caching is widely used to shorten load time for web servers that receive content requests and in content delivery networks. Such attack shows how caching feature can be misused to acquire content not intended for caching.
When a hacker performs a Web Cache Deception Attack, he sends a request so that the web caching service including CDN, reverse proxy, load balancer, etc. interpreted the request differently than the origin server would. Then the attacker initiates caching of content that is usually not cached. Many servers would process the request for a non-existent object, which is widely used on ticketing systems. The attackers add a structure ending with .jpg, .css or other format of cacheable files to the URL of a non-cached page so that it was cached. An important point of this attack is that there should be a user initiating the first request, and then the attacker would follow the same URL to access the cached contents.
But this is not the only complication after a Web Cache Deception Attack. If cached response contains session IDs, CSRF tokens, or security answers, hacker can get full control over the account. He would be able to interact with system like a legitimate account owner.
1. Apps and scripts that won’t receive arguments in the URI after being located should use a redirect back to an URL they will handle, or serve 302 or 404 response.
2. Ensure that caching services follow caching requirements of the origin. Sometimes Edge-control header is used to force caching behavior.
3. Disable feature that cause confusion about file extension between proxy server and the origin server. Although Web Cache Deception Attacks are not as widespread as DDoS attacks, they can become more common than we expect. Deploy a safe CDN solution and don’t hesitate to ask your provider about security options provided.
When a hacker performs a Web Cache Deception Attack, he sends a request so that the web caching service including CDN, reverse proxy, load balancer, etc. interpreted the request differently than the origin server would. Then the attacker initiates caching of content that is usually not cached. Many servers would process the request for a non-existent object, which is widely used on ticketing systems. The attackers add a structure ending with .jpg, .css or other format of cacheable files to the URL of a non-cached page so that it was cached. An important point of this attack is that there should be a user initiating the first request, and then the attacker would follow the same URL to access the cached contents.
But this is not the only complication after a Web Cache Deception Attack. If cached response contains session IDs, CSRF tokens, or security answers, hacker can get full control over the account. He would be able to interact with system like a legitimate account owner.
How to prevent such attacks?
Web Cache Deception Attacks can be performed against any web cache where the origin server and cache has some disagreement towards cache ability. Log analysis rarely helps to detect vulnerability. Since website and caching configurations vary from site to site, there is no versatile solution that will work for all projects equally good. Every solution should be tested for efficiency and security given personal web configuration. Here are some suggestions:1. Apps and scripts that won’t receive arguments in the URI after being located should use a redirect back to an URL they will handle, or serve 302 or 404 response.
2. Ensure that caching services follow caching requirements of the origin. Sometimes Edge-control header is used to force caching behavior.
3. Disable feature that cause confusion about file extension between proxy server and the origin server. Although Web Cache Deception Attacks are not as widespread as DDoS attacks, they can become more common than we expect. Deploy a safe CDN solution and don’t hesitate to ask your provider about security options provided.
