Flash CS3 Documentation

ActionScript 2.0 Language Reference > ActionScript classes > security (System.security) > allowInsecureDomain (security.allowInsecureDomain method)

allowInsecureDomain (security.allowInsecureDomain method)

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. Adobe does not recommend using this method; see "Security considerations," later in this entry.

This method works in the same way as System.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 Adobe recommends against calling this method. 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: 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 Adobe Developer Center contains extensive information on Flash Player and security. For more information, see http://www.adobe.com/devnet/security/.

Imagine that 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 that 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 hypothetical 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():

• Serve all SWF files in the application over HTTPS. This is by far the simplest and most reliable solution. In the scenario described, you would serve both catalog.swf and cart.swf over HTTPS. You might experience slightly higher bandwidth consumption and server CPU load when switching a file such as catalog.swf from HTTP to HTTPS, and your users might experience slightly longer application load times. You need to experiment with real servers to determine the severity of these effects; usually they are no worse than 10-20% each, and sometimes they are not present at all. You can usually improve results by using HTTPS-accelerating hardware or software on your servers. A major benefit of serving all cooperating SWF files over HTTPS is that you can use an HTTPS URL as the main URL in the user's browser without generating any mixed-content warnings from the browser. Also, the browser's padlock icon becomes visible, providing your users with a common and trusted indicator of security.
• Use HTTPS-to-HTTP scripting, rather than HTTP-to-HTTPS scripting. In the scenario described, you could store the contents of the user's shopping cart in catalog.swf, and have cart.swf manage only the checkout process. At checkout time, cart.swf could retrieve the cart contents from ActionScript variables in catalog.swf. The restriction on HTTP-to-HTTPS scripting is asymmetrical; although an HTTP-delivered catalog.swf file cannot safely be allowed to script an HTTPS-delivered cart.swf file, an HTTPS cart.swf file may script the HTTP catalog.swf file. This approach is more delicate than the all-HTTPS approach; you must be careful not to trust any SWF file delivered over HTTP, because of its vulnerability to tampering. For example, when cart.swf retrieves the ActionScript variable that describes the cart contents, the ActionScript code in cart.swf cannot trust that the value of this variable is in the format that you expect. You must carefully validate that the cart contents do not contain invalid data that might lead cart.swf to take an undesired action. You must also accept the risk that a middle party, by altering catalog.swf, could supply valid but inaccurate data to cart.swf; for example, by placing items in the user's cart. The usual checkout process mitigates this risk somewhat by displaying the cart contents and total cost for final approval by the user, but the risk remains present.

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:

• The Flash Player 9 Security white paper at http://www.adobe.com/go/fp9_0_security
• The Flash Player 8 Security-Related API white paper at http://www.adobe.com/go/fp8_security_apis

Availability: ActionScript 1.0; Flash Player 7

Parameters

domain:String - An exact domain name, such as www.myDomainName.com or store.myDomainName.com. In Flash Player 8, you can pass a wildcard ("*") to System.security.allowInsecureDomain() to allow all domains, including local hosts, access to the calling SWF file. Do not use the wildcard unless you are certain that you want to allow all domains, including local hosts, to access the HTTPS SWF file.

Example

In the following example, you host a math test on a secure domain so that only registered students can access it. You have also developed a number of SWF files that illustrate certain concepts, which you host on an insecure domain. You want students to access the test from the SWF file that contains information about a concept.

// This SWF file is at https://myEducationSite.somewhere.com/mathTest.swf
// Concept files are at http://myEducationSite.somewhere.com
System.security.allowInsecureDomain("myEducationSite.somewhere.com");

See also

allowDomain (security.allowDomain method), exactSettings (System.exactSettings property)

Flash CS3