security (System.security)
Object | +-System.security public class security extends ObjectThe System.security class contains methods that specify how SWF files in different domains can communicate with each other. For more information, see the following:
Availability: ActionScript 1.0; Flash Player 6 Property summary
Properties inherited from class Object
Method summary
Methods inherited from class Object
allowDomain (security.allowDomain method)public static allowDomain(domain1:String) : Void 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/movieA.swf and http://mysite.com/movieB.swf then movieA.swf can examine and modify variables, objects, properties, methods, and so on in movieB.swf, and movieB.swf can do the same for movieA.swf. This is called cross-movie scripting or simply cross-scripting. If two SWF files are served from different domains for example, http://mysite.com/movieA.swf and http://othersite.com/movieB.swf then, by default, Flash Player does not allow movieA.swf to script movieB.swf, nor movieB.swf to script movieA.swf. A SWF file gives SWF files from other domains permission to script it by calling System.security.allowDomain(). This is called cross-domain scripting. By calling System.security.allowDomain("mysite.com"), movieB.swf gives movieA.swf permission to script movieB.swf. In any cross-domain situation, two parties are involved, and it's important to be clear about which side is which. 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). To continue the example, when movieA.swf scripts movieB.swf, movieA.swf is the accessing party, and movieB.swf is the party being accessed.  Cross-domain permissions that are established with System.security.allowDomain() are asymmetrical. In the previous example, movieA.swf can script movieB.swf, but movieB.swf cannot script movieA.swf, because movieA.swf has not called System.security.allowDomain() to give othersite.com permission to script movieA.swf. You can set up symmetrical permissions by having both SWF files call System.security.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 be performed with older Flash browser functions such as SetVariable or callbacks established by using ExternalInterface.addCallback(). When HTML-to-SWF scripting crosses domain boundaries, the SWF file being accessed must call System.security.allowDomain(), just as when the accessing party is a SWF file, or the operation will fail. Specifying an IP address as a parameter to System.security.allowDomain() does not permit access by all parties that originate at the specified IP address. Instead, it permits access only by parties that were loaded by explicitly specifying that IP address in their URLs, rather than by 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.
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 System.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 System.security.allowDomain(). Version 5. No cross-domain scripting restrictions. Version 6. Cross-domain scripting security is introduced. By default, Flash Player forbids cross-domain scripting; System.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. This example would permit SWF files from www.mysite.com and store.mysite.com to script each other without calling System.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 System.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 the 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. System.security.allowInsecureDomain() is introduced to allow HTTPS SWF files that are being accessed to voluntarily disable this restriction, but Macromedia recommends against using System.security.allowInsecureDomain(). Version 8. 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 from which the child SWF file will come. This can happen, for example, when you use load-balancing redirects or third-party servers. In this situation, you can use the MovieClip._url property as a parameter to this method. For example, if you load a SWF file into the movie clip my_mc, you can call System.security.allowDomain(my_mc._url). If you do this, be sure to wait until the SWF file in my_mc begins loading, because the _url property does not have its final, correct value until this time. The best way to determine when a child SWF file has begun loading is to use MovieClipLoader.onLoadStart. 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, call System.security.allowDomain(_parent._url) from the child SWF. 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, you can also handle these situations by calling System.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:
Availability: ActionScript 1.0; Flash Player 6 - Behavior changed in Flash Player 7; behavior changed in Flash Player 8. Parameters domain1:String - One or more strings that specify domains that can access objects and variables in the SWF file that contains the System.Security.allowDomain() call. The domains can be formatted in the following ways:
Example The SWF file located at www.macromedia.com/MovieA.swf contains the following lines: System.security.allowDomain("www.shockwave.com"); loadMovie("http://www.shockwave.com/MovieB.swf", my_mc);Because MovieA contains the allowDomain() call, MovieB can access the objects and variables in MovieA. If MovieA didn't contain this call, the Flash Player security implementation would prevent MovieB from accessing MovieA's objects and variables. See also addCallback (ExternalInterface.addCallback method), onLoadComplete (MovieClipLoader.onLoadComplete event listener), _parent (MovieClip._parent property), _url (MovieClip._url property), allowInsecureDomain (security.allowInsecureDomain method) allowInsecureDomain (security.allowInsecureDomain method)public static allowInsecureDomain(domain:String) : Void 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. Macromedia 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 Macromedia 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 Macromedia Developer Center contains extensive information on Flash Player and security. For more information, see http://www.macromedia.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():
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:
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) loadPolicyFile (security.loadPolicyFile method)public static loadPolicyFile(url:String) : Void Loads a cross-domain policy file from a location specified by the url parameter. Flash Player uses policy files as a permission mechanism to permit Flash movies to load data from servers other than their own. Flash Player 7.0.14.0 looked for policy files in only one location: /crossdomain.xml on the server to which a data-loading request was being made. For an XMLSocket connection attempt, Flash Player 7.0.14.0 looked for /crossdomain.xml on an HTTP server on port 80 in the subdomain to which the XMLSocket connection attempt was being made. Flash Player 7.0.14.0 (and all earlier players) also restricted XMLSocket connections to ports 1024 and later. With the addition of System.security.loadPolicyFile(), Flash Player 7.0.19.0 can load policy files from arbitrary locations, as shown in the following example: System.security.loadPolicyFile("http://foo.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. The following code continues the previous example: loadVariables("http://foo.com/sub/dir/vars.txt") // allowed loadVariables("http://foo.com/sub/dir/deep/vars2.txt") // allowed loadVariables("http://foo.com/elsewhere/vars3.txt") // not allowedYou 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: System.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. Because the ability to connect to ports lower than 1024 is new, a policy file loaded with loadPolicyFile() must always authorize this connection, even when a movie clip is connecting to its own subdomain. For more information, see the following:
Availability: ActionScript 1.0; Flash Player 7,0,19,0 Parameters url:String - A string; the URL where the cross-domain policy file to be loaded is located. sandboxType (security.sandboxType property)public static sandboxType : String [read-only] Indicates the type of security sandbox in which the calling SWF file is operating. System.security.sandboxType has one of the following values:
Note that this property may be examined from a SWF file of any version, but is only supported in Flash Player 8 or greater. This unusual arrangement means that 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 or not at playback time. Thus, in a SWF file of version 7 or lower, you may find that this property has an undefined value; that should only happen when the player version (indicated by System.capabilities.version) is less than 8. In that situation, you can determine the sandbox type according to whether your SWF file's URL is a local file or not. If so, you can assume Flash Player will classify your SWF as "localTrusted" (prior to Flash Player 8, this was how all local content was treated). If not, you can assume Flash Player will classify your SWF file as "remote". For more information, see the following:
Availability: ActionScript 1.0; Flash Player 8 - See the description for version-specific details. | |||||||||||||||||||||||||||||||||||||||||
__proto__ (Object.__proto__ property), prototype (Object.prototype property), 
EAN: 2147483647
Pages: 113
- Enterprise Application Integration: New Solutions for a Solved Problem or a Challenging Research Field?
- Context Management of ERP Processes in Virtual Communities
- Data Mining for Business Process Reengineering
- Healthcare Information: From Administrative to Practice Databases
- Development of Interactive Web Sites to Enhance Police/Community Relations