[Update: this may be a false alarm. See how I resolved the problem.]
I've been looking for a way to work around the security hole in the flash persistence mechanism that I described in the previous post.
Since the hole occurs when one site hotlinks a Flash movie on another site, it seemed to me that the obvious solution would be to prevent hotlinking. So I set up a .htaccess file using the Apache mod_rewrite module and the HTTP_REFERER header. It worked: offsite links to the SWF file were prevented.
But this wasn't good enough. I didn't take caching into account. Suppose user has just visisted Site A, and that site uses a scriptable Flash movie to store persistent data locally. The user then visits Site B, which is the malicious one. Site B hotlnks the movie on Site A and scripts it to gain read access to the persistent data. My .htaccess file on the server was supposed to prevent this kind of hotlinking. But the server never gets involved: Site B doesn't need to ask the Site A server to send it the movie: the movie is already in the browser's cache, and Site B can read Site A's persistent data with no trouble.
Anyone have a solution to this problem? I'm ready to give up and declare that Flash-based persistence is only good as a cache for information that is already publically available on the network.
And as a meandering aside, let me say that there are some interesting uses of it there. I gather that XMLHttpRequest bypasses the browser cache, at least in certain browsers. Flash persistence could be used to create a persistent cache for XMLHttpRequest. This might be useful for a web site that had a bunch of pages that all did XSLT using the same stylesheet, which was retrieved with XMLHttpRequest.
Adam Vandenberg has an XMLHttpRequest caching solution but the cache only persists for the lifetime of the current page. Flash persistence might be an interesting addition to his caching code. (Of course, we'd have to confirm that this Flash security hole only gives read access to the cached data; otherwise any website could corrupt the Flash cache of any other.)
I know nothing about Flash. Can you access cookies? If so, I would assume site B (the malicious site) can't access site A's cookies, even though it can access site A's flash movie and data store.
If this is the case, you could store a private key in a cookie (or even reuse the session ID), and use the key to sign an encrypt all of your data.
Bob,
Thanks for this. It sounds like it would work. Implementing encryption in JavaScript would be the stumbling block, though...
Hi David; I tried to recreate this security issue myself and can not replicate it. Here's what I did and what I got.
What I did:
1) I created two fake domain names on my box by editing my /etc/hosts file: I added alice.com and bob.com, both set to resolve to the local host (127.0.0.1)
2) I startup a local webserver
3) I took my testing file from AMASS, test.html, and created two versions: bob.html and alice.html.
4) Alice is the "good" user, while Bob is the "evil" one trying to intercept a key. alice.html has the normal AMASS testing code, loading up a local version of the storage.swf Flash file and storing the key "alicesMessage" with a value. bob.html is the same, but loads up bob_storage.js, a modified version of the storage JavaScript that dynamically creates the Flash object tag to grab the storage file from http://alice.com/dev/storage/storage.swf rather than locally
What I got:
On Windows in both Firefox and IE, I opened two windows. In one I went to http://alice.com/dev/storage/alice.html, while in the other one I went to http://bob.com/dev/storage/bob.html. In Alices window I used the key "alicesMessage" and stored a value. I then went to Bob's window and tried to load the "alicesMessage" key; in both browsers I got exceptions that prevented me from doing so.
My results seem to show that there is no security exception. Perhaps there is a difference between our tests?
Sorry, that should say that my results show there is no security issue.
I'm not sure if this is desired, but as a last resort, you might want to try to prevent caching of the SWF file in the first place by using the header
Cache-Control: no-cache
This of course means that every access to that SWF file will require downloading it from the server again, but it will solve the security flaw.
Regarding the cookies suggestion made by Bob Lee, you might be able to get away by storing a hash of the data in the cookies, and only serve the data if the hash is matching the data. Then, you can use a simple hashing algorithm, instead of implementing a full encryption library in JavaScript.
This might be problematic if an intruder will try to go over all possible hash codes to break into the data, but if the number of possible hash keys is large enough, this will make it almost unfeasible in a web browser.