State of Security

I have noticed some confusion around the different cross-domain loading mechanisms in Flash Player. Its a complex topic, so I figured I'd put together a 90 second primer on the differences.

To wit, there are essentially four types of cross-domain loading mechanisms:

Cross-domain data loading

Data loading means you are actually importing data from another site... in other words, your code has access to the actual bits. This includes operations such as loading XML files, accessing the bits of an image or sound file, importing code into your sandbox, connecting via a socket, etc. In this scenario any content loaded is imported into the loader's sandbox.

Cross-domain data loading is governed by cross-domain policy files, commonly known as "crossdomain.xml". Crossdomain.xml allows a server to specify other domains from which SWFs are permitted to load cross-domain data from it.

Cross-domain data loading is something that is generally not directly possible in browsers today, since they don't provide a mechanism to express cross-domain loading permissions like crossdomain.xml. The only significant exception to this is cross-domain script importing (i.e. SCRIPT SRC=). Why is universal cross-domain script importing ok, but no other cross-domain loading data mechanism? I have no idea, someone back in the day decided that it was ok.

Cross-domain content loading

This is the concept of loading cross-domain content in a hands-off fashion. For example, you can currently load and display images & play other SWFs and sound files cross-domain. This does not require any cross-domain permissions.

So how is this different from cross-domain data loading? Its a hands-off loading operation, which means the loadee content in question can be displayed to the user, but the code that loaded it has no access to its bits. So you can't script into it or inspect its bits because it remains in its original context.

This model is the same in the browser... you can load images or iframes across domains, but you cannot inspect them or script into them.

Cross-domain SWF->SWF or HTML->SWF scripting

A SWF can specify other domains from which SWFs or HTML are permitted to script into it. Scripting is not governed in any way by crossdomain.xml.

It requires calling an ActionScript API: System.security.allowDomain()

Cross-domain SWF->HTML scripting

SWF to HTML scripting is governed by the allowScriptAccess OBJECT/EMBED parameter. It defaults to "sameDomain" which means that SWF is only allowed to script into the surrounding HTML content and browser when it comes from the same domain as the HTML hosting it.

Posted by Lucas Adamski at 09:58 PM | Permalink | Comments (1)

Some concerns have been raised lately regarding malicious ads using Flash. The good news is there are already mechanisms in the Flash Player to effectively address these concerns.

I am simplifying here, but there are two main goals for web-based advertisements:
* advertisers want to present compelling, engaging advertisements
* advertisers want users to click through to their websites

For the sake of simplicity, lets assume that the SWF-based ad and HTML-based container are hosted in separate domains, and that you have control over the HTML container.

At this point a short review of the potential threats posed by an advertisement is in order. An ad might try to:

1) Automatically redirect the user to another site

2) Redirect the user to another site after clicking on it

3) Automatically open a new window to another site

4) Open a new window to another site after clicking on it

5) Automatically install a malicious program

For each one of the above threats, here are the available mitigations respectively:

1) and 2) Set the allowScriptAccess="never" parameter of the OBJECT/EMBED HTML tag to prevent SWF content from controlling existing browser content, including preventing redirects of existing content

3) The Flash Player uses the browser's existing pop-up blocker logic to prohibit pop-ups triggered from Flash, assuming the browser's pop-up blocker is enabled

4) This is normal behavior for an ad. Much like HTML/JavaScript, if the user clicks on a link to go to certain website, generally this action is permitted (though it can depend on how aggressively your pop-up blocker is configured). Furthermore, the hosting HTML could even prohibit this entirely by setting the allowNetworking="none" or allowNetworking="internal" OBJECT/EMBED parameters, though this will prevent users from clicking-through advertisements altogether, and so is generally not the desired effect

5) Flash Player does not permit automatic downloads; any downloads require user involvement and consent

To an advertiser or hosting website, this all may seem rather complicated, but in fact it boils down to one straightforward change assuming you want to have ads that:
- disable any redirects or automatic opening of new windows
- allow a user to click-through the ad to open in a new window

Just set the allowScriptAccess="never" parameter on your OBJECT/EMBED tags.

One caveat: this does not prevent an ad from opening a window to a potentially malicious website if a user clicks on it. There is no technical mitigation to that problem, as its impossible to tell whether the website the user is about to visit is malicious or not. So there will always be a degree of responsibility the publisher of the ad needs to accept for ensuring that they only accept content from trustworthy partners.

If you instead want to have ads that prohibit any browser or network interaction, even if the user clicks on them, you can set the allowNetworking="none" parameter instead.

Keep in mind that it is possible to include potentially malicious JavaScript in the OBJECT/EMBED parameters themselves. While not an issue with Flash Player itself, you need to be careful when validating any HTML tags or parameters for undesirable code.

Like any change, you should thoroughly test any such modifications to ensure your content will still work. For example, the recommended solution above requires ads to open new windows, rather than redirecting the existing window.

References: please see my previous blog entry about controlling SWF content from HTML.

Posted by Lucas Adamski at 11:04 AM | Permalink | Comments (0)