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