Thoughts About

Flash SharedObject cross-domain trick

After warming up with a few random thoughts, let's get to the real business.

Say you wanted to store persistent data and share it between Flash movies from different domains. That's not possibly because of the Flash security sand box for Shared Objects, right? Not quite. I just happened to come across this when a half a year ago I was trying to solve this issue for an application that needed to work both in online and locally in offline modes. The problem is that while the application is really the same, it cannot use the same shared object because it's running in two different domains (localhost for offline and your server for online mode).

I tried a couple of things to go around this problem, like trying to change the _url property of the movie, but while it's possible to change it, it still doesn't change the persistent shared object location for that movie.

You can also try to load the cached version of the movieclip to go around the problem, but naturally it only works if there is a cached version and often you can't guarantee that.

So I kept testing and finally found a viable solution. The trick is to use a local (persistent) version of a remote shared object. Normally, your offline movie is still limited to access to localhost domain and Flash doesn't allow you to use "/.." as a URI. You are allowed to use a parent directory (..), but not multiple sub-sequent ones in your URI. However, looks like MM engineers missed one check, since you can specify "./.." as the URI and thus be able to access the root directory of the shared object data folder, eg. C:\Documents and Settings\yourUserAccount\Application Data\Macromedia\Flash Player.

Test this:
test_so = SharedObject.getRemote("FCTest", "rtmp:/./..", "/");
test_so.data.value1 = "test1";
trace("test_so " + test_so.data.value1);

And do not try to connect the shared object. Then find out where the player created the file FCTest.sor.

It's certainly a security hole or at least unintended behaviour, though I can't immediately figure out how you could exploit this for harmful purposes. I've tested it both with the stand-alone Flash player and through a browser, and you could happily read and write to the shared object. I also just tested that with the new player (7.0.14) and it still works. Generally, it seems that a locally persistent version of a Remote Shared Object is implemented exactly like a Local Shared Object.

A couple of notes: "rtmp:/" has to be specified in the URI, otherwise it
won't work. It'll write the shared object to the "Flash Player" folder,
which is the parent directory of the domain directories. The last parameter,
"/", has to be specified to make the shared object locally persistent. Since this is a fairly harmless bug, it's unlikely that Macromedia will fix this if no one will tell them, and I doubt that. It's in any case useful for some purposes, so let's just keep it as our little secret :)

And btw, since this is my first Flash post, I just like to state that I'm not a fan of Flash and I don't like too much programming in it. It's just something I've needed to do for awhile. While I've always been saying that the language you are programming in does not really matter, after many years of programming in Java, Delphi and Smalltalk, Flash is just unbelievably frustrating at times :( Though good thing it's not as bad as VB/script.