Meta-policies

The primary change in support of the policy file control improvements in Flash Player 9,0,115,0 is the introduction of meta-policies. A meta-policy is a "policy on policies"—a designation by a server administrator as to what policy files are permitted to exist on a server.

For a quick, step-by-step guide to choosing a meta-policy for a server, see the workflow for meta-policies. However, we encourage anyone who maintains a server to read this introductory section first. This includes servers that do not expect to serve any Flash Player compatible content, as such servers can still be vulnerable to policy-file-based attacks.

Why have meta-policies?

As explained in the description of the policy file control improvements, the goal of meta-policies is to help ensure that policy files can only be created with proper authorization. But in order to choose a meta-policy, it is important to understand what policy files do, and what effects an unauthorized policy file can have (see Figure 1).

Figure 1. Data flow enabled by a policy file

In this diagram, the site b.com hosts a policy file that grants permission for a.com. This means that a SWF file from a.com can load data directly from some or all of the b.com site (how much depends on the policy file's location).

The administrator of b.com has to be careful with policy files, because they give permission for SWF files from other domains to operate with users' credentials when accessing b.com. In the diagram above, the user browses to a SWF file on a.com (1), or perhaps a SWF file from a.com is embedded in some other site, c.com (not shown). The SWF file from a.com obtains permission to load data from b.com using the policy file on b.com (2). Now the SWF file can load data from b.com (3), taking advantage of any credentials that enable the user to access b.com. If the SWF file wishes to, it can upload any data it finds on b.com back to its own server at a.com (4).

It is important here to compare, on one hand, the access credentials that the a.com server would have if it directly accessed b.com, and on the other hand, the access credentials that a user has to b.com. If the user is able to access b.com because they are inside a network firewall that b.com is also inside, or if the user is able to access b.com because they have provided a login and received an HTTP cookie, then the user has greater privileges than the a.com server. In this situation, it may be risky to create a policy file on b.com because then SWF files from a.com must be trusted not to disclose data that is private to b.com, the user, or both.

Given the potential of policy files to create this kind of data vulnerability, it is important for a server administrator to be able to limit the creation of policy files (thus avoiding vulnerabilities), and to easily find all policy files on the server at any given time (thus auditing the current set of permissions). Some servers may allow content contributions from personnel who lack administrative rights, and other servers may even serve content defined by end users. It is often not appropriate to allow these kinds of contributors to create policy files.

This is where meta-policies may help. By choosing an appropriate meta-policy, an administrator can completely prohibit the creation of policy files, completely allow the creation of policy files in any location, or take an intermediate approach, permitting only certain policy files by whatever criteria are desired.

Note that meta-policies are useful even for servers that do not expect to serve any Flash Player compatible content. If b.com is an HTML-only server inside a firewall, and someone has managed to create a policy file on b.com, then a SWF file from any site a.com on the Internet can attempt to retrieve data from b.com when a user with access to b.com views a SWF file from a.com. The same logic holds if b.com is a server on the Internet, but accepts login credentials. Thus, it benefits b.com to declare a meta-policy even though it does not expect to serve any Flash Player compatible content. (The likely meta-policy for such a server would be none, preventing any policy files from existing on that server.)

Scope of meta-policies

The following kinds of servers can declare meta-policies:

• HTTP and HTTPS servers. Each server makes its own meta-policy declaration, which does not affect other servers. For example, the meta-policy of an HTTP server at port 80 affects only that server, and not an HTTP server at port 8080 on the same host. Likewise, the meta-policy of an HTTP server does not affect an HTTPS server on the same host, or vice versa.
• FTP servers. Again, each server makes its own meta-policy declaration.
• Entire hosts can declare a socket meta-policy, which governs low-level socket connections to that host on all ports. Low-level socket connections are those initiated using the ActionScript Socket and XMLSocket classes. Higher-level connections to HTTP and FTP servers, using any ActionScript APIs other than Socket and XMLSocket, should not be impacted by socket meta-policies, only by the meta-policy of the particular server involved. We sometimes refer to HTTP, HTTPS, and FTP meta-policies as URL meta-policies to distinguish them from socket meta-policies. For more about socket meta-policies, see the section on socket policy files.

It is not currently necessary or useful to declare meta-policies, or create policy files, on servers other than the above types. The Flash Player networking primitives permit only connections to HTTP, HTTPS, and FTP servers, and directly at the socket level. SWF files can make connections to other types of servers using socket-level connections, but in this case, Flash Player is not aware of the higher protocol, and so makes the policy file check at the socket level, not at the higher level. (Flash Player does also permit connections to Flash Media Server using the RTMP family of protocols, but security works differently for RTMP, with the server, rather than Flash Player, making security decisions.)

Meta-policy options

The following meta-policies are available:

• all: All policy files are allowed. This meta-policy is appropriate only for servers that are on the public Internet and do not serve any content that requires login credentials.
• by-content-type: All policy files whose Content-Type is exactly text/x-cross-domain-policy are allowed. No other policy files are allowed. This meta-policy is only available for HTTP and HTTPS servers. Most HTTP servers provide flexible ways to decide how to assign a Content-Type, so this is the most useful option when it is desirable to permit some policy files, but not others. Common strategies for assigning the text/x-cross-domain-policy type are to specify it for individual locations, thus requiring administrator approval for each policy file; or to assign text/x-cross-domain-policy to any file whose name is crossdomain.xml, thus allowing policy files to exist anywhere, but making it easy to find such files, or filter them during uploads or other content-creation processes.
• by-ftp-filename: All policy files named crossdomain.xml (i.e., those whose URLs end with /crossdomain.xml) are allowed. No other policy files are allowed. This meta-policy is only available for FTP servers. The required filename cannot be customized.
• master-only: Only the master policy file, located at /crossdomain.xml, is allowed.
• none: No policy files are allowed. If this meta-policy is declared in the master policy file, then the master policy file is permitted to exist solely for the purpose of declaring this meta-policy, and any <allow-access-from> directives that it contains will be ignored.
• none-this-response: This is a special meta-policy that can only be specified in an HTTP response header. It helps prevents this particular HTTP response from being interpreted as a policy file. Unlike all other meta-policies, none-this-response affects only a single HTTP response, rather than declaring an overall meta-policy for the entire server. Also unlike all other meta-policies, none-this-response can appear in combination with any other meta-policy without conflict. When none-this-response and another meta-policy are both present, then the current HTTP response will not be allowed to be a policy file, but the additional meta-policy will be interpreted to be the overall meta-policy for the server. The none-this-response meta-policy is mainly useful when your server contains scripts that you do not want to allow to generate policy files. Since scripts can generally choose the Content-Type of their output, and generate arbitrary HTTP response headers, it would be difficult to filter script output looking for indications that the output represents a legal policy file. Instead, by appending a none-this-response meta-policy header to the output, you help make sure that whatever the script generates, it cannot generate a valid policy file. (In addition, if the script generates its own meta-policy HTTP response header, that cannot force the server to adopt a more open meta-policy than the one you specify, since meta-policy conflicts are always resolved by choosing the most restrictive meta-policy encountered.)

How to specify meta-policies

There are two ways to declare a meta-policy on an HTTP, HTTPS, or FTP server (socket policy files work differently):

• Declare the meta-policy in the master policy file for that server—the policy file located at /crossdomain.xml. A new tag called <site-control> is included inside the top-level <cross-domain-policy> tag, and an attribute of the <site-control> tag called permitted-cross-domain-policies specifies the particular meta-policy to be used. Here is an example policy file declaring a meta-policy of by-content-type:

  <cross-domain-policy>
     <site-control permitted-cross-domain-policies="by-content-type"/>
  </cross-domain-policy>

• Declare the meta-policy in an HTTP response header called X-Permitted-Cross-Domain-Policies. This option is not available on FTP servers. In order to be effective, this header must be returned with every HTTP response, because there is no reliable way to detect whether a request is or is not for a policy file. Here is an example HTTP response header declaring a meta-policy of none:

  HTTP/1.1 200 OK 
  X-Permitted-Cross-Domain-Policies: none

  If you need to specify two meta-policies (which is only legal when one of them is none-this-response), either provide the X-Permitted-Cross-Domain-Policies header twice, or provide it once with the meta-policy values separated by a semicolon. Both arrangements are standard practice for HTTP headers.

You should choose only one of the two mechanisms to declare a meta-policy. However, if you accidentally declare a meta-policy in both places, the meta-policy declared in the HTTP response header will take precedence over the meta-policy declared in the master policy file.

Each of the two approaches has advantages. Considerations include:

In favor of declaring meta-policies in the master policy file:

• It is usually simpler to edit the master policy file than to return a new HTTP response header.
• The master policy file technique works for both HTTP and FTP.
• The master policy file technique avoids introducing an additional header to every HTTP response from the server.

In favor of declaring meta-policies in an HTTP response header:

• It is not always possible to create a master policy file in the server's document root directory.
• If a meta-policy is declared in the master policy file, but a non-master policy file is requested, Flash Player must retrieve the master policy file before accepting the non-master policy file. But if a meta-policy is declared in an HTTP response header, the extra request for the master policy file is not needed.
• The server configuration needed to declare a meta-policy in an HTTP response header can generally be managed in a single server configuration file, without any need to alter any servable document content.
• The none-this-response meta-policy can be provided to control the ability of scripts to generate policy files.

On HTTP and HTTPS servers, there is a rule to be aware of: if you do not explicitly declare a meta-policy in an HTTP response header or the master policy file, but you return any policy file with a Content-Type of text/x-cross-domain-policy, this will cause Flash Player to assume a meta-policy of by-content-type. This is not a good way to declare a meta-policy—just a fact to be aware of in case you accidentally end up in this situation.

Default meta-policies

If a server does not declare a meta-policy, there are two possible results:

• In Phase 1, which began with Flash Player 9,0,115,0, the default meta-policy is all. This favors compatibility, helping ensure that sites continue to operate unaffected until a meta-policy is explicitly chosen.
• In Phase 2, which began with Flash Player 10.0, the default meta-policy is master-only. This favors security while still maintaining a high level of compatibility with existing content. A site must explicitly choose a meta-policy before any of its contents other than the master policy file can be used as a policy file.

When Flash Player runs inside a browser, enforcement of meta-policies is dependent on Flash Player being able to read HTTP response headers from the browser's networking stack. Most recent browsers enable this, but some older browsers do not. For a list of browsers that are and are not expected to support HTTP response headers, see Appendix A. If Flash Player finds that it cannot read HTTP response headers, a warning message will be generated in the policy file log, and a meta-policy of all will be assumed for all domains. Note that when Flash Player cannot read HTTP response headers, all meta-policy declarations are ignored, including those that appear in master HTTP policy files rather than in HTTP response headers.

Why action is needed

There are two reasons to declare a meta-policy on your server:

• If your server serves any non-master policy files, and you do not declare a meta-policy permitting those policy files, then they will stop working for users who install a Phase 2 version of Flash Player (Flash Player 10.0 or later).
• Whether or not your server deliberately serves policy files, or even any Flash Player compatible content at all, anyone with the ability to create text files on your server can create a policy file, which may then be used to disclose data that is private to your server, your users, or both. Declaring a meta-policy ensures that the default meta-policy of all is not applied for users of Phase 1 versions of Flash Player.

The workflow for declaring a URL meta-policy takes you through the steps necessary to choose and apply a meta-policy.

Page 3 of 7

Previous Page

Next Page