Posted April 23, 2009 by senocular
Probably the best practical example of this is Joe user at work under his employer Super Company Inc. At work, Joe has access to his company's intranet as well as the world wide interwebs. On the intranet, Joe finds a company wiki page containing some top secret information that has a link to some related game or movie on harmless.com's website and proceeds to check it out. Turns out harmless.com was not so harmless and decided to use the referrer to load in a bunch of data from that [top secret wiki] page into a site's SWF which then proceeds to upload it to some database on the not-so-harmless.com server. As a client-side, web enabled application that SWF has all the same intranet access that Joe does, and this makes it a tempting attack vector for SWF content developers so long as they can convince someone to view their SWF.
Now, obviously this is not possible today because of restrictions in Flash Player that prevent it from loading cross-domain data in this manner - all regulated through the cross-domain policy files, allowing domains to opt-in to sharing their data to other (or any) domains that might request it from "enabled" client-side applications like Flash Player.
The important part of this attack is that the aggressor is the content developer, not the content viewer. This means that viewers of the content should be allowed to see (or hear) anything they'd otherwise have permission to. Content developers, however, should not. This means restricting the cross-domain data at the ActionScript level, not the rendering level. This is why bitmaps can be loaded and viewed, but the actual pixels of the bitmaps cannot be captured or obtained in any way that would compromise whatever data they contain. Same applies to sound and computeSpectrum. Text is a little different because you can't really display it without getting it in text as code so pretty much all text (e.g. xml) is restricted without permission.
But this also explains why server-based proxies work. As servers, these entities do not share the same privileges as the content viewer. A public server at swfdeveloper.com cannot access Super Company Inc's private intranet. Super Company Inc's intranet is inherently protected from that. A SWF has no way of knowing what's from the public interwebs and what's from the private intranet which is why it has that dependency on cross-domain policy files... or delegating that responsibility to something else like the server at swfdeveloper.com which is in a position where the safety of the intranet is taken care of through another means.
So those are pretty much your options. Have the domain provide a cross-domain policy file providing the SWF with trust, or use a proxy or something similar which places that data in an alternate domain that has expressed trust in the player.