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 "AIR"
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.
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.
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.