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!

Web caching poisoning was thought to be a theoretical issue until recently when James Kettle published some awesome research. The basics of caching are that data that has already been sent out to other users should simply be stored somewhere instead of regenerating the request.

This creates a tricky problem though; how do we know what is the same? This is done via key and value matches on parts of the request. The idea behind the attack is to confuse the keying to cache something that should not be cached. This article goes into attacking many open source libraries for cache poisoning.

The first issue was GET parameter cloaking. Using a semi-colon (;) to separate out queries (I didn't know this was a thing!?), the cache can get confused and not realize this is a separator. Because of this, the cache will save an item that should NOT be saved.

Using this technique, we can control a usually keyed parameter to be sent back to other users. This vulnerability was found in Bottle, Tornado and Rack because of a parsing bug in parse_qsl for Python. Additionally, Ruby on Rails suffered from the same issue, as well. The remediation is to NOT parse the semi-colon as a separator (this is deprecated anyway).

The next issue was labeled FATGet parameters. Typically, GET parameters are passed in the query string of the URL. However, the HTTP specification allows for GET parameters to be in the body of the request. If the cache uses the URLparameters but the backend uses the body parameters then a difference can be created.

Using this difference, we can save a request in the cache using the GET parameters but get a different response from the body parameters. Now, the cache is poisoned with improper data. This issue was found when NGINX was used with Tornado.

The final issue described is that arbitrary parameters can be injected into the request because they are NOT keyed. Although this is not a vulnerability by itself, using this with the proper gadgets can lead to some interesting affects. For example, adding the _method to a request in Flask could change the request method being used to a user.

Because cache poisoning is becoming more and more accessible, I feel that normally unexploitable XSS (such as in a reflected POST request) should be considered higher impact with this idea in mind. These are some good methods for cache poisoning that are library specific; I wonder what other bugs exist in libraries?