The primary function of the application sandbox is to enable interaction between AIR APIs and files in trusted directories. Isolation from code in non-application sandboxes is maintained by disabling the JavaScript parser after initial page load so that code such as eval() throws an exception. Setting innerHTML is permitted, but any script it contains is ignored. This provides broad functionality without exposing AIR APIs directly to externally loaded data.

Developers reference trusted directories within the application sandbox using the app:/ URL scheme. Even some files in the application directory can be placed in a non-application sandbox if they are loaded into a frame or iframe using the AIR sandboxRoot and documentRoot attributes if the frame or iframe. All files included within an AIR installer are automatically installed in app:/ and therefore are part of the application sandbox. When the application runs, these files are given the full set of AIR application privileges, including interaction with the local file system. Content outside app:/ is not part of the application sandbox and is therefore treated the same way as it is in the browser.

AIR APIs provide a secure means to safely bridge an evolved browser security model with a desktop-like security model. The AIR sandbox bridge model enables broader functionality and less risk than is associated with typical browser-based applications.

The primary function of the non-application sandboxes is to limit access to local files and AIR APIs unless permitted by the developer. Content loaded from a network or Internet location is automatically assigned to this sandbox. The non-application sandboxes can use the eval() function, execute code via innerHTML assignments, and so on. Code in non-application sandboxes is bound by a same-origin policy and, by default, cannot do cross-domain data loading via XMLHTTPRequest. However, code in a non-application sandbox cannot directly execute AIR APIs.

Developers are encouraged to write code that runs in the application sandbox, even if some restrictions for this sandbox make it behave a little differently than the browser model.

At their simplest, HTML-based AIR applications that use network content consist of a root user interface (UI) file, the data and files they download, and some application files (in the application sandbox). However, if the external content and some user interface files operate in non-application sandboxes and the application files operate in an application sandbox, how does the non-application sandbox content and application sandbox content interact with each other?

View full size graphic

The AIR solution is the sandbox bridge API, which enables indirect communication between different sandboxes. Developers can craft functions that call AIR APIs and then expose those “mediating” functions on the sandbox bridge. These bridge functions essentially “sit on the bridge” and wait for code in the non-application sandbox to call them.

This architecture accomplishes two goals. First, non-application sandbox content does not have direct access to the AIR APIs and application content is protected from external data which is unknown and potentially malicious. Second, only those APIs that the developer explicitly chooses to expose via the bridge mechanism are exposed.

While the sandbox bridge does not guarantee security, developers hold the keys for reducing risk in how they expose the AIR APIs to untrusted content. Much like a client-server model, the server should never trust the client, and the client should never trust data loaded from third parties. Likewise, developers should not use or trust code loading on the server as that could compromise the server, which in turn has access to the operating system. So for the client-server model in both the browser and in the AIR sandbox bridge, primitive system APIs, like writeFile() and readFile(), should always be protected from attack.

Adobe AIR security is designed with the web application development community in mind. Adobe supports standards and methodologies that help to mitigate security risks. Organizations such as the OpenAjax Alliance are further helping to publicize these best practices:

• Isolate untrusted content in a frame or iframe, as leveraging the same-origin policy makes it difficult for attackers to access the full DOM tree.

• Data loaded to a frame from a different domain should be given a unique JavaScript execution context and DOM tree.

• Do not generate and execute code dynamically.

• Avoid inserting HTML content that is not from a trusted source.

• Use JSON securely.

  AIR provides the mechanisms for developers to follow these best practices and thereby enhance the security of their HTML-based applications. For more information, see http://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.html.

  The developer must explicitly bridge sandboxes.