Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Caches are used on the web to make the internet faster. However, what if there is a desync between the cache and the website? This attack, known as web cache oisoning, is complicated to find but can cause huge damage when found.

Apache Traffic Server (ATS) is a caching HTTP proxy that is widely used. When a request is sent with a URL fragment, ATS forwards the request without stripping the fragment. Since the cache strips out the fragment for the cache key but forwards this along, this may lead to a desync between the request being made and the cache.

If the proxies behind ATS encode %23 to #, a completely diffrent cache key may be implemented than the actual request made. If the backend normalizes ../ then XSS or Open Directs may even be possible to change the page in action.

To test this at scale, the author wrote a tool to detect unkeyed headers for cache poisoning. While using Github, they noticed that the Content-Type header was vulnerable when using an invalid value. By sending an invalid Content-Type header, the request would not work properly, causing a DoS to the other users.

Gitlab uses GCP and Fastly in order to host static files. Since GCP allows for x-http-method-override by default, setting this header to a different method would cause issues. Even though a 405 error message for POST would not be cached, HEAD and PURGE would get cached, causing some major issues. This technique worked on targets besides Gitlab as well.

Ruby on Rails is commonly deployed with the Rack middleware. The header x-forwarded-scheme changes the scheme of the request with this. By sending http as the value, a 301 redirect would occur to the same location. If this was cached by the CDN, a redirect loop would occur, denying access to the file. This was exploited on HackerOne and Shopify.

The X-forwarded-host additionally caused some issues. Using this, a 301 redirect could be performed on the result of JavaScript files, with this then being cached. Since the JavaScript was being loaded into the page of the user, this turned into a very serious XSS vulnerability.

Another attack involved URL parameters. The author noticed that the cached data, for images, only cached the parameter size. If two size paraemters were passed in, both were included as the cache key, but the server only used the last one. This led to another DoS.

Another attack involved URL parameters. The author noticed that the cached data, for images, only cached the parameter size. If two size paraemters were passed in, both were included as the cache key, but the server only used the last one. This led to another DoS.

For identifying caching issues, the tool Param Miner from Burp Suite is fairly awesome. When looking for results on the caching, the Age, X-Cache and several other headers can be useful for learning how the caching for the system works.

The author has a list of headers that were exploited in this research as well. Identifying Cache Poisoning vulnerabilities seems so hard in practice, since it requires weird quirks of the system. However, scans may sometimes be enough :)