HTML Security in AIR

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.

Already risky patterns, such as rendering of untrusted content in innerHTML, eval() of remote script & JSON data, and reliance on javascript: URIs, become more dangerous when they intersect with the system privileges inherent in AIR. To address the threats resulting from this model, we have separated application content into two sandboxes.


One sandbox, called the “Application” sandbox, permits direct access to all AIR APIs, but in return restricts certain dangerous practices and APIs such as eval(), and related dynamic script generation techniques at runtime. This means that any code in this sandbox is far less vulnerable to typical web application attacks, such as XSS and related injection and escalation of privilege attacks. This also means that many existing applications and frameworks may not work entirely in this sandbox without modification.The other sandbox, which we are referring to as the “Classic” browser-like sandbox, behaves largely like existing remote content in the browser, allowing you to use all of the dynamic scripting techniques you are used to, but in return without direct access to system AIR APIs.For interaction between the Application and Classic sandboxes, we have the Sandbox Bridge, which is essentially a pass-by-value serialization mechanism for interacting between sandboxes that don’t trust each other.One way to look at this is to think of the Classic sandbox as the typical browser sandbox for web content, while the Application sandbox behaves as the server, doing a lot of the heavy lifting and sensitive operations. As in the web model, content in the Application sandbox should not trust the content in the Classic sandbox, and should not expose any low-level system API’s to it via Sandbox Bridge.If your application relies on existing frameworks or dynamic script generation, there is a very good chance it will need to be updated. If you see the message “Error: Parsing Disallowed”, then AIR is reporting back that you are running eval() or a dynamic script technique in the Application sandbox after loading is complete. If that happens, you need to either modify that code or move part of your application into the Classic sandbox by defining a new frame or iframe with special attributes. See the FAQ below for details on how to migrate your application.In the short run, we expect that initially many apps will be ported to work within the Classic sandbox, then over time migrate most of their code over to the Application sandbox. But many other patterns will emerge over time, and one of our primary goals is to obtain feedback on this model, and iterate in future releases.If you are at MAX in Chicago this year, check out the AIR and Flash Player security talks, as well as the AJAX Security Panel!For full details, please see the following links:HTML security model FAQ: http://labs.adobe.com/wiki/index.php/AIR:HTML_Security_FAQHTML-based sample applications such as Fresh, Bee, Drag’n Share, PeekAgenda, and Podcast Player: http://www.adobe.com/go/air_samplesBuilding an expense tracker on the new Adobe AIR HTML security model: http://www.adobe.com/devnet/air/ajax/articles/expense_tracker.htmlThe security chapter in the developer docs: http://labs.adobe.com/wiki/index.php/AIR:DocumentationFinally, for a general overview of AJAX security concerns, also see: http://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.html

2 Responses to HTML Security in AIR

  1. Mario Vieira says:

    Thanks for your session in Adobe Max Europe. It was very clarifying.About the ExternalInterfaces class, the method addCallback does its job when the swf is in a server, but when it’s local it just doesn’t work…I had researched about it, read your handout session a few times, I had completely allowed scripting access, placed a trust configuration file, cross-domain policies, but nothing…So, I guess I have to ask you; is this a bug? Can you point us towards the right direction?Cheers[Lucas]: Thanks, I’m glad you found the session useful! If you have made the SWF in question a trusted SWF then it should be able to use ExternalInterface, but keep in mind that most browsers (incl. IE and Firefox) restrict or disable JavaScript in local content. So that may be what you are running into. If that is not it, you may have want to check out the Flash Player support section at http://www.adobe.com/support/flashplayer/

  2. Werbeagentur says:

    Great article. many usefully informations, it would be usefully for me. Thanks for share it!Many Gracias from Germany, Harun Isik