Flash wildcard security domain risk

Question

I've got a question about the risk of using a wildcard as a security domain in the method security.allowDomain with Flash.

Suppose the only thing a Flash application does is show some frames or images in a row, and doesn't have any exciting functionality. The Flash application implements System.security.allowDomain('*'), but the server does not have a cross-domain policy file.

The first image from the allowDomain documentation shows that a malicious SWF can use all the functions of the Flash application with the wildcard security policy. But because this application doesn't have any exciting functionality, this isn't an issue.

Can the malicious SWF steal cookies or other data from the Flash application when no functions are in place to do so? Adobe defines cross-scripting as:

movieA.swf can examine and modify variables, objects, properties, methods, and so on in movieB.swf

Does this mean that the malicious SWF can modify functions to return cookie or execute JavaScript in the security context of the Flash application?

Another resource, this tutorial page, talks about a difference between cross-domain policy files and the allowDomain function:

The trust given to a SWF loaded into the current security domain goes beyond that given through allowDomain. Whereas with allowDomain you're effectively giving a SWF anything you can do, I can do permissions, when loading a SWF into the same security domain, you give them permissions along the lines of I can do anything.

But what confuses me is that the page describes that this difference is non-existent because of the loadBytes method:

It's the difference between anything you can do, I can do and I can do anything. The difference being, there's actually no difference.

So what is the risk with allowDomain('*'), but with no functionality or cross-domain policy file?

Answer 1

The real difference is that allowDomain allows cross domain access at a code level, whereas crossdomain.xml can be thought of as allowing access to static content files.

---

Does this mean that the malicious SWF can modify functions to return cookie or execute JavaScript in the security context of the Flash application?

With allowDomain, only if there are public methods or variables containing this information or allowing this functionality in the SWF.

With crossdomain.xml, exploit like this are available which allows the Same Origin Policy to be bypassed via the unrestrictive Flash domain settings. It is not full access as an attacker can't read cookies directly, but they can use them to retrieve other data if site functionality allows.

i.e. You will be allowing any domain hosting a SWF to make a request to your domain and then retrieve the response. So any information your user can see via their web browser on your domain, an attacker will also be able to retrieve (assuming your user is logged into your site and is browsing the attacker's site using the same browser).

But what confuses me is that the page describes that this difference is non-existent because of the loadBytes method:

What it is saying that if you trust another domain's SWF then this could load another SWF using loadBytes. e.g. Your domain A may trust domain B but not C. If you load a SWF from domain B, that SWF may load something from domain C using loadBytes, therefore defeating your trust model.

Answer 2

As far as I know, it's theorically possible to make your swf do as the attackers pleases.

Injecting code and making it loaded by the current application domain is quite easy since Loader.loaderBytes().

Also, I don't understand why a "simple application" which just "shows image in a row" would need a Security.allowDomain.

Having a crossdomain * policy file, however, is directly and incredibly dangerous, as the attacker can read your cookies or submit requests on the behalf of the user from any domain he posess.

I suggest you to reconsider using a wildcar in Security.allowDomain, and only allow domains you trust.