Author (developer) controls
The main ActionScript API used to grant security privileges is the Security.allowDomain() method, which grant privileges to SWF files in the domains that you specify. In the following example, a SWF file grants access to SWF files served from the www.example.com domain:
Security.allowDomain("www.example.com")
This method grants permissions for the following:
■
■
■
■
Cross-scripting between SWF files (see “Cross-scripting” on page 470 )
Display list access (see “Traversing the display list” on page 473 )
Event detection (see “Event security” on page 473 )
Full access to properties and methods of the Stage object (see “Stage security” on page 472 )
The primary purpose of calling the Security.allowDomain() method is to grant permission for SWF files in an outside domain to script the SWF file calling the
Security.allowDomain() method. For more information, see “Cross-scripting” on page 470 .
Specifying an IP address as a parameter to the Security.allowDomain() method does not permit access by all parties that originate at the specified IP address. Instead, it permits access only by a party that contains the specified IP address as its URL, rather than a domain name that maps to that IP address. For example, if the domain name www.example.com maps to the IP address 192.0.34.166, a call to Security.allowDomain("192.0.34.166") does not grant access to www.example.com.
You can pass the "*" wildcard to the Security.allowDomain() method to allow access from all domains. Because it grants permission for SWF files from all domains to script the calling
SWF file, use the "*" wildcard with care.
ActionScript includes a second permission API, called Security.allowInsecureDomain() .
This method does the same thing as the Security.allowDomain() method, except that, when called from a SWF file served by a secure HTTPS connection, it additionally permits access to the calling SWF file by other SWF files that are served from an insecure protocol, such as HTTP. However, it is not a good security practice to allow scripting between files from a secure protocol (HTTPS) and those from insecure protocols (such as HTTP); doing so can open secure content to snooping and spoofing attacks. Here is how such attacks can work: since the Security.allowInsecureDomain() method allows access to your secure HTTPS data by SWF files served over HTTP connections, an attacker interposed between your
HTTP server and your users could replace your HTTP SWF file with one of their own, which can then access your HTTPS data.
460 Flash Player Security
Another important security-related method is the Security.loadPolicyFile() method, which causes Flash Player to check for a cross-domain policy file at a nonstandard location.
For more information, see “Website controls (cross-domain policy files)” on page 456 .
Security sandboxes
Client computers can obtain individual SWF files from a number of sources, such as from external websites or from a local file system. Flash Player individually assigns SWF files and other resources, such as shared objects, bitmaps, sounds, videos, and data files, to security sandboxes based on their origin when they are loaded into Flash Player. The following sections describe the rules, enforced by Flash Player, that govern what a SWF file within a given sandbox can access.
For more information on security sandboxes, see the Flash Player 9 Security white paper.
Remote sandboxes
Flash Player classifies assets (including SWF files) from the Internet in separate sandboxes that correspond to their website origin domains. By default, these files are authorized to access any resources from their own server. Remote SWF files can be allowed to access additional data from other domains by explicit website and author permissions, such as cross-domain policy files and the Security.allowDomain() method. For details, see “Website controls (crossdomain policy files)” on page 456 and “Author (developer) controls” on page 460 .
Remote SWF files cannot load any local files or resources.
For more information, see the Flash Player 9 Security white paper.
Security sandboxes 461
Local sandboxes
Local file describes any file that is referenced by using the file: protocol or a Universal
Naming Convention (UNC) path. Local SWF files are placed into one of three local sandboxes:
■
■
■
The local-with-filesystem sandbox—For security purposes, Flash Player places all local
SWF files and assets in the local-with-file-system sandbox, by default. From this sandbox,
SWF files can read local files (by using the URLLoader class, for example), but they cannot communicate with the network in any way. This assures the user that local data cannot be leaked out to the network or otherwise inappropriately shared.
The local-with-networking sandbox—When compiling a SWF file, you can specify that it has network access when run as a local file (see “Setting the sandbox type of local SWF files” on page 463 ).These files are placed in the local-with-networking sandbox. SWF files that are assigned to the local-with-networking sandbox forfeit their local file access. In return, the SWF files are allowed to access data from the network. However, a local-withnetworking SWF file is still not allowed to read any network-derived data unless permissions are present for that action, through a cross-domain policy file or a call to the
Security.allowDomain() method. In order to grant such permission, a cross-domain policy file must grant permission to all domains by using <allow-access-from domain="*"/> or by using Security.allowDomain("*") . For more information, see
“Website controls (cross-domain policy files)” on page 456 and “Author (developer) controls” on page 460 .
The local-trusted sandbox—Local SWF files that are registered as trusted (by users or by installer programs) are placed in the local-trusted sandbox. System administrators and users also have the ability to reassign (move) a local SWF file to or from the local-trusted sandbox based on security considerations (see “Administrative user controls” on page 452 and “User controls” on page 454 ). SWF files that are assigned to the local-trusted sandbox can interact with any other SWF files and can load data from anywhere (remote or local).
Communication between the local-with-networking and local-with-filesystem sandboxes, as well as communication between the local-with-filesystem and remote sandboxes, is strictly forbidden. Permission to allow such communication cannot be granted by a Flash application or by a user or administrator.
Scripting in either direction between local HTML files and local SWF files—for example, using the ExternalInterface class—requires that both the HTML file and SWF file involved be in the local-trusted sandbox. This is because the local security models for browsers differ from the Flash Player local security model.
462 Flash Player Security
