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.
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
Some interesting questions have been raised regarding sandboxing in AIR, and whether the AIR Application sandbox is “weaker” than the equivalent browser sandbox.
On the face of this, this seems like a reasonable assumption to make. Simply adding system access to a browser sandbox would indeed be much scarier, but that is not what happened. In fact, AIR Application sandbox is significantly different from a browser sandbox insofar that many high-risk APIs have been disabled or severely restricted, making it far more difficult to attack such applications. So the AIR sandbox is not weaker than a browser sandbox; it is different, and in many respects stronger.
We just shipped Adobe AIR 1.0, check it out at http://www.adobe.com/products/air!
AIR lets web developers–whether HTML/AJAX, Flex or Flash–build rich and complex applications that run on the desktop. From a security standpoint, the “desktop” part of that is the key.
If you come from a web development background, you find that desktop applications differ significantly security-wise from apps based in the web browser. Desktop applications have direct access to the local system (insofar that the operating system permits, of course), but in return they must be explicitly installed by the user or system administrator.
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?
I haven’t posted anything for a bit, as we’ve been very busy in the kitchen! We have a new Beta of AIR available, just in time for MAX. Check it out at http://labs.adobe.com/technologies/air/
My focus for this AIR beta has been HTML security. In AIR, you can build applications in just Flash, or HTML, or a combination of the two. The unique challenges of current design and implementation patterns in AJAX make HTML an especially interesting platform for desktop applications from a security perspective.
If you haven’t gotten your personal dose of AIR yet, check it out at http://labs.adobe.com/technologies/air/
The install experience for an AIR application has been the subject of much effort internally, and many questions externally. One of the common questions revolves around the relatively “scary” nature of the installation dialogs.
One of the goals of the installation experience is to accurately communicate to the user the potential risk of installing AIR applications in general. An AIR application is a fully privileged local application, with similar powers and risks to a native application–including full filesystem read/write access. As such, the danger is that developers, IT administrators, or users could assume that AIR applications are somehow intrinsically “safer” to install since they are based upon web technologies.
One way a developer can improve the installation experience for the user is to sign the AIR installer file with a commercial code signing certificate. To see the difference in the installation experience for such an application, check out the “Employee Directory” sample AIR application here: http://labs.adobe.com/technologies/air/samples/
In the future there may also be more restrictive sandbox types that provide a “safer” type of AIR application, with a corresponding installation experience to encourage developers to develop applications with the minimum level of necessary privilege.
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.