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.
Posts in Category "Flash"
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
One of my pet rants is on SSL, or specifically the inappropriate use of SSL on large websites. This is hardly a novel problem, yet even Fortune 500 bank websites continue to make this glaring mistake on their homepages.
A common scenario:
You need to log into your bank / credit card / mortgage company. You go to http://www.pickabank.com, and up comes their home page with a typical login panel (“Login:”, “Password:”). The URL is still HTTP but there’s a nice padlock icon next to the “Submit” button, and lots of “Hacker safe” iconography everywhere. Having confidence that the site is truly “safe for hackers”, you enter your information and hit submit. Right?
In response to previous questions regarding FMS security, the reasoning behind the restrictions on interacting with RTMP streams is to protect the content being provided by the server. This is a little different from other data loading operations as RTMP is not directly covered by cross-domain policy files and was not originally intended as an interactive data source (rather than just a hands-off media type).
In theory permitting access to the RTMP stream does not pose security issues so long as the Flash Media Server can reliably specify a preference for who is permitted to interact with the RTMP streams. So don’t be surprised if this restriction is relaxed in the future.
For detailed information regarding protection content served from Flash Media Servers, see http://www.adobe.com/devnet/flashmediaserver/articles/protecting_video_fms.pdf
When you host SWF content inside HTML, you have a few tools at your disposal to control how much privilege that SWF has. If you are hosting SWFs that you created or trust completely, these may be unnecessary, however you may find them useful otherwise.
When specifying container tags (i.e. OBJECT or EMBED), you can optionally provide one of the following two parameters: “allowScriptAccess” and “allowNetworking”. These tags can only be specified within HTML (not from a SWF itself), and apply to that root SWF and any other SWFs the root SWF may load.
Today I’d like to take a shot at summarizing the reasoning behind having cross-domain policy files in Flash Player, and some best practices related to implementing them.
The browser security model normally prevents web content from one domain from accessing data from another domain. This is commonly known as the “same origin policy.” Note that this policy does not prevent the displaying of HTML or media assets cross-domain, such as HTML in an IFRAME or other images, etc. This is also true in Flash Player.
In the realm of security, “trust” is generally defined as “something acting the way you expect it to act.” By that definition, URI schemes (http://en.wikipedia.org/wiki/URI_scheme) have a checkered history at best.
Many developers tend to assume that a URL simply refers to a network data loading protocol, such as HTTP, HTTPS, and FTP. However, it been extended over time to include:
- local file I/O (file:)
- network file I/O (smb:, nfs:)
- local application integration (mailto:, various IM & streaming media schemes)
- local operating system integration (generally very dangerous stuff like shell:, vshelp:, local:)
Flash in particular also supports the asfunction: scheme, which can be used to call local ActionScript functions within your SWF.
If you are building an application that handles URLs, you should be aware of your responsibility to ensure that any URLs that are passed to the application and acted upon–either by having the application loading it directly or by the user clicking on it–are handled appropriately.