State of Security

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.

Code injection (aka cross-site scripting or XSS), essentially happens because applications fail to validate all data to ensure that no code can be included. Injection happens when code gets turned into data through a variety of different APIs. It can also happen when the developer imports code (such as using the SCRIPT tag for JSON loading) but for some reason assumes that they are only loading data.

What we have done in AIR is to identify those API's and either prohibit or severely restrict their using at application runtime. For example, a partial list of things prohibited in an AIR HTML Application sandbox:

* Calling the eval() function.
* Using innerHTML properties or DOM functions to insert script tags that load a script outside of the application directory.
* Using innerHTML properties or DOM functions to insert script tags that have inline code (rather than loading a script via the src attribute).
* Setting the src attribute for a script tags to load a JavaScript file that is outside of the application directory.
* Using the javascript URL scheme (as in href="javascript:alert('Test')").
* Using the setInterval() or setTimout()method where the first parameter (defining the function to run asynchronously) is a string (to be evaluated) rather than a function name (as in setTimeout('x = 4', 1000)).
* Calling document.write() or document.writeln().

For a more comprehensive treatment of the HTML sandboxes, please see the HTML security section in the Livedocs.

Similar restrictions have been placed on Flash content, however the Flash model is generally more resistant to injection attacks (as there are very few APIs that can turn data into code) so fewer changes were required.

Of course the Application sandbox is not the only sandbox present in AIR. In fact only content originally installed with the application should be placed in the Application sandbox. All other local and remote non-application content is placed into the same equivalent Flash or HTML sandbox that it would be in the browser. Click here for detailed information on sandboxes in AIR.

Posted by Lucas Adamski at 12:13 PM | Permalink | Comments (0)

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.

Adobe requires all applications on Adobe AIR be digitally signed, by either a self-signed or commercial certificate from a trusted Certificate Authority (CA). For the end-user, when an application is signed with a self-signed certificate the installation experience will reflect that the publisher is unknown, giving the user pause as to whether they should continue. So, when developers use a commercial certificate from a trusted Certificate Authority users are more likely to install applications. We’ve worked with trusted Certificate Authorities such as Thawte (www.thawte.com) to make it easy to get a digital certificate for code signing. We’ve also enabled administrators to block applications that do not have a signature that chains to a trusted CA.

In AIR, we provide a consistent installation experience for all of our supported platforms (Windows, OS X and soon to be Linux). This means that the user is always presented with the same installation dialogs regardless of which application they are installing or the particular platform that they are on. For some additional information on the AIR installation experience see my previous blog entry.

Just because AIR applications are bound by the desktop security model, it doesn't mean that you don't have to think about security. On the contrary, desktop applications require as much consideration as web applications. This is something we put an enormous amount of effort into. For example, AIR applications have multiple security sandboxes to allow them to interact safely with content on the web.

For an overview of the Adobe AIR security model, see the AIR Security White Paper which outlines the security model and provides information on the security sandboxes available to Adobe AIR applications. We’ve also put together another white paper which specifically details the enhancements to the HTML security model to enable applications on the desktop.

If you are developer looking at AIR, a great next step would be to check out my introduction to the AIR security model at the Adobe Developer Center.

Posted by Lucas Adamski at 03:48 PM | Permalink | Comments (2)