Sandboxes
AIR provides a comprehensive security architecture that defines permissions accordingly to each file in an AIR application, both internal and external. Permissions are granted to files according to their origin, and are assigned into logical security groupings called sandboxes.
- About the AIR application sandboxes
- The application sandbox
- Privileges of content in non-application sandboxes
About the AIR application sandboxes
The AIR runtime security model of sandboxes is composed of the Flash Player security model with the addition of the application sandbox. Files that are not in the application sandbox have security restrictions similar to those specified by the Flash Player security model.
The runtime uses these security sandboxes to define the range of data that code may access and the operations it may execute. To maintain local security, the files in each sandbox are isolated from the files of other sandboxes. For example, a SWF file loaded into an AIR application from an external Internet URL is placed into a remote sandbox, and does not by default have permission to script into files that reside in the application directory, which are assigned to the application sandbox.
The following table describes each type of sandbox:
|
Sandbox |
Description |
|---|---|
|
application |
The file resides in the application directory and operates with the full set of AIR privileges |
|
remote |
The file is from an Internet URL, and operates under domain-based sandbox rules analogous to the rules that apply to remote files in Flash Player. (There are separate remote sandboxes for each network domain, such as http://www.example.com and https://foo.example.org.) |
|
local-trusted |
The file is a local file and has the user has designated it as trusted , using either the Settings Manager or a Flash Player trust configuration file. The file can both read from local data sources and communicate with the Internet, but does not have the full set of AIR privileges. |
|
local-with-networking |
The file is a local SWF file published with a networking designation, but has not been explicitly trusted by the user. The file can communicate with the Internet but cannot read from local data sources. This sandbox is only available to SWF content. |
|
local-with-filesystem |
The file is a local scripting file that was not published with a networking designation and has not been explicitly trusted by the user. This includes JavaScript files that have not been trusted. The file can read from local data sources but cannot communicate with the Internet. |
This topic focuses primarily on the application sandbox and its relationship to other sandboxes in the AIR application. Developers that use content assigned to other sandboxes should read further documentation on the Flash Player security model. See the "Flash Player Security" chapter in the Programming ActionScript 3.0 (http://www.adobe.com/go/flashCS3_progAS3_security) documentation and the Adobe Flash Player 9 Security white paper (http://www.adobe.com/go/fp9_0_security).
The application sandbox
When an application is installed, all files included within an AIR installer file are installed onto the user's computer into an application directory. Developers can reference this directory in code through the app:/ URL scheme (see Using AIR URL schemes in URLs). All files within the application directory tree are assigned to the application sandbox when the application is run. Content in the application sandbox is blessed with the full privileges available to an AIR application, including interaction with the local file system.
Many AIR applications use only these locally installed files to run the application. However, AIR applications are not restricted to just the files within the application directory -- they can load any type of file from any source. This includes files local to the user's computer as well as files from available external sources, such as those on a local network or on the Internet. File type has no impact on security restrictions; loaded HTML files have the same security privileges as loaded SWF files from the same source.
Content in the application security sandbox has access to AIR APIs that content in other sandboxes are prevented from using. For example, the NativeApplication.nativeApplication.applicationDescriptor property, which returns the contents of the application descriptor file for the application, is restricted to content in the application security sandbox. Another example of a restricted API is the FileStream class, which contains methods for reading and writing to the local file system.
ActionScript APIs that are only available to content in the application security sandbox are indicated in with the AIR logo in the ActionScript 3.0 Language Reference for Adobe AIR. Using these APIs in other sandboxes causes the runtime to throw a SecurityError exception.
For HTML content (in an HTMLLoader object), all AIR JavaScript APIs (those that are available via the window.runtime property, or via the air object when using the AIRAliases.js file) are available to content in the application security sandbox. HTML content in another sandbox does not have access to the window.runtime property, so this content cannot access the AIR APIs.
JavaScript and HTML restrictions
For HTML content in the application security sandbox, there are limitations on using APIs that can dynamically transform strings into executable code after the code is loaded. This is to prevent the application from inadvertently injecting (and executing) code from non-application sources (such as potentially insecure network domains). An example is the use of the eval() function. For details, see Code restrictions for content in different sandboxes.
Restrictions on img tags in ActionScript text field content
To prevent possible phishing attacks, img tags in HTML content in ActionScript TextField objects are ignored in SWF content in the application security sandbox.
Restrictions on asfunction
Content in the application sandbox cannot use the asfunction protocol in HTML content in ActionScript 2.0 text fields.
No access to the cross-domain persistent cache
SWF content in the application sandbox cannot use the cross-domain cache, a feature that was added to Flash Player 9 Update 3. This feature lets Flash Player persistently cache Adobe platform component content and reuse it in loaded SWF content on demand (eliminating the need to reload the content multiple times).
Privileges of content in non-application sandboxes
Files loaded from a network or Internet location are assigned to the remote sandbox. Files loaded from outside the application directory are assigned to either the local-with-filesystem, local-with-networking, or the local-trusted sandbox; this depends on how the file was created and if the user has explicitly trusted the file through the Flash Player Global Settings Manager. For details, see http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager.html.
JavaScript and HTML restrictions
Unlike content in the application security sandbox, JavaScript content in a non-application security sandbox can call the eval() function to execute dynamically generated code at any time. However, there are restrictions to JavaScript in a non-application security sandbox. These include:
- JavaScript code in a non-application sandbox does not have access to the window.runtime object, and as such this code cannot execute AIR APIs.
- By default, content in a non-application security sandbox cannot use XMLHttpRequest calls to load data from other domains other than the domain calling the request. However, application code can grant non-application content permission to do so by setting an allowcrosscomainxhr attribute in the containing frame or iframe. For more information, see Scripting between content in different domains.
- There are restrictions on calling the JavaScript Window.open() method. For details, see Restrictions on calling the JavaScript Window.open() method.
For details, see Code restrictions for content in different sandboxes.
Restrictions on loading CSS, frame, iframe, and img elements
HTML content in remote (network) security sandboxes can only load CSS, frame, iframe, and img content from remote domains (from network URLs).
HTML content in local-with-filesystem, local-with-networking, or local-trusted sandboxes can only load CSS, frame, iframe, and img content from local sandboxes (not from application or network URLs).