- The external operation used to access the resource (i.e., Loader.load(), Sound.load(), etc.)
- The security domain (or security sandbox) of the SWF file performing the request
- The location of the resource
- The explicit access-permissions set for the resource as determined by either the resource's creator (i.e., the developer that compiles the SWF) or distributor (i.e., usually a web site administrator or socket server administrator)
- Creator permission means a SWF file contains the appropriate call to the Security class's static method allowDomain() or to allowInsecureDomain()
- Distributor permission means the resource distributor has made the appropriate cross-domain policy file available
- The explicit access-permissions granted by the user (e.g., permission to connect to the user's camera or microphone)
- The type of Flash Player running the SWF file (e.g., plug-in version, standalone version, Flash authoring tool test version)
- To simplify the testing of local content that is intended for web deployment, Adobe's Flex Builder automatically grants trust to projects under development.
- To test your application as your end user will see it, be sure to run it in its target environment.
What's Security Sandbox?
Much of Flash Player security is based on the region of origin from which the SWF file was opened or loaded. A SWF file from a specific Internet domain, such as www.example.com, can always access all data from that domain. These assets are put in the same security grouping, known as a security sandbox(or security domain). The following basic security rules always apply by default:
- Resources in the same security sandbox can always access each other.
- SWF files in a remote sandbox can never access local files and data.
Based on security restrictions, the following are four of the most-often blocked external operations:
- Loading content
- Loading content means retrieving any external resource to subsequently display or play it.
- Accessing content as data
- Accessing content as data means reading the internal information of a content resource. For example, reading the pixels of a bitmap.
- Cross-scripting means accessing a loaded SWF file programmatically.
- Loading data
- The term "loading data" could be used to describe a wide variety of Flash Player load operations, including downloading files from a server via the FileReference class's instance method download(), loading binary data over a Socket object, and so on.
The specific method used to load the resource (not the file type of the resouorce) makes an external operation either a loading-data operation or a loading-content operation. For example, loading a SWF file using URLLoader's load() method is considered a loading-data operation; loading that same SWF file using Loader's load() method is considered a loading-content operation.
In the following table, it illustrates the approved and prohibited external operations in a remote sandbox.
|Operation||Resources in Local Domain||Remote Domain Resources from SWF's Region of Origin||Remote Domain Resources Outside SWF's Region of Origins|
|Accessing Content as Data||Prohibited||Allowed||Allowed by distributor permission only|
|Cross-scripting||Prohibited||Allowed||Allowed by creator permission only|
|Loading Data||Prohibited||Allowed||Allowed by distributor permission only|
For similar restriction rules applied to other sandbox types, see "Chapter 19--Flash Player Security Restrictions" in the Book "Essential ActionScript 3.0."
Flex assigns a security status known as a secuirty-sandbox-type to every SWF file opened by or loaded into Flash Player. To check a SWF file's security-sandbox-type at runtime, you can retrieve the value of the flash.system.Secuirty.sandboxType variable from within that SWF file (note that this property is only supported in Flash Player 8 or later). There are five possbile security-sandbox-types:
- remote(i.e., Security.REMOTE)
- Remote means the loaded SWF is from an Internet URL.
- local-with-filesystem(i.e., Security.LOCAL_WITH_FILE)
- Local-with-filesystem means the loaded SWF file is from local file system and was compiled with -use-network compiler flag set to be false.
- local-with-networking(i.e., Security.LOCAL_WITH_NETWORK)
- Local-with-networking means the loaded SWF file is from local file system and was compiled with -use-network compiler flag set to be true.
- local-trusted(i.e., Security.LOCAL_TRUSTED)
- Local-trusted means SWF file was opened from a trusted local location
- To verify which locations are trusted on a given computer,consult
- the trust files in the User Flash Player Trust directory (e.g. C:\Documents and Settings\JohnD\Application Data\Macromedia\Flash Player\#Security\FlashPlayerTrust on Windows XP)
- the Global Flash Player Trust directory(e.g., c:\WINNT\system32\Macromed\Flash\FlashPlayerTrust on Windows)
- the online Flash Player Settings Manager
- application(i.e., Security.APPLICATION)
- This SWF file is running in an AIR application, and it was installed with the package (AIR file) for that application.
Air Security Model
Being a desktop application runtime, the AIR security model is significantly different from the web browser security model. The application sandbox (i.e., assets that exist in the application directory ) in AIR provides direct access to privileged AIR specific system APIs. In return for access to these powerful APIs, some common dangerous APIs and patterns are restricted. For example, dynamic importing of remote content is generally prohibited and dynamic code generation techniques (e.g., using eval() and similar APIs to generate code at runtime) are heavily restricted. Only content loaded directly from the application home directory (via the app:/ URI scheme) can be placed in the application sandbox.
By default, files in the AIR application sandbox can cross-script any file from any domain (although files outside of the AIR application sandbox may not be permitted to cross-script the AIR file). By default, files in the AIR application sandbox can load content and data from any domain.
In the following table, it illustrates the approved and prohibited external operations in an application sandbox.
|Operation||Resources in the Application Sandbox||Non-SWF Resources in the Non-Application Sandbox||SWF Resources in the Non-Application Sandbox|
|Accessing Content as Data||Allowed||Allowed||Allowed|
|Cross-Scripting||Allowed||n/a||SWF files in the application sandbox can cross-script SWF files in the non-application sandbox although SWF files from the non-application sandbox may not be permitted to cross-script SWF files in the application sandbox.|
Air applications that write to the local file system are advised to write to app-storage:/. This directory exists separately from the application files on the user's computer, hence the files are not assigned to the application sandbox and present a reduced security risk. Developers are advised to consider the following:
- Include a file in an AIR file (in the installed application) only if it is necessary.
- Include a scripting file in an AIR file (in the installed application) only if its behavior is fully understood and trusted.
- Do not write to or modify content in the application directory. The AIR runtime prevents applications from writing or modifying files and directories using the app:/ URL scheme by throwing a SecurityError exception.
Besides application sandbox, non-application sandbox contains all other content that is not loaded directly into the application sandbox. This includes local and remote content. Content loaded from outside the application observes the same security rules as content loaded in a web browser. For example, such content cannot call AIR APIs that provide access to the local file system.