[Update: this may be a false alarm. See how I resolved the problem.]
Inspired by Brad Neuberg's AMASS project, I've been experimenting with using the Flash plugin as a client-side persistence mechanism, as an alternative to cookies. It allows the storage of much more data, and that data doesn't have to be uploaded to the server for every webpage that uses it. This seems important, and projects like AMASS seem like they have breakthrough potential.
However, I've discovered something I'm worried about. Persistence in Flash is done with the SharedObject class. By default persistent data is not shared among Flash movies: it is only accessible to the movie that stored it. SharedObject has a way to loosen this up, like the path attribute of a cookie. You can specify that all Flash movies in the same directory can share persistent data, for example. Or you can specify that all Flash movies from the same website can share data.
This may be fine when the data is locked inside the Flash movies. But when Flash movies are scriptable, we run into problems. Both AMASS and my own experiments with Flash-based persistence use a simple invisible movie to make the necessary calls to the SharedObject. Both script the Flash plugin with JavaScript so that we can persist client-side JavaScript data.
And this is where the problems arise. Flash governs access to the data based on the URL of the movie; it doesn't seem to care about the URL of the document within which the movie is embedded. Suppose, therefore, that Site A uses a scriptable Flash movie to persistently store some data from JavaScript. Site B can hotlink that scriptable movie right off of Site A, and the JavaScript code on Site B can read the data stored by the JavaScript code on Site A. (In my experiments, Site B cannot overwrite or delete the data stored by Site A, but it can read it.)
My testing was done using Firefox 1.0.6 using the Linux version of the Flash player 7.0 r25.
Update:I have now obtained the same results using Firefox 1.02 and Flash version 8 on a Windows machine.
I think this is a problem. I suspect that it is a big problem and that Macromedia needs to fix it. I'm only beginning to dabble in Flash and just learning about how to script Flash movies. I don't know if this security problem will affect movies that use SharedObject but do not explicitly open themselves up to scripting of that SharedObject. It could be that if you play a Flash-based game at Site C, site D could figure out a way to read your high score in that game.
Your thoughts are welcome in the comments, especially if you understand Flash and Flash scripting better than I do!
Hi David, I'm not sure I pulled out the right question here, but I think it's "Can a webpage which hotlinks my SWF access its local shared-objects data?" If so, it shouldn't, because of the domain mismatch -- one way to *make* it happen would be if your SWF explicitly allows the hijacking domain to share its data, but I don't think you'd have set that up in your example files.
Are you using Macromedia Flash Player 8, or a previous release? Have you checked out Deneb's summary of the Flash 8 security mechanisms?
http://www.macromedia.com/devnet/flash/articles/fplayer8_security.html
jd/mm
John,
Thanks for writing; it's nice to have help from the source.
I think, however, that you miss my point. There is no domain mismatch because the SWF is being hotlinked, not copied: it is still being served by its original domain. It is now embedded in a web page on a different server, and is being scripted by JavaScript from a different server.
From my experiments, it appears that SharedObject only cares about the domain of the SWF file, not of the HTML file within which it is embedded and from which it is scripted.
I would like a way for the ActionScript code in the SWF to compare the domain that it comes from to the domain in which it is embedded, so that it can refuse to respond to cross-domain scripting. But I can't find a way to do that.
Sorry, you're right, I am trying to get the single-sentence question out of these three weblog entries and the discussion at my blog... I'm not sure yet how your subsequent paragraphs differ from my attempt. :(
I see that your third paragraph seems to move directly towards "How can my SWF know the URL of the invoking HTML page?", but I'm still not sure if you're ever seeing any data transfer from a hotlinked SWF, nor how to describe such a setup to the folks on the Macromedia security team...?
John,
I don't know that I've got a single-sentence question for you. I believe I've found a security flaw with SharedObject, when it is exposed to scripting via JavaScript. If you want a single-sentence question, try: "Is this security flaw as serious as it seems to me?"
A secondary question is, as you noted, "how can my swf know the url of the invoking HTML page". If this is knowable, the security hole can be plugged by disallowing cross-domain scripting.
I'd be happy to provide example code demonstrating them problem to the Macromedia security team if you can put me in touch with them.