Defense Against The Dark Art Of Browser Cache Poisoning
A recent PCWorld article by Ellen Messmer on the topic of browser cache-poisoning (as discussed by Mike Kershaw) led me to pondering a "solution" to the problem
"What is the problem?", you ask? To re-state it as simply as possible, when you jump on a public wireless network, anything you do over that network can be - at a minimum - captured and viewed by miscreants intent on prying into your affairs and, perhaps, absconding with some of your secrets. Kershaw's remarks pointed out that these malcontents can also do far worse and actually inject their own data into, say, your web-browsing activities. While such activity has many negative possibilities, Mike focused on one called "cache poisoning".
Whenever you visit a web site, your browser - unless you have specifically configured it not to - will attempt to cache (store) anything it can to help speed up your browsing experience and reduce bandwidth usage. This cache can be "poisoned" by an attacker injecting his/her own content into, say a javascript or css file and modifying the server responses to indicate that your browser should not bother trying to re-get those resources for a very long time. This will have the effect of your browser pulling the content from your local cache the next time it is asked for and will then activate the malicious bits along with the expected payload (so you think nothing is wrong).
Apart from always running with the cache off, you can clear the cache manually after you disconnect from a public access point. Most people will not know how to do the former (or just not want to do it) and - for the latter - I would ask you when was the last time you cleared your cache...at all? If you have cleared it, the reason was probably to fix a problem or clear up a page rendering issue.
My "solution" entails writing a small Windows service or OS X event watcher that:
- keeps a record of all SSIDs you associate to (for remembering choices/settings)
- watches for disassociate or adapter link down events
- automatically - or via a prompt - removes all elements retrieved in the past day (or from the time you associate to the network) on disassociation or link down
I've already built the framework for both the Windows service and an OS X process and plan to post both the code and binaries as soon as I get them tied up in a nice, neat bow. However, I wanted to point out some of the complexities involved while they are fresh on my mind.
Focusing on OS X, the default browser - Safari - stores cached data in a sqlite database in ~/Library/Caches/com.apple.Safari/Cache.db. The schema is very basic and the SQL to remove all elements after a given TIMESTAMP is trivial. But, I would wager that most intrepid readers are not aware that any app that makes use of WebKit will get their own Cache.db. With a browser-to-app tool such as Fluid, this means each created app will have its own cache database (and be vulnerable to the poisoning).
Extending this a bit further, many users will have multiple browsers installed (Chrome, Firefox, Opera, etc). Each has their own method of dealing with web caches, and there really is no way to be confident which ones should be cleared without tracking application usage as well. This is also true on the Windows platform and made even a bit worse by the fact that you can customize where IE and other browsers store their cached data (on almost any platform).
It turns out this is one case where the Windows .NET API trumps OS X/Cocoa in that I can easily watch for WLAN adapter disassociation events and then act upon them. On OS X, it takes a bit more work arrive at the disassociation conclusion, but - once you have the event - the cleaning process code is very similar.
As the article points out:
The few defenses Kershaw suggested were continuously manually clearing the cache, or using private-browser mode. "Who knows how to clear the browser cache in an iPhone?" he asked.
I thought of also adding an option to prompt the user to switch to "private mode" browsing when the program detects association with an unknown or public access point. If you want to know how to clear the Mobile Safari cache, just follow Apple's directions.
I will (hopefully) have some time to finish up a rough beta version of each service and get it out for review. In the interim, I would love to hear thoughts on the approaches and suggestions for new/alternate ones.
