Security protection through sandboxes

To mitigate these risks, AIR now provides a comprehensive security architecture that defines permissions for each internal and external file in an AIR application. Permissions are granted to files according to their origin and are assigned to logical security groupings called sandboxes. The runtime uses these sandboxes to define access to data and executable operations:

  • Code in the application sandbox has access to AIR APIs, has a limited ability to generate code dynamically after a page loads, and cannot load content via a script tag.

  • Code in all other sandboxes (referred to as non-application sandboxes) essentially mimics typical browser restrictions and behaviors for local trusted HTML.

The application sandbox

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 non-application sandboxes

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.

The sandbox bridge

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?

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 Ajax and Mashup Security at the OpenAjax Alliance.

    The developer must explicitly bridge sandboxes.

Summary of sandbox privileges

Capability

Application Sandbox

Other (non-application) sandboxes

Direct access to AIR APIs?

Yes

No

Access to application sandbox functions that use AIR APIs via the bridge?

N/A

Yes

Can load remote script such as <script src='http://www.example.com /some_code.js'>?

No

Yes

Can, by default, execute cross-domain requests (XHR)

Yes

No

Supports dynamically loading strings as code after the load event: eval() function, setTimeout('string', milis), javascript: URLs, attribute handlers on elements such as onclick='myClick()') that are inserted via innnerHTML, and so on.

No

Yes

Ajax frameworks will work without any changes?

Some frameworks

Yes