Managing security boundaries

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. In addition, you may want to segment your content intentionally and enforce boundaries. The following sections describe how to manage security boundaries to be either more inclusive or exclusive.

Loading content as data 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 the connection 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. Lastly, Flash Player acknowledges the port used to load SWF content. Therefore, Flash will consider http://www.a.com:80 to be a different site than http://www.a.com:8080.

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 as raw data 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.

Segmenting SWFs from trusted content

In addition to incorporating many domain names into one security domain, it is also possible to split content into different security domains. This may be necessary if you host SWF files with different trust levels. One way that you can accomplish this is to 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. For instance, websites typically create cookies that they assign to their domain names but they rarely create cookies that are assigned to an IP address. In this example, the cookies created for www.example.com won't be sent along with a request to http://1.2.3.4/my.swf and therefore you do not need to worry about the malicious my.swf gaining access to the cookies. In order for this to work, it is important to verify that there are no example.com domain names that resolve via DNS to the IP address 1.2.3.4 in order to ensure complete separation between the content. If an attacker discovers that the domain foo.example.com resolves to 1.2.3.4, then the attacker may try to reload the malicious SWF using http://foo.example.com/my.swf in order to get access to domain cookies or other permissions within your domain. Another issue with hosting potentially untrusted SWF files on your domain is the possibility of phishing attacks.

If you use named-based virtual hosting, then you may not have the option of obtaining a second IP address. In this case, you could also register a second domain name for your content. Many large providers use this technique because IP addresses don't scale well in complex environments. Trusted content would be hosted off of http://www.example.com and untrusted content is hosted off of http://www.not-example.com.

Some people will try using a different sub-domain for untrusted content, but this approach still has risks. If you set cookies on your website that are accessible to all sub-domains of your site, then SWFs on a sub-domain may be able to access and alter them. Therefore, in this model, sensitive cookies would need to be created using the full domain name for which they apply so that sub-domain hosting the untrusted SWF content cannot access them. This may also have implications if local shared objects, camera, or microphone permission are granted to the super domain.

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, read the Permission controls section of the Programming ActionScript 3.0 for Flash documentation, Cross-domain policy file usage recommendations for Flash Player, and the Cross-domain policy file specification.

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 several aspects of access to the HTTP server:

• What domains are trusted to be within the same origin of the server
• Whether communication between HTTP and HTTPS content is allowed for the listed domain names
• Whether SWF files from other domains can send the server custom headers
• For Flash Player versions prior to 9,0,124,0, it implicitly grants socket access to ports greater than 1024 for SWF files hosted on the same domain as the 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:

• When performing image extraction, such as using Bitmap.draw() or Loader.content, is required to a movie or image from another domain
• When performing sound data extraction on sound loaded from another domain such as ID3Info and computeSpectrum
• When an image is being loaded in an HTML text field from another domain
• When data will be directly loaded via API calls such as LoadVars, URLLoader, or XML.load by another domain
• When import loading a remote SWF
• When a web administrator wants to explicitly block all cross-domain loading requests to their site
• When a SWF on a remote HTTP server needs to load data from within an HTTPS protected section of the server's website

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

• When an image or SWF from another domain is loaded for presentation as a child without accessing anything inside of it (content loading)
• When displaying or playing data from an RTMP server without trying to access video data or sound spectrum data
• When loading an image from the same domain as the loader
• When loading a remote SWF file, since cross-domain permissions for SWF-to-SWF communication are governed by other controls such as Security.allowDomain() or shared events

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:

• Placing sharable content on one sub-domain (public.mysite.com) and non-sharable content on another sub-domain (private.mysite.com)
• Using wildcards in conjunction with static domain information to limit the scope of the permissions
• Granting permissions based on sub-directory
• Using meta-policies to prevent unapproved cross-domain policy files
• Granting permissions only to SWFs loaded over HTTPS

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>

However, there are still some risks associated with this approach. If the site you are granting access to allows users to upload content to a sub-domain of their website, such as uploads.example.org, then a "*.example.org" permission would allow the end-user content to access your site as well. Depending on the permissions you are granting, allowing arbitrary third-party data that is hosted on uploads.example.org may be an unnecessary security risk. It is important that you thoroughly understand what type of content is hosted on the site to which you are granting access.

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. This practice is not recommended. For instance, you would probably not feel comfortable if unsecured HTTP content from your bank's website was able to reach into your secured connection with your bank to extract information. 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, you would want to avoid setting the secure flag to "false" for the entire website and instead place the cross-domain permission in a specific sub-directory. If you need to allow HTTP-loaded SWF files to communicate with HTTPS-loaded SWF files, then a cross-domain policy file with a secure flag of "false" is not necessary because cross-domain policy files do not govern SWF-to-SWF communication.

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>

Understanding ports vs. protocols

The secure flag within the cross-domain policy file tells Flash Player whether it should prevent cross-protocol communication between HTTP and HTTPS for the domain listed in the allow-access-from tag. It does not tell Flash Player to acknowledge any given port. Cross-domain policy files do not include the ability to restrict access based on the source port of the connection. If the cross-domain policy file allows access from www.example.org, then it will allow access to any SWF that was loaded over HTTP, whether or not the SWF was loaded from a server www.example.org:80 or a server listening on www.example.org:8080. If the above cross-domain policy file were hosted on https://www.mysite.com:8443/, then the secure flag would tell Flash Player that a SWF loaded from http://www.mysecuresite.org:8080/my.swf could not load its content because the SWF was loaded via a different protocol from the website.

Flash Player does pay attention to the port number of the server that is hosting the cross-domain policy file. If a web server has a policy file hosted on http://www.example.org:80/crossdomain.xml, then that policy file would not apply to the web server hosted on http://www.example.org:8080/. A separate cross-domain policy file would need to exist on the www.example.org:8080 website if that site wanted to permit other domains access to its content.

Allowing custom headers

Starting with Flash Player 9,0,124,0, Adobe introduced the capability to define which custom headers Flash Player can send across domains. These settings are defined by the allow-http-request-headers-from tag within the cross-domain file. Similar to other elements within the crossdomain.xml file, it is possible to set the domain attributes describing the sites that are allowed to forward headers using the full domain name of the remote domain, a wildcard, or a combination of the two. In addition, the secure attribute maintains the same meaning as it has within the allow-access-from described above. The headers attribute is where it is possible to define which headers are allowed to be sent to the domain hosting the cross-domain policy. Although wildcards are supported, we recommend that only the specific headers that are intended to be accepted be specified:

<?xml version="1.0"?>
   <!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
   <cross-domain-policy>
   <!-- This domain can accept the HTTP Request headers MyHeader and MyOtherHeader from a SWF file on www.example.com -->
      <allow-http-request-headers-from domain="www.example.com" headers="MyHeader,MyOtherHeader" secure="true"/>
   </cross-domain-policy>

Page 5 of 13

Previous Page

Next Page