Client-side persistence with FSO and UserData

You would think it was the browser vendors who tried really hard to get cookie security into browsers - really basic things like domain scope and such. And a really big reason for the 4k limitation is that you won't use cookies to store massive amounts of data. But things like WHATWG DOM Storage, Flash Shared Objects, and Internet Explorer Persistence are really against that whole grain.

One of the things that developers are trained to look out for is properly setting cache headers on their responses in order that sensitive data is not persisted in the browser cache. But my guess is that most developers will use these tools to do precisely that. The problem, however, is that none of these are stored in a location such that they'll be cleared out with the browser cache. So attackers that get access to local machines will move from checking the browser cache for sensitive information, or cookies to get the sensitive information from the server, to getting the sensitive information from these caches.

If you're a developer, and you read this, please protect your users - don't store sensitive information in these caches. Don't get me wrong - protecting the user is also the user's responsibility, but sometimes the things like clearing cache areas are beyond a user's control in shared areas like kiosks or shared machines.

Foundstone has a whitepaper on FSO and IE Persistence - it really doesn't go into too many of the implications (local control of the user machine or shared environments) but it does give an idea how those two technologies work. To find out more about WHATWG DOM storage, a google for Mozilla and SQLite will give you lots of hits.