PDF (492K)

Moving ahead securely



The AIR security model aims for a backwards compatibility with legacy Ajax models while reducing the risk associated with exposing system APIs to data beyond the developer’s control. In the browser client-server model, the browser handles much of the presentation and some dynamic third-party data loading. The server handles most of the sensitive processing and provides OS-like facilities such as storage, cryptography, and so on. By providing two sandboxes that communicate via indirectly exposed functions, Adobe AIR makes it less likely that attackers can access end-user machines and data.

    Leveraging Ajax frameworks

    Because a non-application sandbox is effectively the HTML browser sandbox, Ajax developers should find porting of existing applications and patterns to AIR relatively straightforward. For example, you could take an existing crossword game from the web and insert it entirely into a non-application sandbox frame.

    While Ajax frameworks running in non-application sandboxes should run just as they do in a web browser, some framework versions may not completely work in the application sandbox if they rely on eval() and cross-domain code loading. It largely depends on how much a given framework depends on eval() and similar behaviors, as well as which parts of the framework the developer uses.

    These restrictions do not prevent using eval() with JSON object literals. This allows your application content to work with the JSON JavaScript library. However, application sandbox content is restricted from using overloaded JSON code (with event handlers). For other Ajax frameworks and JavaScript code libraries, check to see if the code in the framework or library works within these restrictions on dynamically generated code. If they do not, you will need to include any content that uses the framework or library in a non-application security sandbox. Adobe maintains a document listing known Ajax framework support for the AIR application sandbox:

    http://www.adobe.com/go/airappsandboxframeworks

    Migrating applications

    What if you want to take that simple crossword game and implement functions like saveGame() and loadGame()? Doing so requires accessing AIR APIs, and you implement the relevant APIs in the application sandbox. Functions and data in the application sandbox are then exposed to the non-application sandbox via a sandbox bridge. At a high level, the process involves the following:

    1. Rename the original root content file to someName.htm.

    2. Create a file named myRoot.htm and include an IFRAME or FRAME that points to someName.htm.

    3. Write functions that call the AIR APIs. It’s safer not to call the APIs directly.

    4. Create a parentSandboxBridge that exposes the application sandbox functionality to the non-application sandbox.

      Communication between the two sandboxes can be two way: parentSandboxBridge and childSandboxBridge enables traversing the bridge in both directions. This gives developers more control over content flow between the application and the application environment.

    A real use case

    Signet (a bookmark manager for del.icio.us users) is an HTML-based AIR application that implements the AIR security model in the following way:

    1. First, SignetRoot.htm was created to contain a frame with id signetFrame and three required attributes that identify available domains.

    2. In SignetRoot.htm, onload calls the SignetBridge.js which contains all the exposed functions.

    3. In SignetBridge.js, the functions are exposed to signetFrame via parentSandboxBridge.

    4. In Signet.js, the exposed functions make direct AIR API calls. For example, writeRscContentPriv calls writeRscContent.

      While the methodology is relatively straightforward, the effect is powerful: remote and local domains are defined for two sandboxes, the bridge is started during onload, and the APIs are indirectly exercised through mediating functions via the bridge API.

      View full size graphic