Packageflash.system
Classpublic final class Security
InheritanceSecurity Inheritance Object

Language Version : ActionScript 3.0
Player Version : Flash Player 9

The Security class lets you specify how SWF files in different domains can communicate with each other.

View the examples



Public Properties
 PropertyDefined By
 Inheritedconstructor : Object
A reference to the class object or constructor function for a given object instance.
Object
  exactSettings : Boolean
[static] Determines how Flash Player chooses the domain to use for certain Flash Player settings, including settings for camera and microphone permissions, storage quotas, and storage of persistent shared objects.
Security
 Inheritedprototype : Object
[static] A reference to the prototype object of a class or function object.
Object
  sandboxType : String
[static] [read-only] Indicates the type of security sandbox in which the calling SWF file is operating.
Security
Public Methods
 MethodDefined By
  
allowDomain(... domains):void
[static] Lets SWF files and HTML files in the identified domains access objects and variables in the SWF file that contains the allowDomain() call.
Security
  
[static] Lets SWF files and HTML files in the identified domains access objects and variables in the calling SWF file, which is hosted by means of the HTTPS protocol.
Security
 Inherited
Indicates whether an object has a specified property defined.
Object
 Inherited
Indicates whether an instance of the Object class is in the prototype chain of the object specified as the parameter.
Object
  
[static] Loads a cross-domain policy file from a location specified by the url parameter.
Security
 Inherited
Indicates whether the specified property exists and is enumerable.
Object
 Inherited
Sets the availability of a dynamic property for loop operations.
Object
  
showSettings(panel:String = "default"):void
[static] Displays the Security Settings panel in Flash Player.
Security
 Inherited
Returns the string representation of the specified object.
Object
 Inherited
Returns the primitive value of the specified object.
Object
Public Constants
 ConstantDefined By
  LOCAL_TRUSTED : String = "localTrusted"
[static] The SWF file is a local file and has been trusted by the user, using either the Settings Manager or a FlashPlayerTrust configuration file.
Security
  LOCAL_WITH_FILE : String = "localWithFile"
[static] The SWF file is a local file, has not been trusted by the user, and was not published with a networking designation.
Security
  LOCAL_WITH_NETWORK : String = "localWithNetwork"
[static] The SWF file is a local file, has not been trusted by the user, and was published with a networking designation.
Security
  REMOTE : String = "remote"
[static] The SWF file is from an Internet URL and operates under domain-based sandbox rules.
Security
Property Detail
exactSettingsproperty
exactSettings:Boolean  [read-write]

Language Version : ActionScript 3.0
Player Version : Flash Player 9

Determines how Flash Player chooses the domain to use for certain Flash Player settings, including settings for camera and microphone permissions, storage quotas, and storage of persistent shared objects. You may set exactSettings to false in order to have the SWF file use the same settings that were used in Flash Player 6.

In Flash Player 6, the domain used for these player settings was based on the trailing portion of the domain of the SWF file. If the domain of a SWF file includes more than two segments, such as www.example.com, the first segment of the domain ("www") is removed, and the remaining portion of the domain is used: example.com. So, in Flash Player 6, www.example.com and store.example.com both use example.com as the domain for these settings. Similarly, www.example.co.uk and store.example.co.uk both use example.co.uk as the domain for these settings. In Flash Player 7 and later, player settings are chosen by default according to a SWF file's exact domain; for example, a SWF file from www.example.com would use the player settings for www.example.com, and a SWF file from store.example.com would use the separate player settings for store.example.com.

When Security.exactSettings is set to true, Flash Player uses exact domains for player settings. When it is set to false, the Flash Player uses domain settings used in Flash Player 6. The default value for exactSettings is false. If you change exactSettings from its default value, you must do so before any events occur that require Flash Player to choose player settings — for example, using a camera or microphone, or retrieving a persistent shared object.

If you previously published a version 6 SWF file and created persistent shared objects from it, and you now need to retrieve those persistent shared objects from that SWF file after porting it to version 7 or later, or from a different SWF file of version 7 or later, you must set Security.exactSettings to false before calling SharedObject.getLocal().


Implementation
    public static function get exactSettings():Boolean
    public function set exactSettings(value:Boolean):void

Throws
SecurityError — Flash Player already used the value of exactSettings at least once in a decision about player settings.
sandboxTypeproperty 
sandboxType:String  [read-only]

Language Version : ActionScript 3.0
Player Version : Flash Player 9

Indicates the type of security sandbox in which the calling SWF file is operating.

Security.sandboxType has one of the following values:

A SWF file of any version may use this property, but is only supported in Flash Player 8 or later. Thus you can examine this property, for example, from a version 7 SWF file playing in Flash Player 8. This all-versions support means that, if you publish for a version earlier than 8, you will not know at publish time whether this property will be supported at playback time. Thus, in a SWF file of version 7 or earlier, this property has an undefined value; that should happen only when the player version (indicated by flash.system.Capabilities.version) is earlier than 8. In that situation, you can determine the sandbox type according to whether the SWF file is a local file or not. If it is a local file, Flash Player will classify the SWF file as localTrusted. (Before Flash Player 8, this was how all local content was treated.) If it is not a local file, Flash Player will classify the SWF file as remote.

For more information, see the following:


Implementation
    public static function get sandboxType():String

See also

Method Detail
allowDomain()method
public static function allowDomain(... domains):void

Language Version : ActionScript 3.0
Player Version : Flash Player 9

Lets SWF files and HTML files in the identified domains access objects and variables in the SWF file that contains the allowDomain() call.

If two SWF files are served from the same domain — for example, http://mysite.com/swfA.swf and http://mysite.com/swfB.swf — then swfA.swf can examine and modify variables, objects, properties, methods, and so on in swfB.swf, and swfB.swf can do the same for swfA.swf. This is called cross-movie scripting or cross-scripting.

If two SWF files are served from different domains — for example, http://siteA.com/swfA.swf and http://siteB.com/siteB.swf — then, by default, Flash Player does not allow swfA.swf to script swfB.swf, nor swfB.swf to script swfA.swf. A SWF file gives SWF files from other domains by calling Security.allowDomain(). This is called cross-domain scripting. By calling Security.allowDomain("siteA.com"), siteB.swf gives siteA.swf permission to script it.

In any cross-domain situation, it is important to be clear about the two parties involved. For the purposes of this discussion, the side performing the cross-scripting is called the accessing party (usually the accessing SWF), and the other side is called the party being accessed (usually the SWF being accessed). When siteA.swf scripts siteB.swf, siteA.swf is the accessing party, and siteB.swf is the party being accessed.

Cross-domain permissions that are established with allowDomain() are asymmetrical. In the previous example, siteA.swf can script siteB.swf, but siteB.swf cannot script siteA.swf, because siteA.swf has not called allowDomain() to give SWF files at siteB.com permission to script it. You can set up symmetrical permissions by having both SWF files call allowDomain().

In addition to protecting SWF files from cross-domain scripting originated by other SWF files, Flash Player protects SWF files from cross-domain scripting originated by HTML files. HTML-to-SWF scripting can occur with older Flash browser functions such as SetVariable or callbacks established through ExternalInterface.addCallback(). When HTML-to-SWF scripting crosses domains, the SWF file being accessed must call allowDomain(), just as when the accessing party is a SWF file, or the operation will fail.

Specifying an IP address as a parameter to allowDomain() 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 it its URL, rather than a domain name that maps to that IP address.

Version-specific differences

Flash Player's cross-domain security rules have evolved from version to version. The following table summarizes the differences.

Latest SWF version involved in cross-scriptingallowDomain() needed?allowInsecureDomain() needed?Which SWF must call allowDomain() or allowInsecureDomain()?What can be specified in allowDomain() or allowInsecureDomain()?
5 or earlierNoNoN/AN/A
6Yes, if superdomains don't matchNoThe SWF file being accessed, or any SWF file with the same superdomain as the SWF file being accessed
  • Text-based domain (mysite.com)
  • IP address (192.168.1.1)
7Yes, if domains don't match exactlyYes, if performing HTTP-to-HTTPS access (even if domains match exactly)The SWF file being accessed, or any SWF file with exactly the same domain as the SWF file being accessed
  • Text-based domain (mysite.com)
  • IP address (192.168.1.1)
8 or laterYes, if domains don't match exactlyYes, if performing HTTP-to-HTTPS access (even if domains match exactly)SWF being accessed
  • Text-based domain (mysite.com)
  • IP address (192.168.1.1)
  • Wildcard (*)

The versions that control the behavior of Flash Player are SWF versions (the published version of a SWF file), not the version of Flash Player itself. For example, when Flash Player 8 is playing a SWF file published for version 7, it applies behavior that is consistent with version 7. This practice ensures that player upgrades do not change the behavior of Security.allowDomain() in deployed SWF files.

The version column in the previous table shows the latest SWF version involved in a cross-scripting operation. Flash Player determines its behavior according to either the accessing SWF file's version or the version of the SWF file that is being accessed, whichever is later.

The following paragraphs provide more detail about Flash Player security changes involving Security.allowDomain().

Version 5. There are no cross-domain scripting restrictions.

Version 6. Cross-domain scripting security is introduced. By default, Flash Player forbids cross-domain scripting; Security.allowDomain() can permit it. To determine whether two files are in the same domain, Flash Player uses each file's superdomain, which is the exact host name from the file's URL, minus the first segment, down to a minimum of two segments. For example, the superdomain of www.mysite.com is mysite.com. SWF files from www.mysite.com and store.mysite.com to script each other without a call to Security.allowDomain().

Version 7. Superdomain matching is changed to exact domain matching. Two files are permitted to script each other only if the host names in their URLs are identical; otherwise, a call to Security.allowDomain() is required. By default, files loaded from non-HTTPS URLs are no longer permitted to script files loaded from HTTPS URLs, even if the files are loaded from exactly the same domain. This restriction helps protect HTTPS files, because a non-HTTPS file is vulnerable to modification during download, and a maliciously modified non-HTTPS file could corrupt an HTTPS file, which is otherwise immune to such tampering. Security.allowInsecureDomain() is introduced to allow HTTPS SWF files that are being accessed to voluntarily disable this restriction, but the use of Security.allowInsecureDomain() is discouraged.

Version 8. There are two major areas of change:

Occasionally, you may encounter the following situation: You load a child SWF file from a different domain and want to allow the child SWF file to script the parent SWF file, but you don't know the final domain of the child SWF file. This can happen, for example, when you use load-balancing redirects or third-party servers.

In this situation, you can use the url property of the URLRequest object that you pass to Loader.load(). For example, if you load a child SWF file into a parent SWF, you can access the contentLoaderInfo property of the Loader object for the parent SWF:

Security.allowDomain(loader.contentLoaderInfo.url)

Make sure that you wait until the child SWF file begins loading to get the correct value of the url property. To determine when the child SWF has begun loading, use the progress event.

The opposite situation can also occur; that is, you might create a child SWF file that wants to allow its parent to script it, but doesn't know what the domain of its parent will be. In this situation, you can access the loaderInfo property of the display object that is the SWF's root object. In the child SWF, call Security.allowDomain( this.root.loaderInfo.loaderURL). You don't have to wait for the parent SWF file to load; the parent will already be loaded by the time the child loads.

If you are publishing for Flash Player 8 or later, you can also handle these situations by calling Security.allowDomain("*"). However, this can sometimes be a dangerous shortcut, because it allows the calling SWF file to be accessed by any other SWF file from any domain. It is usually safer to use the _url property.

For more information, see the following:

Parameters

... domains — One or more strings or URLRequest objects that name the domains from which you want to allow access. You can specify the special domain "*" to allow access from all domains.

Specifying "*" is the only way to allow access to nonlocal SWF files from local SWF files that have been published using Access Network Only for the Local Playback Security option in the Flash authoring tool.

See also

allowInsecureDomain()method 
public static function allowInsecureDomain(... domains):void

Language Version : ActionScript 3.0
Player Version : Flash Player 9

Lets SWF files and HTML files in the identified domains access objects and variables in the calling SWF file, which is hosted by means of the HTTPS protocol. This method is not recommended; see "Security considerations," later in this entry.

This method works in the same way as Security.allowDomain(), but it also permits operations in which the accessing party is loaded with a non-HTTPS protocol, and the party being accessed is loaded with HTTPS. In Flash Player 7 and later, non-HTTPS files are not allowed to script HTTPS files. The allowInsecureDomain() method lifts this restriction when the HTTPS SWF file being accessed uses it.

Use allowInsecureDomain() only to enable scripting from non-HTTPS files to HTTPS files. Use it to enable scripting when the accessing non-HTTPS file and the HTTPS file being accessed are served from the same domain, for example, if a SWF file at http://mysite.com wants to script a SWF file at https://mysite.com. Do not use this method to enable scripting between non-HTTPS files, between HTTPS files, or from HTTPS files to non-HTTPS files. For those situations, use allowDomain() instead.

Security considerations: Flash Player provides allowInsecureDomain() to maximize flexibility, but calling this method is not recommended. Serving a file over HTTPS provides several protections for you and your users, and calling allowInsecureDomain weakens one of those protections. The following scenario illustrates how allowInsecureDomain() can compromise security, if it is not used with careful consideration.

Note that the following information is only one possible scenario, designed to help you understand allowInsecureDomain() through a real-world example of cross-scripting. It does not cover all issues with security architecture and should be used for background information only. The Flash Player Developer Center contains extensive information on Flash Player and security. For more information, see http://www.adobe.com/devnet/security/.

Suppose you are building an e-commerce site that consists of two components: a catalog, which does not need to be secure, because it contains only public information; and a shopping cart/checkout component, which must be secure to protect users' financial and personal information. Suppose you are considering serving the catalog from http://mysite.com/catalog.swf and the cart from https://mysite.com/cart.swf. One requirement for your site is that a third party should not be able to steal your users' credit card numbers by taking advantage of a weakness in your security architecture.

Suppose that a middle-party attacker intervenes between your server and your users, attempting to steal the credit card numbers that your users enter into your shopping cart application. A middle party might, for example, be an unscrupulous ISP used by some of your users, or a malicious administrator at a user's workplace — anyone who has the ability to view or alter network packets transmitted over the public Internet between your users and your servers. This situation is not uncommon.

If cart.swf uses HTTPS to transmit credit card information to your servers, then the middle-party attacker can't directly steal this information from network packets, because the HTTPS transmission is encrypted. However, the attacker can use a different technique: altering the contents of one of your SWF files as it is delivered to the user, replacing your SWF file with an altered version that transmits the user's information to a different server, owned by the attacker.

The HTTPS protocol, among other things, prevents this "modification" attack from working, because, in addition to being encrypted, HTTPS transmissions are tamper-resistant. If a middle-party attacker alters a packet, the receiving side detects the alteration and discards the packet. So the attacker in this situation can't alter cart.swf, because it is delivered over HTTPS.

However, suppose that you want to allow buttons in catalog.swf, served over HTTP, to add items to the shopping cart in cart.swf, served over HTTPS. To accomplish this, cart.swf calls allowInsecureDomain(), which allows catalog.swf to script cart.swf. This action has an unintended consequence: Now the attacker can alter catalog.swf as it is initially being downloaded by the user, because catalog.swf is delivered with HTTP and is not tamper-resistant. The attacker's altered catalog.swf can now script cart.swf, because cart.swf contains a call to allowInsecureDomain(). The altered catalog.swf file can use ActionScript to access the variables in cart.swf, thus reading the user's credit card information and other sensitive data. The altered catalog.swf can then send this data to an attacker's server.

Obviously, this implementation is not desired, but you still want to allow cross-scripting between the two SWF files on your site. Here are two possible ways to redesign this hypothetical e-commerce site to avoid allowInsecureDomain():

Web browsers have enforced separation between HTTPS and non-HTTPS files for years, and the scenario described illustrates one good reason for this restriction. Flash Player gives you the ability to work around this security restriction when you absolutely must, but be sure to consider the consequences carefully before doing so.

For more information, see the following:

Parameters

... domains — One or more strings or URLRequest objects that name the domains from which you want to allow access. You can specify the special domain "*" to allow access from all domains.

Specifying "*" is the only way to allow access to nonlocal SWF files from local SWF files that have been published using the Access Network Only option for the Local Playback Security setting (File > Publish Settings > Flash tab) in the Flash authoring tool.

See also

loadPolicyFile()method 
public static function loadPolicyFile(url:String):void

Language Version : ActionScript 3.0
Player Version : Flash Player 9

Loads a cross-domain policy file from a location specified by the url parameter. Flash Player uses policy files to determine whether to permit Flash movies to load data from servers other than their own.

By default, Flash Player looks for policy files in only one location: /crossdomain.xml on the server to which a data-loading request is being made.

With Security.loadPolicyFile(), Flash Player can load policy files from arbitrary locations, as shown in the following example:

  Security.loadPolicyFile("http://www.example.com/sub/dir/pf.xml");
  

This causes Flash Player to retrieve a policy file from the specified URL. Any permissions granted by the policy file at that location will apply to all content at the same level or lower in the virtual directory hierarchy of the server. For example, following the previous code, these lines do not throw an exception:

 import flash.net.*;
  var request:URLRequest = new URLRequest("http://www.example.com/sub/dir/vars.txt");
  var loader:URLLoader = new URLLoader();
  loader.load(request);
  
  var loader2:URLLoader = new URLLoader();
  var request2:URLRequest = new URLRequest("http://www.example.com/sub/dir/deep/vars2.txt");
  loader2.load(request2);
  

However, the following code does throw a security exception:

 import flash.net.*;
  var request3:URLRequest = new URLRequest("http://www.example.com/elsewhere/vars3.txt");
  var loader3:URLLoader = new URLLoader();
  loader3.load(request3);
  

You can use loadPolicyFile() to load any number of policy files. When considering a request that requires a policy file, Flash Player always waits for the completion of any policy file downloads before denying a request. As a final fallback, if no policy file specified with loadPolicyFile() authorizes a request, Flash Player consults the original default location, /crossdomain.xml.

Using the xmlsocket protocol along with a specific port number, lets you retrieve policy files directly from an XMLSocket server, as shown in the following example:

  Security.loadPolicyFile("xmlsocket://foo.com:414");
  

This causes Flash Player to attempt to retrieve a policy file from the specified host and port. Any port can be used, not only ports 1024 and higher. Upon establishing a connection with the specified port, Flash Player transmits <policy-file-request />, terminated by a null byte. An XMLSocket server can be configured to serve both policy files and normal XMLSocket connections over the same port, in which case the server should wait for <policy-file-request /> before transmitting a policy file. A server can also be set up to serve policy files over a separate port from standard connections, in which case it can send a policy file as soon as a connection is established on the dedicated policy file port. The server must send a null byte to terminate a policy file, and may thereafter close the connection; if the server does not close the connection, Flash Player does so upon receiving the terminating null byte.

A policy file served by an XMLSocket server has the same syntax as any other policy file, except that it must also specify the ports to which access is granted. When a policy file comes from a port lower than 1024, it can grant access to any ports; when a policy file comes from port 1024 or higher, it can grant access only to other ports 1024 and higher. The allowed ports are specified in a "to-ports" attribute in the <allow-access-from> tag. Single port numbers, port ranges, and wildcards are all allowed. The following example shows an XMLSocket policy file:

  <cross-domain-policy>
    <allow-access-from domain="*" to-ports="507" />
    <allow-access-from domain="*.foo.com" to-ports="507,516" />
    <allow-access-from domain="*.bar.com" to-ports="516-523" />
    <allow-access-from domain="www.foo.com" to-ports="507,516-523" />
    <allow-access-from domain="www.bar.com" to-ports="*" />
  </cross-domain-policy>
  

A policy file obtained from the old default location—/crossdomain.xml on an HTTP server on port 80—implicitly authorizes access to all ports 1024 and above. There is no way to retrieve a policy file to authorize XMLSocket operations from any other location on an HTTP server; any custom locations for XMLSocket policy files must be on an XMLSocket server.

The ability to connect to ports lower than 1024 can be granted by a policy file loaded with loadPolicyFile() only.

You can prevent a SWF file from using this method by setting the allowNetworking parameter of the the object and embed tags in the HTML page that contains the SWF content.

For more information, see the following:

Parameters

url:String — The URL location of the cross-domain policy file to be loaded.

showSettings()method 
public static function showSettings(panel:String = "default"):void

Language Version : ActionScript 3.0
Player Version : Flash Player 9

Displays the Security Settings panel in Flash Player.

Parameters

panel:String (default = "default") — A value from the SecurityPanel class that specifies which Security Settings panel you want to display. If you omit this parameter, SecurityPanel.DEFAULT is used.

See also

Constant Detail
LOCAL_TRUSTEDConstant
public static const LOCAL_TRUSTED:String = "localTrusted"

Language Version : ActionScript 3.0
Player Version : Flash Player 9

The SWF file is a local file and has been trusted by the user, using either the Settings Manager or a FlashPlayerTrust configuration file. The SWF file can read from local data sources and communicate with the Internet.

See also

LOCAL_WITH_FILEConstant 
public static const LOCAL_WITH_FILE:String = "localWithFile"

Language Version : ActionScript 3.0
Player Version : Flash Player 9

The SWF file is a local file, has not been trusted by the user, and was not published with a networking designation. The SWF file may read from local data sources but may not communicate with the Internet.

See also

LOCAL_WITH_NETWORKConstant 
public static const LOCAL_WITH_NETWORK:String = "localWithNetwork"

Language Version : ActionScript 3.0
Player Version : Flash Player 9

The SWF file is a local file, has not been trusted by the user, and was published with a networking designation. The SWF file can communicate with the Internet but cannot read from local data sources.

See also

REMOTEConstant 
public static const REMOTE:String = "remote"

Language Version : ActionScript 3.0
Player Version : Flash Player 9

The SWF file is from an Internet URL and operates under domain-based sandbox rules.

See also

Examples How to use examples
SecurityExample.as

The following example shows how a click event on a Sprite object can be used to show the Local Storage Settings panel of the Flash Player Settings. An orange box is added to the stage using draw(). In draw(), a click event listener is added named clickHandler(), which responds to click events by directing Flash Player to open its Local Storage Settings panel.
package {
    import flash.display.Sprite;
    import flash.text.TextField;
    import flash.events.*;
    import flash.system.Security;
    import flash.system.SecurityPanel;

    public class SecurityExample extends Sprite {
        private var bgColor:uint = 0xFFCC00;
        private var size:uint = 100;

        public function SecurityExample() {
            draw();
        }

        private function draw():void {
            var child:Sprite = new Sprite();
            child.graphics.beginFill(bgColor);
            child.graphics.drawRect(0, 0, size, size);
            child.graphics.endFill();
            child.buttonMode = true;

            var label:TextField = new TextField();
            label.text = "settings";
            label.selectable = false;
            label.mouseEnabled = false;
            child.addChild(label);

            child.addEventListener(MouseEvent.CLICK, clickHandler);
            addChild(child);
        }

        private function clickHandler(event:MouseEvent):void {
            Security.showSettings(SecurityPanel.LOCAL_STORAGE);
        }
    }
}




 

Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/livecycle/es/sdkHelp/common/langref/flash/system/Security.html