Accessibility

Flash Player Article

 

Creating more secure SWF web applications

Peleus Uhley

Adobe

Adobe frequently updates the Flash Player software security model to improve the security of the Flash Player environment. However, that only addresses half of the overall solution to help securely deploy applications that run in Flash Player. As the web developer, you must also correctly leverage the tools provided by the ActionScript language and the Flash Player platform to help ensure that your SWF files are more secure. Poor programming conventions can expose SWF files and the sites that host them to web attacks. Adobe provides many resources to developers such as their Secure Programming Guide to assist with developing more secure code.

This article outlines many of the security considerations associated with common tasks and provides samples of techniques that can be used to help secure code against those threats. Links to the full documentation are provided throughout the article for further reference.  These techniques are designed primarily for the Flash Professional development environment but they can also be applied by Flex developers.

Requirements

To get the most out of this article you will need to install the following software:

Flash CS3 Professional (optional)

Flex Builder 3 beta (optional)

Flash Player 9 Update 3 (9,0,115,0) or later

Prerequisite knowledge

You should have an understanding of ActionScript 2.0, ActionScript 3.0, and Flash Player. Knowledge of Flash Professional or Flex is encouraged but not required.

Potential threats to SWF files

This section provides a brief overview of the different high-level threats that you should consider when developing SWF applications. Although there are more granular threats that could be defined within a specific context for any SWF file, this overview covers the high-level threats common to most SWF deployments. Throughout the rest of the document, "Related Threats" entries will map these threats to specific Flash Player APIs and concepts. Each section will then describe the mitigation strategies that apply to the identified threats.

Cross-domain privilege escalation

Cross-domain loading may allow a remote SWF to have unintended access to the loader's domain and data. If the loading SWF imports the remote SWF file into its security domain, then the loaded SWF could gain access to the parent SWF's data and relay that data back to an attacker. In addition, depending on settings within the web page, the loaded SWF could inject script into the loaded SWF file's web page. These attacks could occur whenever the end-user can gain control over movies that are loaded by a parent SWF file. Cross-domain privilege escalation is a high-level threat that can expose a SWF to more specific threats such as spoofing, script injection into the browser, malicious data injection, DNS rebinding and insufficient authorization restrictions. This threat exists whenever content from multiple remote sources is loaded and processed under a single security domain.

Spoofing

A remotely loaded SWF may try to render its controls over the top of the loading SWF in an attempt to perform a spoofing attack. By overlaying the parent SWF, the malicious SWF can hijack control from the loading SWF file. For instance, if developers do not set masks on Loaders to limit the remote SWF file to a particular area of the Stage then an attacker could perform a spoofing attack.

Malicious data injection

Injecting malicious data into applications is how most vulnerabilities are found by attackers. A Flash application may receive malicious data injection from several types of interfaces. For example, it is common for FlashVars to be set via the Object tag within the HTML. However, developers sometimes forget that these variables can be set via the URL where it is trivial for an attacker to alter the values. For example, if the FlashVar value is a URL that points to remote content such as another SWF, then the attacker could alter the URL to point to a malicious SWF instead. In ActionScript 2.0, any un-initialized value can automatically be set via the URL as a FlashVar. In ActionScript 3.0, you must explicitly request the value of each FlashVar variable and manually assign that value to an internal variable.

Other examples where malicious data inject can include any time a SWF loads remote data—such as when a SWF file obtains data from a LocalConnection, the SWF file remotely loads variables from a server, or the SWF file imports data from another SWF file. A SWF file will be exposed to this threat if you do not perform data validation on remotely obtained data.

Script injection into the browser

In some instances, website owners may host third-party SWF files on their site. However, the website owners may not want to grant the third-party SWF files read and write access to their HTML or JavaScript code. Incorrectly setting permissions could allow an attacker to rewrite the entire page or redirect the users from the trusted site to a phishing site. This threat exists for web administrators that host third-party SWFs as well as for SWF files that accept URLs via FlashVars.

The most common vulnerability to consider is an attacker injecting data in order to conduct a cross-site scripting (XSS) attack. Assume that the target SWF takes a URL value from a FlashVar and sends that information to a navigateToURL or a getURL command. An attacker who notices this behavior may try to replace the original URL value of the FlashVar with a "javascript:" URL. JavaScript URLs sent to the browser through getURL or navigateToURL methods will execute within the context of the domain hosting the SWF. The javascript: URL can contain any set of JavaScript commands including commands to steal the cookies from the domain and forward them to a third-party site. A cross-site scripting attack could also occur if a malicious remote SWF is imported into the trusted SWF and then the remote SWF calls a javascript: URL.

Insufficient authorization restrictions

Excessive cross-domain permissions may allow relay attacks, spoofing, data theft or other attacks. For example, a malicious SWF file may try to exploit overly permissive cross-domain policy file permissions to steal protected data from a remote website. Another example might be an untrusted SWF that is able to send malicious data to another domain via a LocalConnection. Weak domain restrictions can occur when wildcards are misused in allowDomain methods or cross-domain files.

Developers often consider a cross-domain threat to be domain www.a.com gaining unauthorized access to www.b.com. However, developers must also consider whether their SWF files will be hosted within a shared environment. This can include situations where a developer's content is hosted under http://www.host.com/~user1 and the content under http://www.host.com/~user2 is not explicitly trusted by the developer. This can also occur in advertising situations where ads from multiple sources are hosted on the same domain. There are situations where Flash Player takes directory and file paths into account in determining authorization such as with LocalConnections. There are other situations where only the hosting domain is considered such as allowDomain() settings. Developers need to take shared hosting situations into account when designing mitigations to this threat.

Unauthorized access to data in transit

An attacker may try to read or alter data sent over unencrypted channels such as RTMP and HTTP. If the SWF file is performing critical functions (such as collecting credit card data within a shopping cart), then the attacker could potentially view that data. An attacker may also try to manipulate traffic and attempt to replace the trusted SWF files with malicious SWF files before they reach the end-user. Vulnerabilities for this threat include when secure communication channels such as HTTPS or RTMPS are not used to protect sensitive data.

Insecure communications can also occur when SWF files loaded over HTTP can access the data of SWF files loaded over HTTPS. By default, an HTTP-loaded SWF file may not access data from SWF files loaded over HTTPS. However, if data is shared between an HTTP SWF and an HTTPS SWF then the data may be transmitted over an insecure channel. This can occur if an allowInsecureDomain method is misused or when the secure flag is set to false in a crossdomain.xml file.

Unauthorized local data access

An attacker may attempt to steal sensitive local data from SWF files and local shared objects. SWF files can be decompiled and local shared objects can be read by third-party applications. An attacker may also try to obtain the information dynamically through cross-scripting. This threat includes vulnerabilities such as when developers store sensitive data within SWF applications and shared objects.

Cross-site request forgery

Cross-site request forgery (XSRF) is where an attacker exploits a user who has visited their website by initiating an unauthorized request to another site to which the user is authenticated. If the target website utilizes atomic (single submit) actions for updates to user information, then the attacker can initiate a change to the user's account on that site by forcing the browser to make a request to the site. The attacker does not need the user's cookies to perform the attack since the browser will automatically append them to the request. The attacker is usually unable to directly see the results of their update but the change will be made nonetheless. Due to the current design of the web, protections against these attacks are currently being implemented by the websites themselves and not by the browser or its clients. Since Flash Player utilizes the browser to make web requests, Flash Player can be used as a tool in performing cross-site request forgery attacks.

DNS rebinding

Web browsers and Flash Player use domain names for establishing authorization to data as part of the same-origin policy. An attacker can try to bypass the same-origin policy by tricking the web browser to continually update the IP address it has recorded for a particular domain name. For this attack to work, the attacker must have a DNS server under their control and a malicious website. Through varying techniques, the attacker can update the IP address for their domain name within their DNS server and then force the web browser to retrieve the updated information. Therefore, the attacker can make their domain name first point to the IP of their public website, then point to an IP of a trusted server on the victim's internal network and then point back to their public website.

For all of these requests, only the IP address is changing and the domain name used to establish the requests remains the same. Since the domain name remains the same for all requests, the web browser considers the connection to the trusted internal server and the connection to the attacker's public web server to be equivalent with regards to security. This allows the attacker to steal information from the internal web server and send that data back to the public website. For many types of requests, Flash Player relies on the hosting web browser to establish HTTP connections. Therefore any DNS rebinding attack that is applied to the web browser will also affect Flash Player. This attack may also be applied to Flash socket connections.

Selecting more secure compiler settings

In this section I discuss the optimal settings to use in the Publish Options in Flash CS3 Professional to help security in your Flash applications.

To see more information regarding this topic, check out the section entitled Set publish options for the Flash SWF file format in Adobe LiveDocs

The first consideration a developer makes is what Flash Player version the SWF application should be compatible with. All modern versions of Flash Player include an auto-update feature to notify users when a new version of the player is available and this has been highly successful in getting the majority of Flash Player users migrated to new versions quickly. The Flash Player home page tracks market penetration of the players and shows how quickly new versions are adopted (see Adobe Flash Player version penetration). Flash Player 9 compatibility achieved 90% cross-platform market penetration within approximately one year while Flash Player 8 compatibility has over 98% cross-platform penetration in major markets. For some applications, reaching 98% of customers is sufficient. However, for global organizations, the inability to reach 1.5% of the hundreds of millions of systems on the Internet still results in not reaching a few million systems. Some of the systems with older versions of Flash Player include older operating systems or systems that are part of a locked environment where they do not receive updates unless absolutely necessary due to system stability.

Newer versions of Flash Player frequently contain important security updates and features which can help to ensure that SWF files are not misused on the hosted website. Due to backwards compatibility requirements, in some instances Flash Player determines whether to enforce the additional security changes based on the version of Flash Player that the SWF was compiled for and not the version of Flash Player that is executing the SWF. For example, if the end-user has the latest version of Flash Player installed (version 9) but the end-user is playing a SWF file that a developer compiled for Flash Player version 7, then, in some instances, the end-user's Flash Player will mimic the behavior of Flash Player 7—which has a less mature security model for both the site developer and the end-user. One example would be that the default for "allowScriptAccess" is "always" in SWF files compiled for compatibility for Flash Player 7 and "sameDomain" for SWF files compiled for Flash Player 8. Consequently, you should compile for compatibility with Flash Player 8 or later to ensure that the SWF uses the more secure setting.

Additionally, you access better security tools when leveraging ActionScript 3.0. Developers using ActionScript 3.0 can take advantage of regular expressions which can make the process of performing data validation easier. Input controls within the language are more centralized. In addition, the AVM2 virtual machine used to process ActionScript 3.0 is faster, more robust and more stable then the AVM1 environment that supports the legacy ActionScript 2.0 and ActionScript 1.0 code. Developers who want to migrate from ActionScript 2.0 to ActionScript 3.0 can find several resources in the Adobe Developer Connection's guidelines for migrating to ActionScript 3.0.

If you want to ensure your end-users are using a current version of Flash Player, then you can use the Flash Player Detection Kit provided by Adobe. It contains both client-side JavaScript and ActionScript code for detecting the Flash Player version and determining if the version is appropriate for your content.

Using the protect from import and permit debugging options

Related threats: Unauthorized local data access

The Protect From Import and Permit Debugging flags use an MD5 hash to password-protect SWF files from import into a Flash authoring tool. This protection is a basic protection for authoring tools that choose to honor it. A determined attacker could still decompile the SWF file to get the source code or strip the debugging flag from the binary. The MD5 hash used by these flags is subject to brute force dictionary-based attacks. Therefore, SWF files should not be considered to be a black box application even with the Protect From Import flag set. Any sensitive data or secrets stored within a SWF can easily be found. Developers should not store static passwords, encryption keys or other sensitive data within the source code of a SWF file.

Compiling clean code

Related threats: Unauthorized local data access

When creating applications, it is a best practice to remove all debug code from the final production releases. This is also a best practice for developing SWF applications. The Omit Trace Actions flag in Flash development environments tells the compiler to remove any trace commands when creating the compiled SWF file. This will make the published SWF smaller and it will remove any excess information or actions from the SWF.

Setting the minimum stage size

Related threats: Spoofing

The stage size should be set to a minimum of 215 pixels wide and at least 138 pixels high so that Flash Player messages from shared objects, microphone, camera and other components can be displayed fully to the user.

Setting security controls within the HTML code

When a SWF is embedded within HTML, there are several flags that can be set that tell Flash Player the permissions the SWF file has to access content either from the browser or on the network. These flags are useful for sites that may host untrusted SWF files from third-party developers.

In addition to the strategies described below, refer to the "How to restrict SWF content from HTML" blog post for additional information.

Using allowScriptAccess

Related threats: Script injection into the browser

To learn more about controlling access to HTML scripts, see the section entitled Controlling access to scripts in a host web page on Adobe LiveDocs.

The allowScriptAccess setting has been available since Flash Player 6,0,40,0, It determines whether a parent SWF file and any SWF files loaded by the parent SWF file can make outbound scripting calls to the browser through commands such as FSCommand and ExternalInterface or sending "javascript://{code}" statements to getURL (in ActionScript 2.0) and navigateToURL (in ActionScript 3.0).

When you grant access to the SWF file, remember that you are essentially granting both read and write access to the entire HTML page.

The three possible settings for allowScriptAccess are:

It is also important to note that the allowNetworking tag can affect script access within the browser and will supersede the settings used for the allowScriptAccess tag.

Review the highlighted sections in the following code example:

<object id='MyMovie.swf' classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000' codebase='http://download.adobe.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0' height='100%' width='100%'>
<param name='allowScriptAccess' value='never'/>
<param name='src' value=''MyMovie.swf'/>
<embed name='MyMovie.swf' pluginspage='/go/getflashplayer' src='MyMovie.swf' height='100%' width='100%' allowScriptAccess='never'/>
</object>

Understanding allowNetworking

Related threats: Script injection into the browser, cross-domain privilege escalation

To augment the information provided below, visit the section entitled Restricting networking APIs in Adobe LiveDocs.

The allowNetworking feature was added in Flash Player 9 to prevent a SWF from making external networking calls through the browser or through ActionScript networking calls. The allowNetworking settings will supersede the allowScriptAccess settings since methods controlled by the allowScriptAccess tag are a subset of the overall class of ActionScript networking methods:

The three possible settings for allowNetworking are:

For ActionScript 3.0, the blocked networking methods include sendToURL(),  FileReference.download(), FileReference.upload(), Loader.load, LocalConnection.connect(), NetConnection.connect(), NetStream.play(), Security.loadPolicyFile(), SharedObject.getLocal(), SharedObject.getRemote(), Socket.connect, Sound.load(), URLLoader.load(), URLStream.load(), XMLSocket.connect(), System.security.loadPolicyFile(), as well as those methods blocked by the internal setting.

For ActionScript 2.0, the blocked networking methods include XML.load(), XML.send(), XML.sendAndLoad(), LoadVars.load(), LoadVars.send(), LoadVars.sendAndLoad(), loadVariables(), loadVariablesNum(), MovieClip.loadVariables(), NetConnection.connect(), NetStream.play(), loadMovie(), loadMovieNum(), MovieClip.loadMovie(), MovieClipLoader.loadClip(), Sound.loadSound(), LocalConnection.connect(), LocalConnection.send(), SharedObject.getLocal(), SharedObject.getRemote(), FileReference.upload(), FileReference.download(), System.security.loadPolicyFile(), XMLSocket.connect(), as well as those methods blocked by internal setting.

It is also not possible to reference external media in an <img> tag in the htmlText property of a TextField object (because a SecurityError exception is thrown). Symbols from an imported shared library added in the Flash authoring tool (not ActionScript) are blocked at run time.

Review the highlighted sections in the code example below:

<object id='MyMovie.swf' classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000' codebase='http://download.adobe.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0' height='100%' width='100%'>
<param name='allowNetworking' value='none'/>
<param name='src' value=''MyMovie.swf'/>
<embed name='MyMovie.swf' pluginspage='/go/getflashplayer' src='MyMovie.swf' height='100%' width='100%' allowNetworking='none'/>
</object>

allowNetworking supersedes the AllowScriptAcess methods

The results of combining the allowNetworking and allowScriptAccess flags are shown in Table 1.

Table 1. Network and access settings for different levels of security

allow
ScriptAccess		 allowNetworking
 

All

Internal

None

Always

The SWF has full access to communicate with the browser and the network. This is the least secure setting.

The allowNetworking setting will override the allowScriptAccess setting and disallow access to the browser. The SWF is still able to leverage internal APIs such as sockets and loaders to communicate with the network.

The allowNetworking setting will override the allowScriptAccess setting and prevent the SWF from communicating to the browser and the network.

SameDomain

The SWF can talk to the HTML container if they are both within the same domain. All internal networking APIs are allowed.

The allowNetworking setting will override the allowScriptAccess setting and disallow access to the browser. The SWF is still able to leverage internal APIs such as sockets and loaders to communicate with the network.

The allowNetworking setting will override the allowScriptAccess setting and prevent the SWF from communicating to the browser and the network.

Never

The SWF can not make calls to the browser but it can make network calls using internal APIs such as sockets and loaders.

This SWF can not communicate with the browser. The SWF is still able to leverage internal APIs such as sockets and loaders to communicate with the network.

The allowNetworking setting prevent the SWF from communicating to the browser and the network. This is the most secure setting.

Controlling full-screen mode

Related threats: Spoofing

To find out more about working in full-screen mode, see the Developer Center article, Exploring full-screen mode in Flash Player 9.

You can control the display of full-screen mode using the features included in Flash Player. A website hosting third-party SWF files may not wish to allow the videos to go into full screen mode and overlay the site's content. Essentially, full-screen display could result in end-users being tricked into believing that they are interacting with the hosting website—when in reality they are interacting with the third-party SWF file. By default, the allowFullScreen option is set to false.

Adobe has included other controls to limit this scenario: The user must initiate full-screen mode with a mouse click or a keypress event. Upon invoking full-screen display, the end-user will receive an overlay dialog box warning them they are viewing the SWF in full-screen mode with instructions on how to exit. Users cannot enter data into text input fields while the SWF is displayed in full-screen mode. Users and administrators also have the option to prevent full-screen mode within their mms.cfg file.

Review the highlighted sections in the code example below:

<object id='MyMovie.swf' classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000' codebase='http://download.adobe.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0' height='100%' width='100%'>
<param name='allowFullScreen' value='false'/>
<param name='src' value=''MyMovie.swf'/>
<embed name='MyMovie.swf' pluginspage='/go/getflashplayer' src='MyMovie.swf' height='100%' width='100%' AllowFullScreen='false'/>
</object>

Loading remote content

One of the most common tasks you may want to do is fetch images, sounds, or other data from a remote website. If the content is from a different domain than the requesting SWF file, then Flash Player may need to check with the remote domain to confirm whether you have permission to access that content. The following sections describe when permission is needed and how to obtain it.

Loading content from different domains

Related threats: Cross-domain privilege escalation

By default, Flash Player will follow the same-origin policy used by browsers which says that content within a single domain can access all the other content and data hosted on the same domain name. In addition, a site can present content from other domains but it can not directly access the data belonging to those other domains. For example, the same-origin policy will allow a piece of content on www.a.com to access all of the other data associated with www.a.com. The site www.a.com can also include an iframe showing the web page for www.b.com. However, the same-origin policy prohibits www.a.com from accessing www.b.com's cookies or interacting with the JavaScript on www.b.com's page.

Flash Player considers the full domain name used to establish content's origin to be its security domain. For Flash Player, a SWF file's domain is defined by where the SWF file is hosted. If a web page at the domain www.a.com includes an object tag to load a SWF from the domain www.b.com, then the SWF considers its security domain to be defined by www.b.com. Other SWF files hosted on the www.a.com site will not have full access to the SWF loaded from the www.b.com site because they are loaded from different security domains. Flash Player matches on the complete domain name and therefore the domain www.a.com is considered to be a different security domain from the domain home.a.com. Flash Player also separates content loaded from www.a.com over HTTPS and content loaded from www.a.com over HTTP into separate security domains.

Unlike the browser, Flash Player contains several methods for expanding the same-origin protections to include more than one domain name. Therefore the owner of the site www.a.com can tell Flash Player that the site's content can be shared with the domain home.a.com. This allows website owners with multiple domain names to have interaction between their sites. Many of these methods support the use of wildcards for when developers want to share their data with the world. From a security perspective, wildcards need to be used with discretion since you are allowing everyone access to your data.

Splitting a single domain name into two security domains by using IP addresses

In addition to incorporating many domain names into one security domain, it is also possible to split one domain name into two security domains. This may be necessary if you only have one domain name available but you have SWF files with two different trust levels. To accomplish this, you can take advantage of the fact that Flash Player does not associate domain names with IP addresses.

If the site www.example.com is hosted at the IP address 1.2.3.4, then Flash Player will consider a SWF loaded by the URL http://www.example.com/my.swf to be in a different security domain then the SWF loaded by the URL http://1.2.3.4/my.swf. This approach can be useful if a site allows untrusted users to upload SWF files. Since the site owners want to protect their SWF files from being accessed by malicious SWF files uploaded by a user, the site owners could reference the trusted SWF files using the domain name in the URL and then load the potentially malicious user-submitted SWF files using an IP addresses within the URL.

Implementing cross-domain files

Related threats: Cross-domain privilege escalation, insufficient authorization restrictions

If you'd like to research how to use crossdomain.xml files, see Overview of permission controls on Adobe LiveDocs and Cross-domain policy file usage recommendations for Flash Player on the Flash Player Developer Center.

Cross-domain files are one method for expanding the same-origin policy to allow multiple domain names to be considered part of the same origin. A cross-domain policy file is a way for the server hosting the file to acknowledge that its content can be considered to be part of the same origin as domains listed within the cross-domain file. Cross-domain files served from a web server on port 80 or 443 are considered to be HTTP policy files and can control policies for web requests. Cross-domain files hosted from other ports are considered to be socket policy files. Socket policy files will be discussed later.

The crossdomain.xml file can be used to specify three aspects of access to the HTTP server:

These cross-domain controls are available to the distributor of content and can apply to either the entire website or just one portion. Creators of SWF files also have the ability to define cross-domain controls through the use of the Security.allowDomain() method which I discuss later. The Security.allowDomain() method is a more granular way of granting cross-domain permissions on a per-file basis.

It is also important to note that Flash Player, like most browsers, does not prevent cross-domain sending of data. Flash Player only attempts to prevent cross-domain loading of data. If the website at home.a.com wants to perform an HTTP POST of data to www.a.com using a method that does not return a response to Flash Player, then it can do so without the need for a cross-domain file. If the SWF at home.a.com needs to access the response data from the request, then a cross-domain policy file is necessary.

Here are some situations that require using the crossdomain.xml file:

It is not necessary to use a crossdomain.xml file:

In order to successfully load remote content into a SWF file, a remote domain has to place a crossdomain.xml file in the directory of the content or one its parent directories. Before making a request to a new remote domain, Flash Player will verify that the settings to allowNetworking permit access to remote domains. Next, Flash Player needs to request the crossdomain.xml file to determine whether the current domain is allowed to load the remote domain's content. If the current domain is not listed in the crossdomain.xml file or the file does not exist, then access to the content is denied and an exception will be thrown when you attempt to access the data.

Cross-domain files can be used to explicitly deny access globally. If a cross-domain file is not present, then access is also denied. Access will also be explicitly denied to everyone by creating a crossdomain.xml file with no entries in the root directory and a site-control policy set to none:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy> 
 <-- No one can have raw access to any of the content on this site through Flash Player -->
 <-- This is the only cross-domain policy file on this server -->
  <site-control permitted-cross-domain-policies="none" />
</cross-domain-policy>

The risks associated with cross-domain requests

There are several risks associated with cross-domain policy file requests. For example, assume that www.example.com uses cookies to track authentication and authorization to sensitive areas of their website. The administrators of the website have installed a cross-domain policy that allows all sites access by setting the allow-access-from domain setting to a global wildcard ("*"). The impact of this setting is that the website is informing Flash Player that the same-origin restrictions do not apply to their site. Therefore, a malicious SWF from a remote domain is now allowed access to all of the data and content within www.example.com. Since the web browser will append any existing cookies to HTTP requests made by Flash Player, the SWF from the remote domain could make requests to areas of the website that contain sensitive information. The malicious SWF can then take the data returned within the response and forward it back to their original website.

This threat can be expanded if the overly permissive cross-domain file is on an internal network. For instance, an internal IT person may create a cross-domain file with a domain="*" setting thinking that the host is on an internal network and everyone is trusted on the internal network. However, cross-domain policy files are a way for hosts to state which domains the host trusts with its data. Therefore, the IT administrator's cross-domain policy file states that the internal host trusts all sites with its data including Internet sites. Therefore a SWF loaded by the browser from an external website would be allowed to make requests to the internal website and relay that information back to the Internet.

Refining access with cross-domain

Due to the many risks associated with cross-domain permissions, there are several controls available to an administrator to grant granular permissions to their content. These controls include:

The next few sections detail these techniques for avoiding creating overly permissive cross-domain permissions.

Using wildcards in conjunction with domain names

If the domain has multiple sub-domains that change frequently, administrators can use a wildcard in conjunction with the parent domain name by specifying domain="*.mysite.com" instead of domain= "*". Below are additional sample valid entries for a crossdomain.xml file that demonstrate alternatives to using the "*" wildcard:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy>
  <!-- This is the only cross-domain policy file for this server -->
  <site-control permitted-cross-domain-policies="master-only"/>
   <!— Administrators can set multiple entries with a wildcard on the sub-domain to     avoid setting domain="*"  -->
   <allow-access-from domain="*.mysite.com" />  
       <allow-access-from domain="*.myothersite.com" /> 
</cross-domain-policy>

Always using SSL consistently

Related threats: Unauthorized access to data in transit

Flash Player version 7 and later have several restrictions preventing HTTP loaded SWFs accessing resources served over HTTPS. These restrictions are in place by default to prevent untrusted SWF files loaded over HTTP from accessing sensitive data that was securely communicated to trusted SWF files loaded over HTTPS. SWF files loaded over HTTP are untrusted because they are subject to man-in-the-middle attacks. A man-in-the-middle attack is where someone sitting on the network between the end-user and the server alters or replaces the SWF file while it is in transit. Man-in-the-middle attacks are frequently executed in places such as wireless networks.

Some websites create SWF applications which load all of their data over HTTPS in order to ensure that the data is protected. However, problems occur when these websites start the user experience by loading the initial SWF application over HTTP. For the end-user, Flash Player does not provide feedback that the Flash application is using HTTPS so the end-user can not validate their information is being protected. Also, since the initial Flash application is loaded over HTTP, it is subject to a man-in-the middle attack and therefore the end-user can not trust the SWF file. If SSL is going to be used to protect data, then it should be used consistently throughout the entire application. This will ensure that the user receives the SWF over a secure connection and it will aid the developer in avoiding issues created by mixing insecure and secure protocols.

Avoid allowing HTTP and HTTPS SWF files to communicate

It is possible to override these protections by setting the "secure" flag for the domain to "false" within the crossdomain.xml file or through an allowInsecureDomain method within the SWF. This practice is not recommended. If allowing communication from HTTP SWF files to HTTPS protected data is absolutely necessary, try to limit the exposure of the HTTPS protected data to the HTTP loaded SWF file. For instance, rather than setting secure="false" in a crossdomain.xml file and exposing all the data on your site, it may be better to set an allowInsecureDomain on a LocalConnection within the HTTPS loaded SWF file so the access from the HTTP loaded SWF files can be controlled.

Insecure HTTPS connections

Flash Player supports making HTTPS requests by using the browser's SSL implementation. Therefore if a SWF is connecting to a server with certificates issues such as an expired certificate or a failed domain name match, then the browser will handle prompting the user about issue. Developers should work with website administrators to ensure that SSL certificates are current, signed by a trusted Certificate Authority and match the host's domain name in order to provide the user with a secure and seamless experience.

Ensuring SSL protections with the Secure flag

By default, the crossdomain.xml file will prevent SWFs hosted on an HTTP server from accessing data served from an HTTPS protected site through the use of the secure flag. The default value of the secure flag is "true" which informs the player not to allow remote HTTP loaded SWF files from accessing content on the HTTPS protected areas of the website. Transmitting data that was originally protected by SSL to a remote server over HTTP can defeat all the protections that the SSL connection originally provided for that data.  The secure flag can be applied to either web or socket policy entries.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy>
   <!-- This is a master-policy file -->
   <site-control permitted-cross-domain-policies="master-only"/>
   <!-- This says that http://www.mysecuresite.com can access this site's HTTP data -->
   <!-- SWFs on https://www.mysecuresite.com can access this site's HTTPS data -->
   <!-- SWFs on http://www.mysecuresite.com can not access this site's HTTPS data -->
       <allow-access-from domain="www.mysecuresite.com" secure="true" />
</cross-domain-policy>

Complex cross-domain implementations

The following sections discuss more complex, cross-domain implementations, including cross-domain policy files in sub-directories, utilizing meta-policies, and socket policy files.

Utilizing crossdomain.xml in subdirectories

If you'd like to get more information about how to work with the loadPolicyFile method, see the loadPolicyFile documentation on Adobe LiveDocs.

HTTP policy files can be specified from subdirectories in order to define access for that directory and all of its subdirectories. Therefore, rather than creating a very general crossdomain.xml file in the root directory of a site, an administrator can allow users to define their own crossdomain.xml files within their subdirectories for their specific needs. For instance, a developer who needs to specify domain="*" can specify that permission in a sub-directory crossdomain.xml file to expose only that directory as an alternative to placing domain="*" in the root crossdomain.xml file. This may be useful in situations where a developer creates local-with-networking SWF files which require a domain="*" setting to communicate with a public website. Crossdomain.xml files hosted from a subdirectory can not define access to ports.

The following code example illustrates how to load a policy file from a subdirectory:

//Load a policy file which allows cross-domain access to the ~user1 directory
System.security.loadPolicyFile("http://www.example.com/~user1/myPolicy.xml");
 
//Access data under the ~user1 directory
NetStream.play("http://www.example.com/~user1/vids/myVideo.flv");

Avoid using FlashVars in loadPolicyFile() calls

Related threats: Cross-site request forgery

Developers should avoid obtaining URLs from FlashVars for use in the loadPolicyFile method. If the attacker can control the FlashVar, then they can use the loadPolicyFile method to make a cross-domain GET request and send arbitrary data to a remote site. This could result in an unauthorized information disclosure or a cross-site request forgery attack. If a developer must accept the location as a FlashVar, then the developer should takes steps to make sure that the URL is on an approved whitelist before providing the URL to the loadPolicyFile method.

Meta-policies can be used to control sub-domain crossdomain.xml files

For more information on meta-policies, please see the meta-policies section of Security changes in Flash Player 9 (Version 9,0,115,0).

Allowing any user on a system to create a crossdomain.xml file for their directory is of frequent concern to many system administrators. In some instances, system administrators want to be the only entity capable of defining cross-domain permissions. Starting with Flash Player 9 Update 3, Flash Player acknowledges controls set by the system administrators to limit which directories are allowed to create crossdomain.xml files. These options that are specified within a <site-control/> directive include:

To utilize these controls, an administrator would create a crossdomain.xml file similar to the following example in their root web directory:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy>
  <!—This is the only cross-domain policy file for this server -->
  <site-control permitted-cross-domain-policies="master-only"/>
</cross-domain-policy>

The meta-policy implementation is being back-ported to Flash Player 7 and Flash Player 8 to reach as many end-users as possible.

Initiating a policy file check

If you'd like to research the content discussed in this section further, you may find it useful to visit the following pages on Adobe LiveDocs:

You can use the checkPolicyFile property to check for a policy file. There are checkPolicyFile properties for NetStream, SoundLoaderContext, LoaderContext and image tags in an HTML text area. This property is applicable to the Loader.load() method, but not to the Loader.loadBytes() method.

Set this property to true when you are loading an image (JPEG, GIF, or PNG) from outside the SWF file's domain, and you need programmatic access to the content of that image using ActionScript. Flash Player will first consider policy files that have already been downloaded, next it attempts to download any pending policy files specified in calls to the Security.loadPolicyFile() method, and then attempts to download a policy file from the default location that corresponds to URLRequest.url, which is /crossdomain.xml on the same server as URLRequest.url.

An example of accessing image content involves referencing the Loader.content property to obtain a Bitmap object, and calling the BitmapData.draw() method to obtain a copy of the loaded image's pixels. Attempts to utilize one of these operations without specifying a checkPolicyFile at loading time may result in a SecurityError exception because the needed policy file has not been downloaded yet.

The code example below illustrates how to check for policy files to avoid security errors: 
// Setting a Loader to check the policy files
var ldr:Loader = new Loader();
var loader_context:LoaderContext = new LoaderContext()
loader_context.checkPolicyFile = true;
var url:String = "http://www.remote_example.com/content.swf";
var urlReq:URLRequest = new URLRequest(url);
ldr.load(urlReq,loader_context);
// Checking for a policy file by specifying "CheckPolicyFile" in an
// image tag defined within a TextArea
<img src = 'http://remote.server.org/filename.jpg'
checkPolicyFile = 'true' id = 'instanceName' >

SWF files are unable to check for cross-domain files if the allowNetworking parameter of the object and embed tags is set to false. If a SWF cannot locate the policy file, then a SecurityException will be thrown at the time a data load is attempted.

Socket policy files

Related threats: DNS rebinding, cross-domain privilege escalation

This section provides a brief summary of socket policy files. For complete information on socket policy files, please see the socket policy files section of Security changes in Flash Player 9 (version 9,0,115,0)

Socket policy files define what socket connections are permitted to the domain. Socket policy files need to be hosted from a socket policy file server listening on port 843 or from the same port as the intended connection. Like cross-domain files, they support meta-policies to define where policy files are allowed on the server. The available meta-policies are:

Setting the secure flag

Socket policy files support a secure flag that is similar to HTTP policy files. Setting this flag to "true" within an <allow-access-from> directive informs Flash Player that only SWF files served over HTTPS are allowed to connect to the specified port. By default this flag is assumed to be false. It is currently not a best practice to rely on this flag for remote sockets since socket policy files are currently fetched over insecure protocols and are subject to man-in-the-middle attacks. Therefore, an attacker may change the value of the flag while it is transit. This flag may be appropriate for localhost connections where man-in-the-middle attacks are far less likely.

Use ranges and commas in a socket policy file to define port access

Instead of using wildcards to define port access, Flash Player will accept ranges and commas to specify groups of port numbers. This can reduce the risk of accidentally exposing non – Flash Player related ports to Flash Player's socket libraries:

// Use an XMLSocket request to port 843 in order to download a policy
// file allowing access to 456
System.security.loadPolicyFile("xmlsocket://socks.mysite.com:843");
// Connect to port 456
mySocket.connect("socks.mysite.com", 456);
// The crossdomain.xml file on port 123 allowing access to 456
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for xmlsocket://socks.mysite.com -->
<cross-domain-policy> 
   <!-- This is a master-policy file -->
   <site-control permitted-cross-domain-policies="master-only"/>
   <!—Instead of setting to-ports="*", administrator's can use ranges and commas -->
   <!—This will allow access to ports 123, 456, 457 and 458 -->
       <allow-access-from domain="socks.mysite.com" to-ports="123,456-458" />
</cross-domain-policy>

Communicating between SWFs and across domains

Related threats: Cross-domain privilege escalation, malicious data injection, unauthorized access to data in transit, insufficient authorization restrictions

Flash Player provides several methods for communication between SWF files depending on the developers needs. Each of the methods includes a cross-domain communication capability. Which method is appropriate depends on the use case scenario and how much trust exists between the two domains.

The solutions can be subdivided into direct communication and communication through a common resource. Direct communication methods require the target SWF file to be loaded by the sender. If a common resource for communicating is created, then loading operations are not needed and communication can occur between multiple SWF files.

Below is a list of the common methods and some things to consider regarding their capability and security.

Direct communication

Import loading via Loaders:

Cross-scripting permissions via flash.system.Security.allowDomain():

Communication through a shared resource

LocalConnection:

Local shared objects:

JavaScript relaying:

Loaders

Related threats: Cross-domain privilege escalation, malicious data injection, unauthorized access to data in transit, insufficient authorization restrictions

To learn more about security settings while using the Loader class, see the documentation for LoaderContext in ActionScript 3.0 on Adobe LiveDocs.

You can use the Loader class for import loading or for cross-scripting communication depending on the domains specified within the LoaderContext parameter settings. Two types of domains can be specified when loading content. The first is a security domain which is typically defined by the location where the SWF was loaded. The security domain is used to determine whether the SWF should be import loaded. Each security domain can contain multiple "ApplicationDomains" which define inheritance and access boundaries between classes within the code. ApplicationDomains are only supported in SWF files authored in ActionScript 3.0. Both application and security domains are defined within the Loader's LoaderContext settings.

Be aware of when Flash Player defaults to import loading

Security domains can be assigned when a SWF file is being loaded from another domain. By default in a HTML page, two SWF files loaded independently from different domain names will have different security domains. If the loading SWF file explicitly trusts the remote SWF by incorporating the remote SWF into its code, then the loading SWF can import it directly into its own security domain. This process is called import loading. Import loading allows the developer to load remote SWF files from other domains as though they were loaded from the developer's domain. This should only be considered in situations when you completely trust the content coming from the remote domain. Import loading is the ActionScript 3.0 equivalent of running eval() on someone else's code. If the SWF file remains within its own security domain, then cross-scripting permissions must be employed in order to allow communication which will be discussed later in this section.

There are two ways you can perform import loading in order to load a remote SWF into the current security domain. When Loader.loadBytes() is used to load a SWF, the SWF is loaded into the security domain of the loading SWF by default, if the LoaderContext is set to null. The second method involves specifying in the LoaderContext that the SecurityDomain is the currentDomain. You can only change the security domain of the loaded SWF to the loading SWF file's domain. Additionally, a crossdomain.xml file must exist on the remote server approving the loading of the SWF by the current domain.

The code example below shows an example of using LoaderContext: 

// This will result in import loading (the default for Flash Player)
var ldr:Loader = new Loader();
var url:String = "http://www.unknown.example.com/content.swf";
var urlReq:URLRequest = new URLRequest(url);
ldr.loadBytes(urlReq);
 
// This will also result in import loading
var ldr:Loader = new Loader();
var loader_context:LoaderContext = new LoaderContext()
loader_context.securityDomain = SecurityDomain.currentDomain
var url:String = "http://www.unknown.example.com/content.swf";
var urlReq:URLRequest = new URLRequest(url);
ldr.load(urlReq,loader_context);
 
// Load a SWF but leave it in its own security domain
var ldr:Loader = new Loader();
var url:String = "http://www.unknown.example.com/content.swf";
var urlReq:URLRequest = new URLRequest(url);
ldr.load(urlReq);

Import loading can allow a SWF file to talk to the loading SWF file's DOM

When you are loading a remote SWF, consider both the impact of the access that SWF file will have with other SWF components as well as the impact on the web page where it is loaded. If allowScriptAccess is set to Always, then any method of loading a SWF file will allow script access to the hosting web page. If allowScriptAccess is set to sameDomain then import loading the remote SWF grants it access to the hosting web page.

Setting application domains

Application domains define how classes are handled by the interpreter and whether the loaded SWF can access or inherit the loading SWF file's classes. Application domains are for managing cooperating units of ActionScript code and are not intended for security purposes. They can not be applied to SWF files authored in ActionScript 2.0 or ActionScript 1.0. Which option is appropriate will depend on the specific application. Choosing to load the SWF with the default option of being a child of the loader's ApplicationDomain or into the loader's own ApplicationDomain will result in the loaded SWF being able to access or inherit the parent SWF's classes. If the loading SWF has classes that should not be immediately exposed to loaded SWF files, then the developer should load the SWF as a child of the system's ApplicationDomain to ensure it does not inherit the loading SWF file's classes. However, in this usage, the child SWF file may still be able to explicitly retrieve definitions from other ApplicationDomains if it knows their location.

The code example below shows how this is accomplished:

// Create the request and LoaderContext for the application domain
request = new URLRequest(swfLib);
var context:LoaderContext = new LoaderContext();

// Option 1: Loads the SWF as a child of the current domain
context.applicationDomain = new ApplicationDomain(ApplicationDomain.currentDomain)

// Option 2: Sets the application domain to the current domain
context.applicationDomain = ApplicationDomain.currentDomain;

// Option 3: This separates the loader and loadee entirely
context.applicationDomain = new ApplicationDomain(null).

// Option 4: A complex example demonstrating how to load a SWF
// file into a new child of the current domain's parent's parent
Content.applicationDomain = new ApplicationDomain(ApplicationDomain.currentDomain.parentDomain.parentDomain)

// Load the request based on the context setting
loader.load(request, context);

Cross-scripting between domains

Related threats: Cross-domain privilege escalation, malicious data injection, unauthorized access to data in transit, insufficient authorization restrictions

To get more information about topics discussed in this section, see the following pages on Adobe LiveDocs:

If you load two SWF files from the same domain, you have several methods you can use to allow the SWFs to communicate and share data and functions. However, if the two SWF files are loaded from different domains, then they are not allowed to communicate via cross-scripting unless you specifically grant access by specifying system.Security.allowDomain() within the SWF file that will be accessed. The allowDomain setting allows only one-way communication. If the two SWF files need to exchange data in both directions, then both SWF files must contain an allowDomain statement (see Figure 1).

Using security.allowDomain in ActionScript 3.0

Using allowDomain in ActionScript 2.0

Figure 1. Using security.allowDomain in ActionScript 3.0 (top) or allowDomain in ActionScript 2.0 (bottom) to enable communication between SWFs loaded on different domains

When a SWF file loaded over HTTP wants to access data from a SWF file served over HTTPS then special permission must be granted. In these situations you can use, the security.allowInsecureDomain() call. It is highly recommended to avoid these types of scenarios whenever possible. Using this type of communication may potentially allow sensitive data protected by SSL to be leaked into an unprotected environment.

The security.allowDomain() restrictions have evolved with each new version

Flash Player cross-domain security rules have evolved with the security model of the player. Developers should take this into account when deciding which version of their Player to specify in compiling their SWF. The following table summarizes the differences (see Table 2).

Table 2. Cross-domain security rules implemented by different versions of Flash Player

Latest SWF version involved in cross- scripting 5 or
earlier		 6 7 8 or
later
allowDomain() needed? No Yes, if super-domains don't match Yes, if domains don't match exactly Yes, if domains don't match exactly
allowInsecureDomain() needed? No No Yes, if performing HTTP-to -HTTPS access (even if domains match exactly) Yes, if performing HTTP-to -HTTPS access (even if domains match exactly)
Which SWF must call allowDomain() or allowInsecureDomain()? N/A The SWF file being accessed, or any SWF file with the same super-domain as the SWF file being accessed The SWF file being accessed, or any SWF file with exactly the same domain as the SWF file being accessed SWF being accessed
What can be specified in allowDomain() or allowInsecureDomain()? N/A
  • Text-based domain (mysite.com) or
  • IP address (192.168.1.1)
  • Text-based domain (mysite.com) or
  • IP address (192.168.1.1)
  • Text-based domain (mysite.com) or
  • IP address (192.168.1.1) or
  • wildcard (*)

In Flash Player 9, using this API applies only to the SWF file that calls them, not to other SWF files from the same domain.

It is important to not that the behavior of Flash Player is defined by the version you select in the Publish settings when you create the SWF file from the FLA file and is not based on the version of Flash Player itself. For example, when Flash Player version 9 is playing a SWF file published for version 7, it applies behavior that is consistent with version 7. This practice ensures that backwards compatibility is maintained and that player upgrades do not change the behavior in deployed SWF files.

Setting Security.allowDomain() permits more than just cross-scripting

The Security.allowDomain() method grants access for cross-scripting, accessing the display list, access to the Stage object and event detection. This will also mean that HTML-to-SWF scripting is granted to the remote domain. HTML-to-SWF communication is discussed later in the JavaScript Relaying section. Allowing cross-scripting between two domains should only occur when the script allowing access explicitly trusts the domain that is being granted access. Cross-scripting will allow access to all of the objects and methods within the SWF granting permission.

If a parent wants to determine whether it can cross-script with a SWF that it has just loaded, it can check the childAllowsParent property of LoaderInfo in ActionScript 3.0. Likewise, a loaded SWF can determine if it can communicate with its parent via the parentAllowsChild property of ActionScript 3.0.

Communicating through a shared resource

The next three methods describe considerations for communicating through a shared resource. These methods do not require the target SWF file to be loaded, and they can allow communication to more than one SWF file. Shared resources can include local connections, local shared objects, and JavaScript relaying.

Controlling LocalConnection communication

Related threats: Cross-domain privilege escalation, malicious data injection, insufficient authorization restrictions

To find the documentation for the content discussed in this section, visit the LocalConnection ActionScript 3.0 documentation on Adobe LiveDocs.

You can use a LocalConnections object to allow two or more SWF files to communicate with each other if they are both being hosted simultaneously on the same machine. Since the only requirement is that both SWFs are running simultaneously on the same machine, the two SWF files do not need to be running in the same browser. The allowDomain() method within the LocalConnection object is used to authorize access to the LocalConnection. The identifying name of a connection is the domain name attached to the connection name that you've assigned. The domain name is also sent in the sendingDomain parameter of allowDomain. The LocalConnection.allowDomain method is an assignable method for checking authorization.

The code example below shows how to add the superdomain as a prefix of the connection name:

// Receiving LocalConnection SWF
// For Flash Player 6 hosted on www.example.com uses superdomains
// for authorizing the connection in allowDomain
receiving_lc.allowDomain = function(sendingDomain) {
   return(sendingDomain=="example.com");
}
receiving_lc.connect('myConnection');

// Sending LocalConnection SWF
// sendingLC in http://store.example.com/sending.swf connects by
// prefixing the superdomain to the connection name
sendingLC.send('example.com:myConnection', 'myMethod');

If you are working with files authored for Flash Player 7 or later, the sendingDomain parameter contains the exact domain of the caller. In this situation, the connection must be identified with the full domain: 

// Receiving LocalConnection (AS2)
// AS2 code for Flash Player 7 hosted on www.example.com
receiving_lc.allowDomain = function(sendingDomain) {
return(sendingDomain=="store.example.com");
}
receiving_lc.connect('myConnection');

// Receiving LocalConnection (AS3)
// AS3 code for Flash Player 9 hosted on www.example.com
receiving_lc.allowDomain("store.example.com");
receiving_lc.connect('myConnection');

// Sending LocalConnection (AS2 or AS3)
// sendingLC is in http://store.example.com/sending.swf
// Even though the receiving SWF uses full domain, the sending SWF
// only uses the superdomain
sendingLC.send('example.com:myConnection', 'myMethod');

Beware of using wildcards on LocalConnections

As a shortcut during the development phase, Flash supports the "*" wildcard to accept localConnections from multiple domains. Additionally, you can prepend a "_" on the connection name to make the connection globally accessible. These features should only be used for debugging during development. As a general rule, never allow these shortcuts to be present in production code since any SWF from any site can connect to the localConnection:

// receivingLC is in http://www.example.com/receiving.swf
// Doing this can be risky since ANYONE can connect!
receivingLC.allowDomain('*');
receivingLC.connect('_myConnection');
// sendingLC is in http://www.someotherdomain.com
sendingLC.connect('myConnection');

Use a multiple domain whitelist rather than wildcards in allowDomain

During testing, if you wish to avoid the wildcard feature, you can alternately write more complex logic for the allowDomain function that lists all of the allowed callers:

// For Flash Player 7 or later (AS2)
receiving_lc.allowDomain = function(sendingDomain) {
   return(sendingDomain=="www.domain.com" ||
      sendingDomain=="store.domain.com");
}
 
// For Flash Player 9 or later (AS3)
Receiving_lc.allowDomain("www.domain.com", "store.domain.com")

Be cautious when specifying allowDomain using LoaderInfo information

If the domain name of a loaded SWF is not known at compile time, these properties can be used dynamically to obtain the domain name instead of using a wildcard. However, keep in mind that in some cases, any site on the Internet can load the SWF:

// If the parent does not know the child domain
// This can be risky if you loaded using a FlashVar!
Security.allowDomain(loader.contentLoaderInfo.url)

// If the child does not know the parent domain
// Keep in mind that ANYONE can load your SWF!
Security.allowDomain(this.root.loaderInfo.loaderURL)

If you are working with files authored for Flash Player 7 or later, it is not possible to use this method to allow SWF files hosted using a secure protocol (HTTPS) allow access from SWF files hosted in nonsecure protocols. In this situation, the LocalConnection.allowInsecureDomain event handler can be used for these scenarios but it is not recommended.

Security considerations when using local shared objects

Related threats: Cross-domain privilege escalation, malicious data injection, unauthorized access to local data, insufficient authorization restrictions

To see details about working with local shared objects, see the documentation on SharedObjects for ActionScript 3.0 on Adobe LiveDocs.

If you'd like more information about working with third-party local shared objects, check out the article What are third-party local shared objects?

Local shared objects (LSOs) are a mechanism provided for persistent storage of small amounts of data. Access to this data is segmented by looking at three components: the domain hosting the SWF, the local path of the SWF and whether the SWF was loaded via HTTPS. The domain is always checked to ensure that one domain cannot access another domain's SWF data. The domain is also checked in situations where a domain is hosting third-party SWF files. End-users have the ability to change the default setting of Flash Player to deny third-party SWF files the ability to create local shared objects. If the user changes this setting, SWF files hosted on the same domain as the web page will be able to create local shared objects but any SWF files imported from another domain will not be able to create or access existing local shared objects.

Set the localPath variable carefully

Local shared object data is also segmented by the URL path. By default, the shared object is restricted to the full path in the URL which includes the name of the SWF file. This means that only the SWF file creating the shared object can access the shared object. However, permission to the shared object can be expanded to permit additional access based on path. For example, if the SWF file is located at http://www.mydomain.com/path1/path2/path3/my.swf, then the SWF can configure the shared object to allow access from other SWF files within /path1, /path1/path2, or /path1/path2/path3 by setting the initial localPath value to one of those three choices. Some designers will specify "/" when creating their local shared objects so that all the SWF files in the domain can share the same data. This setting is not recommended because you can create issues for developers in shared environments in cases where independent groups are all hosted under the same domain. If the SWF file will be hosted by a third-party that hosts content from other developers, it is a best practice to set the path value to restrict access to only your section of the website.

The code example below shows how to specify the localPath to the local shared objects:

// This will get the local shared object "userInfo" that is stored
// based on the full path of the SWF and is available to only SWF files
// served over HTTP
var mySO = SharedObject.getLocal("userInfo", "/path1/path2", false);

The secure flag can be used to protect shared objects

If you are working with SWF files that run in Flash Player 8 and later, an additional "secure" flag was added to shared objects so that SWF files served over HTTPS could create shared objects that are accessible only to other SWF files served over HTTPS from the same domain. This means that a SWF served over HTTP cannot access the secure shared object set by the SWF served over HTTPS—even if it is the same SWF file. The flag defaults to "false" so that any SWF from the same domain and path can access the shared object and to ensure that SWF files created prior to Flash Player 8 will not be affected.

The code example below describes how to access local shared objects across SWF files served over HTTPS from the same domain:

// This will get the local shared object "userInfo" that is stored
// based on the full path of the SWF and is available to only SWF files
// served over HTTPS
var mySO = SharedObject.getLocal("userInfo", null, true);

The data that is stored in a local shared object is kept in a serialized, binary format. However, the data is not encrypted. Local shared objects are not secure, as developers have created several free tools to read and write to local shared object files. Also, like cookies, shared objects are limited by are user-controlled settings. An end-user can choose to alter the storage size of local shared objects or choose to deny storage completely. For these reasons, local shared objects should not be used to store anything that cannot be destroyed or altered in your application:

static function getRemote(name:String, remotePath:String, persistence:Object, secure:Boolean) : SharedObject;

In addition to storing data locally in a local shared object, data can be stored remotely on a Flash Media Serve