1 October 2008
This article refers to Flash Player 9 Update 3 (9,0,115,0), Flash Player 9 April 2008 Security Update (9,0,124,0), Flash Player 10.0 (1,0,2,xx and later) and Flash Player 11.x.
For more information on the structure of cross-domain policy files used to permit the sharing of data by client-side applications across domains, refer to Cross-domain policy file specification. For information on serving socket policy files from Linux and Windows hosts, you may find Setting up a socket policy file server very helpful.
Note: This article was updated in October 2008. There are only three substantial changes to be aware of: Flash Player 9,0,124,0 has implemented fully strict behavior for sockets (Phase 1.5); Flash Player 10.0 has implemented Phase 2 of the new restrictions; and the Phase 2 default URL meta-policy has been changed from the maximally restrictive none to the less restrictive master-only, permitting URL master policy files (those at /crossdomain.xml) to continue working without the introduction of a meta-policy.
In 2003, Flash Player 7 software introduced a channel of client-server communication that was new to the web: direct cross-domain data loading, authorized by policy files. Before policy files, web content could only perform two-way communication with its own server, such as runtime configuration or transactions without page reloads. Policy files allowed servers to open up their data selectively to client content from other domains, or generally to content from anywhere. Since the introduction of policy files, domain boundaries have been less of a barrier for authors of rich Internet applications.
Like most new technologies, policy files weren't perfect when they were first introduced. After four years, the Internet security community has found two undesirable situations (described later in this article) that can arise from the existence of policy files. The basic premise of policy files remains valid, and Flash developers can continue to rely on policy files just as they have since Flash 6. To address the new concerns, however, Adobe is specifying some stricter rules for the use of policy files. Additionally, there are a number of improvements that make policy files more useful and usable. We will try to explain the reasons for our changes clearly and simply.
This article assumes some familiarity with policy files. For a detailed introduction to policy files, see the Flash Player Security chapter of Programming ActionScript 3.0 on Adobe LiveDocs; Cross-domain policy file usage recommendations for Flash Player; and the Cross-domain policy file specification. For information about HTTP header-sending permissions in policy files, which is not covered in this article, see the relevant section in Understanding Flash Player 9 April 2008 Security Update compatibility.
To conform to the stricter rules, websites that serve policy files will need to make some minor changes. These changes are mainly for the protection of those sites themselves—essentially a new set of security best practices concerning policy files.
For most sites, we don't expect the changes to be difficult—but because of the large number of sites impacted, Adobe implemented the stricter requirements in Flash Player in three phases. In Phase 1, which began with Flash Player 9,0,115,0, a small number of strict rules were enforced immediately, but most violations of the strict rules resulted only in warnings visible in Debug versions of Flash Player. In Phase 1.5, which began with Flash Player 9,0,124,0, the warnings of Phase 1 became errors in the specific case of socket operations. In Phase 2, which began with Flash Player 10.0, all of the warnings of Phase 1 became errors and the transition to stricter rules was complete.
We recommend that website administrators follow these steps:
Two issues are addressed by the stricter policy file rules:
Policy file control. There is a possibility that a file on a server that does not appear to be a policy file may in fact be used as a policy file. For example, if a server permits uploads by users, but does not intend to open data for cross-domain access, it is possible that a user could deliberately construct a policy file but disguise it as a different type of file, such as an ordinary text, XML, or HTML file, or even as a binary type, such as a PNG or JPEG image file. A user who successfully uploaded this disguised policy file could then write a SWF file that takes advantage of the disguised policy file to load data from outside the server's domain. Similarly, a site maintainer with limited privileges could add a policy file to the site against an administrator's wishes, or even accidentally create a policy file they did not intend to. This issue is essentially one of controlling what policy files are permitted to exist on a server. Server administrators should be able both to set a server-wide policy on policy files (we call this a meta-policy), and to easily search for all policy files on their server, allowing auditing of all cross-domain permissions present on the server. The stricter policy file rules in Flash Player allow meta-policy declarations by server administrators, and perform greater sanity checking on policy files to help ensure that they are properly formatted.
DNS hardening. A class of cross-site scripting attacks known as DNS rebinding can target Flash Player, as well as browsers, virtual machines, and other user-agent programs. A DNS rebinding attack exploits a user-agent's same-origin policy, in which content from a given Internet domain is permitted to load and communicate with other resources in its own domain without explicit permission. An attacker who controls their own domain, and runs their own DNS server, can dynamically reconfigure their DNS server so that a given domain name resolves first to an IP address under the attacker's control (which may be used to serve a malicious SWF file or other content), then later to a different IP address that the attacker does not control. If the user-agent program does not detect the change in IP addresses, its same-origin policy will permit the attacker's content to access the second IP address without permission from the second host. Flash Player relies on browsers to provide HTTP networking, so any rebinding vulnerabilities that involve only HTTP must be solved in browsers. However, Flash Player also provides socket-level networking (via the ActionScript Socket and XMLSocket classes), and the strict policy file rules in Flash Player 9,0,115,0 help mitigate DNS rebinding vulnerabilities as they pertain to sockets. Specifically, the strict rules always require permission from a socket policy file in order to make a socket connection, even when the socket server appears to be the same as a connecting SWF file's domain of origin. In addition, beginning with version 9,0,115,0, Flash Player matches socket connections to their corresponding socket policy files based on IP addresses, not just domain names.
While addressing the above issues, we have also added some new features to make policy files more useful and usable:
localhost sockets may now specify that only HTTPS SWFs from given domains may connect, using the secure="true" declaration previously reserved for HTTPS policy files. This can help secure hybrid applications that couple online Flash content with native local applications.While most of the Policy file changes in Flash Player 9,0,115,0 generated only developer warnings, a few of the changes immediately resulted in changed functionality that may prevent SWF applications from working as intended. We made these immediate changes only for patterns of behavior that we believed were highly unlikely to occur in legitimate content. Still, we realize some legitimate content was affected.
For a quick, step-by-step guide to finding and fixing problems resulting from immediate strictness, see the workflow for immediate issues. However, we encourage anyone who may be affected (which is anyone responsible for SWF content) to read this introductory section first.
Unlike all other changes described in this article, Flash Player's restrictions on malformed policy files were not new to version 9,0,115,0. These restrictions have been enforced since version 9,0,47,0. However, starting in version 9,0,115,0, problems resulting from these restrictions should be easier to find due to the new logging mechanism.
Flash Player now rejects any policy file whose contents are not properly formatted. Invalid formatting can result from:
<cross-domain-policy> tag or after the closing </cross-domain-policy> tag. Note that this kind of extraneous content actually makes a file invalid as an XML document.<cross-domain-policy>.Flash Player rejects malformed policy files as part of the policy file control improvements. A malformed policy file can sometimes be an indication that Flash Player might be seeing a file that a website administrator did not intend to be usable as a policy file.
Adobe now provides XML Schema documents that you can use to validate policy file tags and formatting, if you wish. (This is an optional step, and if you're not familiar with XML Schema documents, you can safely skip it.) The schemas appear here:
PolicyFile.xsd is a generic schema for all policy files. The other four schemas restrict policy file syntax further for various protocols.
As with all issues of immediate strictness, follow the workflow for immediate issues to determine whether your SWF content is affected by malformed policy files. If you do find reports of malformed policy files in your logs, you (or whoever controls the affected policy files) should edit the policy files to remove any extraneous content, correct misspellings, etc.
Since policy files were introduced, Flash Player has always ignored a policy file if an HTTP server returned a redirect to another domain when the policy file was requested. However, within-domain redirects were allowed, and Flash Player would consider a policy file's effective location to be its initially requested URL, even if the request for the policy file was redirected to a different location on the same server. The effective location of a policy file is important, because it dictates the scope of the policy file—the set of resources to which the policy file allows access. For example, a policy file located at http://example.com/directory1/crossdomain.xml would permit access to resources located at http://example.com/directory1/ and below, but not to resources in other locations on the same server, such as http://example.com/elsewhere/. In general, Adobe recommends against using redirects for policy files, as they can make it more difficult to predict the effective permissions on a site.
Starting with version 9,0,115,0, Flash Player will still accept policy files that are delivered with same-domain redirects, but will use the final URL, rather than the initial URL, as the effective location of a redirected policy file. For example, if the location http://example.com/forks/crossdomain.xml is redirected to http://example.com/spoons/crossdomain.xml, the resulting policy file will permit access to http://example.com/spoons/ and below, but not to locations under http://example.com/forks/.
Flash Player uses final redirected URLs as part of the policy file control improvements. Administrators should be able to easily determine the set of policy file permissions on a server. But if the initial URL of a redirect is used as its effective location, then the existence of a policy file could be simulated anywhere on the site by creating a redirect. By using only final URLs as effective locations, Flash Player helps ensure that only deliberate and obvious policy files can be used. A redirect will only cause an already established policy file to be loaded, rather than altering the permissions on a site.
Hopefully, redirected policy files are rare, but as with all issues of immediate strictness, follow the workflow for immediate issues to determine whether your SWF content is affected by policy file redirects. If you do find reports of policy file redirects in your logs, that by itself is not necessarily an indication that content will not function as intended, but it can serve as a clue if a later operation that was intended to be allowed is not allowed.
It is particularly problematic to redirect requests for the master HTTP policy file location, at /crossdomain.xml. Doing so will strip the resulting policy file of its status as master. It will then be impossible for that site to have a master policy file at all, which hinders common operations like declaring a meta-policy.
Starting in version 9,0,115,0, Flash Player will ignore any HTTP policy file that is not sent with a Content-Type value that gives some assurance that the file is intended to be a text file. Flash Player requires that a policy file's Content-Type must be one of the following:
text/* (any text type)application/xml or application/xhtml+xmlContent-Type values are determined from the response headers provided by HTTP servers. Servers may choose a Content-Type based on a file's name, extension, location, contents, or the instructions of a server script generating the file. If you need to change the Content-Type associated with a policy file, you may need to reconfigure a registry mapping filename extensions to Content-Type values, or edit a general server configuration file. Consult the documentation for your HTTP server.
As with all issues of immediate strictness, follow the workflow for immediate issues to help determine whether your SWF content is affected by non-textual Content-Type values, and for steps you can take to change Content-Type values on several popular HTTP server platforms. If you find that you need to solve a Content-Type issue, be sure to also consult the section on meta-policies, because a common way to choose a meta-policy is to designate the special Content-Type of text/x-cross-domain-policy for all policy files, which may solve two problems at once—establishing a meta-policy and providing a textual Content-Type.
Flash Player requires textual Content-Type values as part of the policy file control improvements. A policy file with a non-textual Content-Type can sometimes be an indication that Flash Player might be seeing a file that a website administrator did not intend to be usable as a policy file.
When Flash Player runs inside a browser, enforcement of the Content-Type whitelist 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 policy files will be accepted regardless of their Content-Type, or even if they have no Content-Type at all.
Note: This section provides historical information only. Since the release of Flash Player 9,0,124,0, which implemented Phase 1.5 of strict policy file rules, all sockets have been treated with strict rules. This section only describes differences between Flash Player versions 9,0,115,0 and 9,0,124,0, which are now largely unimportant to maintainers of socket servers, since servers must now be prepared to encounter version 9,0,124,0 or later.
Starting in version 9,0,115,0, Flash Player defines a set of stricter rules for socket policy files. Socket policy files authorize ActionScript language connections to socket servers. The strict rules are described in detail in the section on socket policy files, but in brief, they state that permission from a socket policy file is always required in order to make any ActionScript socket connection. The previous rules permitted SWF files to make socket connections to high-numbered ports in their own domain without a policy file, and permitted any SWF file to connect to a high-numbered socket port based only on an HTTP policy file. These situations are no longer permitted under the strict socket rules.
For most socket servers, the strict rules were rolled out in two phases, with violations generating only warnings in Phase 1, unless hosts opted in to the new rules. However, for a few special kinds of sockets, the strict rules were applied immediately, even in Phase 1. These were:
localhost in ActionScript. Local sockets are those at loopback addresses (127.0.0.1 in IPv4, ::1 in IPv6) and at locally assigned outward-facing addresses (such as the address assigned to an Ethernet adapter). This rule forms part of Flash Player's DNS hardening improvements. The system of opting in to strict socket rules is appropriate for server hosts, but not for local machines, which most users do not treat as servers. This rule helps prevent malicious DNS servers from resolving a host name first to a remote address (to deliver a SWF file), then later to a local address (to connect to a local service). The special name localhost is exempted from this rule because there is generally no possibility of remote DNS being involved in resolving localhost.*.local (any name ending in .local) in ActionScript. Link-local IP addresses are those assigned only on a single link (one network segment, such as a point-to-point connection or a network hub). Link-local addresses are often used for "zero-configuration" peer-to-peer networking. They take the form 169.254.* in IPv4, and fe80:* in IPv6. This case is very similar to the local case above. The .local exemption reflects the fact that there is generally no possibility of remote DNS being involved in resolving a .local address.As with all issues of immediate strictness, follow the workflow for immediate issues to determine whether your SWF content is affected by immediately strict sockets, and for steps to remedy any problems you find.
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.
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).
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.)
The following kinds of servers can declare meta-policies:
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.)
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.)There are two ways to declare a meta-policy on an HTTP, HTTPS, or FTP server (socket policy files work differently):
<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>
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:
In favor of declaring meta-policies in an HTTP response header:
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.
If a server does not declare a meta-policy, there are two possible results:
all. This favors compatibility, helping ensure that sites continue to operate unaffected until a meta-policy is explicitly chosen.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.
There are two reasons to declare a meta-policy on your server:
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.
Most networking in ActionScript is URL-based, using HTTP, HTTPS, and FTP. However, ActionScript also supports the Socket and XMLSocket classes, which enables networking directly at the lower TCP socket level. Whereas URL networking is authorized by URL policy files, ActionScript socket-level connections are authorized by socket policy files.
Flash Player 9,0,115,0 and 9,0,124,0 introduce several changes to the way socket policy files work. These changes are primarily to support the goal of DNS hardening, helping to ensure that ActionScript cannot be used as a means for a DNS rebinding attack that results in an unauthorized socket connection.
For a quick, step-by-step guide to implementing a valid socket policy file configuration for a host, see the workflow for socket policy files. However, we encourage anyone who maintains a server host to read this introductory section first. This includes hosts that do not expect to serve any Flash Player compatible content, as such hosts can still be vulnerable to socket-based DNS rebinding attacks.
This section builds on the previous section on meta-policies, so be sure you've read that first.
This background section provides information that has been true since the introduction of socket policy files in Flash Player 7,0,19,0.
Socket policy files serve the same purpose as URL policy files: they authorize connections from client content. A URL policy file authorizes data loading from its own HTTP, HTTPS, or FTP server, whereas a socket policy file authorizes socket connections to its own host.
Note: We use the terms "URL policy files", "URL meta-policies", etc., to refer to networking over HTTP, HTTPS, and FTP. This is despite the fact that socket policy file locations can be expressed using URLs, for example as xmlsocket: URLs when calling loadPolicyFile from ActionScript.
All policy files have two essential attributes: permissions (the list of domains authorized to connect) and scope (the set of resources to which access is allowed). Socket policy files work identically to URL policy files as far as permissions are concerned, but socket policy file scopes work differently than URL policy file scopes.
The scope of a URL policy file is determined by its location, but the scope of a socket policy file is determined by the file's contents—specifically, by to-ports attributes that specify the TCP ports to which socket connections may be made.
A socket policy file may be served from any TCP port on a host, but a socket policy file from port 1024 or above may only authorize connections to ports 1024 and above. A socket policy file from a port below 1024 may authorize connections to any port on the host.
Socket policy files may be obtained from the same port as a main connection (the socket connection being made by ActionScript, which is authorized by a socket policy file), or from a different port, separate from the main connection. If you opt to serve a socket policy file from the same port as a main connection, the server listening on that port must understand socket policy file requests (which are indicated by a transmission of <policy-file-request/> from Flash Player), and must respond differently for policy file requests and main connection requests. It is usually easier to serve socket policy files from a separate port, because this centralizes the socket policy for a host in one place, and because most servers are not equipped to serve their own socket policy files.
Since policy files were first introduced, Flash Player has recognized /crossdomain.xml as a master location for URL policy files. However, prior to version 9,0,115,0, Flash Player did not recognize a fixed master location for socket policy files. Flash Player 9,0,115,0 introduces a concept of socket master policy files, which are served from the fixed TCP port number 843.
Socket master policy files serve several needs:
loadPolicyFile to inform Flash Player of the location of a socket policy file.Note: Setting up a socket policy file server provides a brief background on the latest Flash Player socket functionality, as well as sample code for creating socket policy file servers in testing environments.
Adobe is applying with IANA, the Internet Assigned Numbers Authority, to reserve TCP port 843 for the purpose of serving socket policy files. This process may take a long time, but in the meantime Adobe is documenting this intended use of port 843 as broadly as possible.
Because port number 843 is below 1024, socket master policy files can authorize access to any port on a host. The 1024 boundary is important on Unix-style hosts, because typically such hosts require root access (i.e., administrative privileges) in order to bind a server to a port below 1024. This means that setting up a socket master policy file on a Unix-style host will typically require root access, which is a good protective measure for such hosts.
See the section on firewall traversability if you are concerned about serving socket master policy files through firewalls.
Socket meta-policies are similar to URL meta-policies. There are a few differences:
<site-control> tag. Socket meta-policies cannot be declared in HTTP response headers, as HTTP is not involved.The available socket meta-policies are:
all: Socket policy files are allowed from any port on this host. This meta-policy is appropriate only for hosts that are on the public Internet and do not serve any content that requires login credentials.master-only: Only the socket master policy file, served from port 843, is allowed on this host.none: No socket policy files are allowed on this host. 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.The default socket meta-policy is all. Flash Player will assume the meta-policy all for any host that does not serve a socket master policy file that declares a socket meta-policy. The default of all applies to both Phase 1 and Phase 2 implementations of Flash Player. This differs from the way URL policy files work—the default URL meta-policy for Phase 2 is master-only.
Thus, socket policy files have a different, more permissive default meta-policy than URL policy files. This is because sockets are much less likely than URL servers to experience a risk of unauthorized policy files. It is not uncommon for HTTP servers, for example, to serve user-generated content, or content created by personnel other than server administrators—so it makes sense to have (in Phase 2) a default URL meta-policy of master-only, thus helping ensure that administrators have proactively enabled policy files before anyone can create them. However, it would be much less common for a host to permit unauthorized users to install or modify entire servers listening on TCP ports, so it makes sense to have a default socket meta-policy of all, thus helping ensure that socket policy files can be created anywhere on a host unless an administrator specifically forbids it.
The primary change in support of the DNS hardening improvements in Flash Player 9,0,115,0 is the introduction of strict socket rules. These rules are:
These two rules can be summed up in a simple statement: under the strict socket rules, every socket connection requires permission from a socket policy file.
Like most of the policy file changes Flash Player 9, the strict socket rules were deployed in two phases. In Phase 1, which began with Flash Player 9,0,115,0, violations of the strict policy file rules resulted only in warnings that are visible to Flash developers using Debug versions of Flash Player. In Phase 1.5 , which began with Flash Player 9,0,124,0, these warnings became errors, possibly causing SWF files depending on the older rules to stop functioning as intended. Staring from Phase 1, host administrators have had the opportunity opt into the strict rules, helping ensure that their sites are protected against DNS rebinding attacks even for users who have Phase 1 versions of Flash Player.
The workflow for socket policy files provides details to help you find and solve issues that result from the introduction of strict socket rules. In brief, if you maintain any SWF files that make socket connections in one of the two situations described above, you will need to ensure that the host to which you are connecting serves a socket policy file. The usual way to do this is to set up a socket master policy file server on port 843, but see the workflow section for other options.
For Phase 1 versions of Flash Player, the following configurations will cause a host to use strict socket rules. This is important information both for host administrators, who can opt into the more secure rules for their own protection, and for maintainers of SWF files, who should understand the effects that these configurations may have on the ability of their SWF files to make socket connections.
all, the host will still use strict socket rules. All socket connections to this host will require permission from a socket policy file, which will most likely be the same socket master policy file that is triggering the transition to strict socket rules. This is the usual mechanism that host administrators should use to opt into strict socket rules.Since policy files were introduced, Flash Player has supported a special attribute in the <allow-access-from> directives of policy files from HTTPS servers: secure="true". When secure="true" is specified, SWF files from the domain or domains listed in that <allow-access-from> directive are permitted to retrieve data only if those SWF files are themselves retrieved over HTTPS. This helps protect the data from HTTPS servers, and helps ensure that it does not flow to SWF files whose origin cannot be strongly authenticated. (A SWF file that is served over HTTPS is much harder to forge than a SWF file that is served over HTTP, because of the domain-authentication and tamper-resistance technologies built into HTTPS.) The default behavior for HTTPS policy files is in fact secure="true"; in order to override it, HTTPS policy files must explicitly declare secure="false", which Adobe recommends against.
Starting with version 9,0,115,0, Flash Player supports the secure="true" declaration in a new situation: in socket policy files from local sockets (i.e., from socket servers running on the same computer as Flash Player). When secure="true" is declared in an <allow-access-from> directive from a local socket policy file, SWF files from the domain or domains listed in that <allow-access-from> directive are permitted to connect to the allowed ports only if those SWF files are retrieved over HTTPS. Here is an example of a local socket policy file using this feature:
<cross-domain-policy>
<allow-access-from domain="my.com" secure="true" to-ports="3050"/>
</cross-domain-policy>
The only permission granted by such a policy file would be for a SWF file loaded over HTTPS from my.com to connect to port 3050. A SWF file loaded over HTTP from my.com would not be granted any permissions by this particular policy file.
The domains listed with secure="true" declarations are called secure domain lists.
Secure domain lists in local socket policy files are potentially useful for hybrid online/offline applications. Imagine that an application installs a native local component on users' machines, provides an online SWF interface via a web browser, and uses an ActionScript socket connection to communicate between the web SWF and the local component. In this scenario, the application developer would want to ensure that only their particular SWF files could communicate with the local component; otherwise, other SWF files on the web could potentially commandeer the native functionality of the local component. If the developer of this application posted all their SWF files to an HTTPS server on my.com, and served the socket policy file shown above from their local component, including the secure="true" declaration, this would prevent all but the application developer's own SWF files from connecting to the local component.
In order to take advantage of secure domain lists, local application developers must make sure their users have a Flash Player of at least version 9,0,115,0 installed. Otherwise, the secure="true" directive will be silently ignored.
Adobe recommends against using the secure="true" directive in socket policy files that are not served from local sockets (i.e., from socket servers running on the same computer as Flash Player). Flash Player will generate warnings in the policy file log if it finds secure="true" in a socket policy file that does not appear to have come from the local host. Flash Player will in fact honor secure="true" in non-local socket policy files, but only because it is not possible for Flash Player to detect with 100% reliability whether a socket connection is to the local host or not.
It is important to understand why it may be insecure to declare secure="true" in a socket policy file that does not come from the local host. As of this writing, Flash Player does not provide secure socket-level networking—there is no equivalent of HTTPS at the socket level yet (this support would be called SSL/TLS at the socket level). This means that socket policy files are always retrieved without the benefits of SSL/TLS. Socket policy files are thus vulnerable to man-in-the-middle attacks, where a third party on the network between client and server can change the contents of a network conversation without either client or server knowing that this has occurred. So, if a socket policy file from a non-local socket declares secure="true", a man-in-the-middle attacker can simply substitute secure="false". Declaring secure="true" in a non-local socket policy file therefore may provide a false sense of security that Flash Player cannot reliably enforce. (It is for this same reason that secure="true" is not permitted in HTTP policy files either—only in HTTPS policy files.) However, if secure="true" is declared in a local socket policy file, there is no off-host networking involved in transferring the socket policy file from its server to Flash Player. This is why secure="true" makes sense in local socket policy files.
One important change to socket policy files in Flash Player 9,0,115,0 is invisible to ActionScript and requires no changes in content.
Prior to version 9,0,115,0, if Flash Player found a socket policy file from some domain a.com, that policy file could be used to authorize any socket connection to a.com. This left open the possibility that, due to a DNS rebinding, a.com might have referred to a different host at the time of the socket connection than it did at the time of the policy file retrieval, thus allowing one host to specify the permissions for a different host.
Starting with version 9,0,115,0, Flash Player always checks that, before a socket connection is allowed, a socket policy file has been retrieved from the same IP address as the host to which the connection is being made.
Flash Player 9,0,115,0 may cause hosts to see some slightly different traffic than they are accustomed to, and Flash Player contains some accommodations for the differences. The differences include:
XMLSocket connection, and permission for the connection has not already been obtained from a socket master policy file or a policy file whose location has been specified with loadPolicyFile, Flash Player will attempt to retrieve a policy file from the same port as the main connection before it attempts the older behavior of looking for an HTTP policy file on port 80 of the same domain as the main connection. (The default policy file checks for ActionScript 3.0 socket connections are not changing; checking the same port as the main connection has always been the default for ActionScript 3.0 socket connections.)For any socket policy file that Flash Player requests automatically, if the host does not either answer or reject the connection attempt within 3 seconds, Flash Player will abort the attempt, assume there is no policy file at that location, log a warning in the policy file log, and move on to the next stage of socket policy file authorization. This timeout behavior helps protect Flash Player against waiting too long for a socket connection that will never succeed, but it does somewhat reduce Flash Player's robustness to temporary network outages, slow connections, heavily loaded servers, etc. If you know that a certain socket policy file, which Flash Player would otherwise automatically request, is available, you can avoid the 3-second timeout behavior by explicitly calling loadPolicyFile from your SWF file, providing the URL of that socket policy file. This will cause Flash Player to be patient in its attempt to retrieve that policy file, avoiding timeouts until the TCP timeout of 2 minutes expires. For example, if you know that the master socket policy file on port 843 of mysite.com is available, and you are seeking to avoid 3-second timeouts while Flash Player attempts to retrieve it, you could call loadPolicyFile("xmlsocket://mysite.com:843") from ActionScript.
A disadvantage of socket master policy files is that they require clients to be able to access port 843. Some users behind restrictive outbound firewalls may not have this capability.
Adobe believes that outbound firewalls have good reason to permit access to port 843: this enables Flash Player to help enforce security policies declared by host administrators, and the effort to standardize the purpose of port 843 should ensure that other types of servers are not bound to that port. However, socket master policy files are a new concept, and it will take time for firewall rule sets to incorporate access to port 843. This is also a matter that must be left to the discretion of individual firewall administrators, who may choose not to permit access to port 843. We will show why this should generally not cause serious problems for Flash Player users or for server hosts.
Lack of access to port 843 has the following consequences:
These consequences may sometimes cause minor problems, but Adobe does not believe they should cause major problems. Here is why:
There are two reasons to serve a socket policy file (probably a socket master policy file from port 843) on your host:
The workflow for configuring socket policy files takes you through the steps necessary to serve a master socket policy file from your host.
The following procedures should help you quickly address any issues relating to the policy file changes in Flash Player 9,0,115,0, Flash Player 9,0,124,0, or Flash Player 10.0. Adobe recommends using these sections as a reference after reading the corresponding introductory sections earlier in this article.
Flash Player 9,0,115,0 introduces policy file logging, a new feature. The policy file log shows messages for every event relating to policy files—attempts to retrieve them, successes and failures in processing them, the fates of the requests that depend on them. A complete reference to the messages you will find in the policy file log can be found in Appendix B.
To use the policy file log:
mm.cfg configuration file. This is a general debugging configuration file that Debug versions of Flash Player read on startup. mm.cfg is located in your "home" directory; here are some typical examples:Windows: C:\Documents and Settings\username
Windows Vista: C:\Users\username
Macintosh: /Users/username
Linux: /home/username
mm.cfg if it does not exist, then add one or both of the following lines to it:PolicyFileLog=1 # Enables policy file logging
PolicyFileLogAppend=1 # Optional; do not clear log at startup
If PolicyFileLogAppend is not enabled, each new root-level SWF will clear the log file. If PolicyFileLogAppend is enabled, the previous contents of the log file will always be kept, and the log file will grow at the end.
If many different root-level SWF files are loaded during your testing, you will probably want to enable PolicyFileLogAppend. However, if you enable PolicyFileLogAppend, you will probably need to manually rename or delete the log file from time to time, since otherwise it will grow enormous, and it will be difficult to determine where previous output ends and new output begins.
Windows: C:\Documents and Settings\username\Application Data\Macromedia\Flash Player\Logs
Windows Vista: C:\Users\username\AppData\Roaming\Macromedia\Flash Player\Logs
Macintosh: /Users/username/Library/Preferences/Macromedia/Flash Player/Logs (it is unconventional for a program to write log files to the Preferences directory, but that is in fact the case)
Linux: /home/username/.macromedia/Flash_Player/Logs
Logs directory. Verify that it has a recent modification time. Open it and verify that at least one message appears ("Root-level SWF loaded"). If so, policy file logging is working.As described in the section on immediate strictness, a few of the changes in Flash Player 9,0,115,0 will affect SWF content immediately, possibly causing undesired behavior in a small percentage of SWF files. If you maintain SWF content, then as soon as possible, you should do the following:
[strict]. This label is an indication of a potential immediate issue.If you need to uninstall Flash Player to downgrade to an older version, use the Flash Player Uninstaller. Due to security features in the ActiveX control, you will need to run the uninstaller using the "/clean" command:
uninstall_flash_player.exe /clean
To obtain an earlier version of Flash Player to test with, visit this TechNote: Archived Flash players available for testing purposes.
[strict] messages that you find in your policy file log. These messages can include:Content-Type declared by the server, and will be ignored, possibly causing cross-domain access to be denied. See this log message explanation and the section on the Content-Type whitelist.Content-Type declared by the server, and will be ignored, possibly causing cross-domain access to be denied. See this log message explanation and the section on the Content-Type whitelist.localhost. Strict socket rules are being applied immediately, and access is denied. See this log message explanation and the section on immediately strict sockets.As described in the section on meta-policies, there are two reasons you should choose and declare a meta-policy on an HTTP, HTTPS, or FTP server:
all is not applied for users of Phase 1 versions of Flash Player.If you are operating a site on a server that you do not administer, be sure to read the section on considerations for users of hosted services.
To configure a meta-policy on a server that you control:
none.all, and if you choose by-content-type, this helps ensure that the criteria for assigning a Content-Type of text/x-cross-domain-policy are impossible for user-defined content to satisfy.all.master-only, and help ensure that only trusted personnel can alter the contents of the master policy file at /crossdomain.xml.by-content-type, and assign a Content-Type of text/x-cross-domain-policy for individually specified locations. Here is an example of an Apache configuration snippet to achieve this:<Location /crossdomain.xml>
ForceType text/x-cross-domain-policy
</Location>
<Location /another/place/crossdomain.xml>
ForceType text/x-cross-domain-policy
</Location>
by-content-type, and assign a Content-Type of text/x-cross-domain-policy for any location that meets your criteria. Here is an example of an Apache configuration snippet to achieve this:<Files crossdomain.xml>
ForceType text/x-cross-domain-policy
</Files>
none-this-response to the output of any such scripts. Here is an example of an Apache configuration snippet to achieve this:<Location /cgi-bin>
Header set X-Permitted-Cross-Domain-Policies none-this-response
</Location>
<site-control> tag into the master policy file at /crossdomain.xml. Here is an example:<cross-domain-policy>
<site-control permitted-cross-domain-policies="by-content-type"/>
</cross-domain-policy>
X-Permitted-Cross-Domain-Policies header. Here is an example of an Apache configuration snippet to achieve this:<Location />
Header set X-Permitted-Cross-Domain-Policies master-only
</Location>
If you operate a site on a hosted service, or a server that you otherwise don't entirely control, and you serve policy files:
Use the following if you only want to use a single policy file on your site:
<site-control permitted-cross-domain-policies="master-only"/>
Use the following if you don't want any restrictions on the creation of policy files on your site:
<site-control permitted-cross-domain-policies="all"/>
As described in the section on socket policy files, there are two reasons you may want to serve a socket master policy file from port 843 on your host:
Serving a socket master policy file is not the only way to address these issues, but it is the easiest and most consistent way to address them. If you find for some reason that serving a master socket policy file from port 843 is impractical, you can address these issues on a port-by-port basis, serving non-master socket policy files from individual ports. But a socket master policy file should address an entire host at once.
To serve a socket master policy file:
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="mysite.com" to-ports="999,8080-8082"/>
</cross-domain-policy>
Note: Setting up a socket policy file server provides a brief background on the latest Flash Player socket functionality, as well as sample code for creating socket policy file servers in testing environments.
Two of the security changes introduced in Flash Player 9,0,115,0 can only be enforced when Flash Player has access to HTTP response headers. When Flash Player is running inside a browser, this is not always possible, as some browsers do not provide HTTP response headers to Flash Player.
The two features that require HTTP response header access are as follows:
Content-Type values, as well as those that have no Content-Type at all. When Flash Player does not have access to HTTP response headers, it accepts HTTP policy files regardless of their Content-Type.X-Permitted-Cross-Domain-Policies response headers. When Flash Player does not have access to HTTP response headers, all HTTP servers are assumed to have a meta-policy of all.Table 1 shows the browsers that Adobe has tested for HTTP response headers.
| Browser | Versions that do not provide headers | Versions that provide headers |
|---|---|---|
| Internet Explorer (Windows) | — | 5.5 and later |
| Mozilla Firefox | 2.0.0.3 and earlier | 2.0.0.4 and later |
| Safari (Macintosh) | 2.x and earlier | 3.x and later |
This section lists messages that you may find in the policy file log, crossdomain.xml. As detailed in the section on logging, some of these messages are prefixed with the designation [strict], meaning that they indicate immediate issues in Phase 1, rather than warnings of impending issues for Phase 2. See the section on immediate issues.
Root-level SWF loaded: (URL).
A top-level SWF file from the indicated URL has been loaded. This is usually the first message in the log, and if you have enabled append-mode logging, you may see it more than once. This message helps you put later messages in context, knowing which SWF file began the Flash Player session that generated the log.
Searching for <allow-access-from> in policy files to authorize
data loading from resource at (URL) by requestor from (URL).
A SWF file has attempted an operation that requires data-loading permission from a policy file, and a search will now begin for such a policy file. The URLs in this message tell you where the SWF file was loaded from and what resource the SWF file requested.
Searching for <allow-http-request-headers-from> in policy files
to authorize header sending to URL (URL) by requestor from (URL).
A SWF file has attempted an HTTP operation with custom request headers, which requires header-sending permission from a policy file, and a search will now begin for such a policy file. The URLs in this message tell you where the SWF file was loaded from and where the SWF file is attempting to send custom HTTP request headers. See the article Understanding Flash Player 9 April 2008 Security Update compatibility for details regarding header-sending permissions.
Request for resource at (URL) by requestor from (URL) is permitted
due to policy file at (URL).
A SWF file has attempted an operation that requires permission from a policy file, and a policy file was found that permitted the operation. The URLs in this message tell you what resource the SWF file requested, where the SWF file was loaded from, and which policy file granted the permission. Note that it is possible that multiple policy files would have permitted the operation, but only one of them is mentioned in this type of log message.
Request for resource at (URL) by requestor from (URL) has failed
because the server cannot be reached.
A SWF file has attempted to make a socket connection, but the socket server is unreachable at the moment. The URLs in the message tell you what server and port the SWF file attempted to connect to, and where the SWF file was loaded from. For security reasons, In ActionScript, the SWF file will receive exactly the same error indication as if the server were reachable, but no permission had been granted for the operation; in ActionScript 3.0, this indication is a securityError event.
Request for resource at (URL) by requestor from (URL) is denied
due to lack of policy file permissions.
A SWF file has attempted an operation that requires permission from a policy file, but no valid policy file was found that permitted the operation. The URLs in the message tell you what resource the SWF file requested, and where the SWF file was loaded from.
This message may occur for many reasons; it indicates a required step that failed to occur, rather than a particular problem that did occur. In some situations, there will be other, more specific messages that come before this message, and they may give you more information before this final failure message. Among the possible causes:
allowDomain to load an applicable policy file, this message will generally be preceded by the message "Failed to load policy file from URL ". Note that, for a socket connection, you should see the previously listed message instead for this situation "...because the server cannot be reached" , but for any other request, you should see this message.allowDomain to inform Flash Player of the policy file's location. Try calling allowDomain from the SWF file.
Domain (domain) does not specify a meta-policy. Applying default
meta-policy 'all'. This configuration is deprecated.
This is a very common message that you will see any time Flash Player obtains a policy file from an HTTP, HTTPS, or FTP server that has not yet specified a meta-policy. In Phase 1, this is only a warning reminding you that this server needs to choose a meta-policy by the time a Phase 2 Flash Player Flash Player 10.0 is released, or else Flash content might stop working as intended. See the section on meta-policies.
SWF from (URL) may not connect to a socket in its own domain
without a policy file.
A SWF file initiated a socket connection to its own domain, and no policy file was found to authorize the operation. Strict policy file rules require permission from a socket policy file to make any socket connection, even to a SWF file's own domain. See the section on socket policy files. The recommended action is to add a socket master policy file server on port 843.
HTTP response headers not available on this platform.
Strict policy file rules cannot be enforced.
Flash Player made an HTTP request, and was not able to see HTTP response headers. As detailed in the section on meta-policies, some of the new strict policy file rules require that Flash Player be able to access HTTP response headers, for example so that Content-Type and X-Permitted-Cross-Domain-Policies information from the server is known. Any meta-policy information from servers will be unavailable. For a list of precise effects, and a list of browser configurations where this behavior is expected, see the browser dependency appendix. This warning should not indicate that previously working content will stop working; rather it indicates that the new, stricter rules cannot be enforced, which may result in reduced security for servers and users. The latest versions of most popular browsers enable Flash Player to see HTTP response headers, so upgrading your browser will usually eliminate this message.
Policy file accepted: (URL).
A policy file from the indicated URL has successfully been loaded, has passed all validity checks, and has been accepted by Flash Player. Any <allow-access-from> directives in the policy file will now take effect. This policy file might have been loaded because a SWF file explicitly requested it by calling loadPolicyFile, or it may have been located automatically by Flash Player's default policy file rules.
Policy file requested from (URL) redirected to (URL);
will use final URL in determining scope.
Flash Player requested an HTTP policy file, and the original request was redirected to a different location in the same domain. As detailed in the section on redirects, beginning with version 9,0,115,0, Flash Player has changed its interpretation of HTTP policy files that are obtained from URLs that are redirected within the same domain. Prior to version 9,0,115,0, Flash Player would treat redirected policy files as though they had originated from the URL that was initially requested. Since version 9,0,115,0, however, Flash Player has treated redirected policy files as though they had originated from the final, post-redirect URL. This difference may affect the scope of such a policy file—the set of resources to which it allows access. If you see this warning, check further down the log to see if all requests that depend on this policy file are in fact still succeeding. If they are not, you may need to add a non-redirected policy file at the originally requested URL. You can also put a non-redirected policy file at a different URL, which may require adding or changing loadPolicyFile calls in SWFs to use the new policy file URL. In any case, you should consider avoiding redirecting policy file requests, since they tend to make policy file debugging more difficult.
Domain (domain) does not explicitly specify a meta-policy,
but Content-Type of policy file (URL) is 'text/x-cross-domain-policy'.
Applying meta-policy 'by-content-type'.
Flash Player has retrieved an HTTP policy file from the indicated URL, and has looked for a meta-policy in HTTP headers and in the master policy file for this domain, but found no meta-policy. However, the policy file was returned with a Content-Type of text/x-cross-domain-policy, which is an indication that the administrator of this server has deliberately made changes to support meta-policies. Since the official Content-Type for HTTP policy files is in use in this domain, Flash Player is assuming a meta-policy of by-content-type for this domain. See the section on specifying meta-policies. It is recommended that, for clarity, this server should explicitly declare a meta-policy, rather than relying on this implicit mechanism. This can be done using a <site-control> tag in the master policy file, or using the HTTP response header X-Permitted-Cross-Domain-Policies.
Timeout on (URL) (at 3 seconds) while waiting for socket policy file.
Flash Player requested a socket policy file by default either from port 843 or from the same port as a connection attempt , and the socket policy file request resulted neither in success nor in a detectable failure; the server that Flash Player was attempting to contact did not respond within 3 seconds. This might be due to a server not expecting to receive policy file requests, or due to network problems between client and server. When Flash Player requests socket policy files by default, it waits only 3 seconds for a response, in order to avoid tying up server resources or delaying client-side notifications of problems; see the section on socket policy files. This warning usually means one of two things: first, that you need to set up a socket policy file server on port 843, which is the first location that Flash Player checks by default; or second, that you need to provide more explicit guidance to Flash Player from ActionScript by calling loadPolicyFile to indicate the location of a socket policy file. When you call loadPolicyFile rather than allowing Flash Player to check locations by default, Flash Player will wait as long as necessary for a response from a socket policy file server, rather than timing out after 3 seconds. This may help your application's reliability in marginal network conditions. It can thus be helpful to call loadPolicyFile even for a default socket policy file location—simply to request that Flash Player wait patiently for the socket policy file server to respond.
Failed to load policy file from (URL).
Flash Player attempted to retrieve a policy file from the indicated URL, and encountered an error. This might be because of network problems, because a server is not running at this location, or because a server is running but did not recognize the location requested (e.g., HTTP 404 error). This message appears as an error for locations that were passed to loadPolicyFile, as a warning for HTTP/HTTPS/FTP locations that Flash Player has requested by default, and not at all for socket policy file locations that Flash Player has requested by default.
Ignoring policy file at (URL) due to incorrect syntax.
Flash Player retrieved a policy file from the indicated URL, but found that the policy file contained invalid syntax. The policy file has been ignored and will not authorize any operations. See the section on malformed policy files for an explanation of why proper syntax is enforced, and what common kinds of incorrect syntax can result in this error. You (or whoever maintains this policy file) should fix the incorrect syntax as soon as possible. This rule has been enforced since even before Phase 1—starting with Flash Player version 9,0,47,0.
Ignoring policy file at (URL) due to bad Content-Type '(content-type)'.
Flash Player retrieved an HTTP policy file from the indicated URL, but found that the HTTP Content-Type of the policy file was not consistent with normal policy files. To help protect this server, this policy file has been ignored and will not authorize any operations. See the section on the Content-Type whitelist for details. You (or whoever maintains this policy file) should change the unsuitable Content-Type as soon as possible.
Ignoring policy file at (URL) due to missing Content-Type.
Similar to the above error, but Flash Player found no Content-Type at all.
Ignoring policy file requested from (URL) because a cross-domain
redirect to (URL) occurred.
Flash Player attempted to retrieve a policy file from the first URL indicated, but was redirected to the second URL indicated, which is in a different domain. This is forbidden, and always has been. This policy file has been ignored and will not authorize any operations.
Ignoring policy file at (URL) due to meta-policy '(meta-policy)'.
Flash Player retrieved a policy file from the indicated URL, but also found the indicated meta-policy on that policy file's server, either in a <site-control> tag in the master policy file, or in an X-Permitted-Cross-Domain-Policies HTTP header. The indicated meta-policy expressly forbids this file from being valid as a policy file, so this policy file has been ignored and will not authorize any operations. This message by itself does not necessarily indicate a problem, but if you intended for this policy file to be valid, you may need to change its Content-Type or its FTP filename, or you may need to change the meta-policy.
Ignoring policy file at (URL) due to X-Permitted-Cross-Domain-Policies:
none-this-response.
Flash Player retrieved an HTTP policy file from the indicated URL, but also found the HTTP response header X-Permitted-Cross-Domain-Policies: none-this-response, which is an indication from the server that this HTTP response is not permitted to be used as a policy file. This is usually used to prevent server scripts from generating policy files; see the section on socket meta-policies. This policy file has been ignored and will not authorize any operations. If you control this server, and you need this policy file to authorize operations, you may need to change your server configuration to avoid generating a none-this-response header.
Ignoring socket policy file at (URL) because it is too large.
Socket policy files may not exceed 20 kilobytes.
Flash Player began the process of retrieving a socket policy file from the indicated location, but aborted the download because too much data was received. This policy file has been ignored and will not authorize any operations. This is to help protect the server; Flash Player does not expect policy files to be large, and aborts large policy file downloads to avoid loading the server in what seems to be an error situation. If this is a valid socket policy file, try reducing its size so that it is smaller than 20K.
Unrecognized meta-policy in HTTP header from (URL): (meta-policy).
An invalid meta-policy was specified in an X-Permitted-Cross-Domain-Policies HTTP header from the indicated URL. It has been ignored. This is a misconfiguration that should be corrected on the server. See the section on meta-policies.
Unrecognized meta-policy in policy file from (URL): (meta-policy).
An invalid meta-policy was specified in a <site-control> tag in a master policy file at the indicated URL. The meta-policy has been ignored, but the policy file itself has not necessarily been ignored (there should be a further error message if it is). You (or whoever controls the content of this policy file) should correct the <site-control> tag so that it contains a valid meta-policy name. See the section on meta-policies.
Conflicting meta-policy in HTTP header from (URL): (meta-policy).
Multiple conflicting meta-policies were found in one or more X-Permitted-Cross-Domain-Policies HTTP header from the indicated URL. The entire meta-policy string is shown, as received from the server. If multiple X-Permitted-Cross-Domain-Policies headers were provided, they have been coalesced here into a single header with semicolon-separated values, as is normal for HTTP headers. Flash Player has applied the most restrictive meta-policy that was found in this string. This is a misconfiguration that should be corrected on the server. It is generally not legal to provide multiple meta-policies in HTTP response headers; the only exception is none-this-response, which may be combined with any other meta-policy, but only affects the individual HTTP response where it is found. See the section on meta-policies.
Meta-policy (meta-policy) in HTTP header from (URL) conflicts
with previously established meta-policy (meta-policy).
Flash Player found an inconsistent declaration of meta-policy from the server of the indicated URL. Flash Player has applied the most restrictive meta-policy that was found from this server, but if a less restrictive meta-policy was found first, the less restrictive meta-policy may have been in effect for some time until the conflict was found later. This is a misconfiguration that should be corrected on the server. See the section on meta-policies.
Meta-policy (meta-policy) in policy file from (URL) conflicts with
previously established meta-policy (meta-policy).
Similar to the above error, but the conflicting meta-policy file was discovered in a <site-control> tag rather than an HTTP header.
Ignoring <site-control> tag in policy file from (URL).
This tag is only allowed in master policy files.
Flash Player found a <site-control> tag in a policy file, from the indicated URL, that was not a master policy file. The <site-control> tag has been ignored, but the policy file itself has not necessarily been ignored (there should be a further error message if it is). The <site-control> tag is only legal in master policy files (/crossdomain.xml on an HTTP/HTTPS/FTP server, or a socket policy file from port 843). You (or whoever controls this server) should remove the <site-control> tag from this policy file, and make sure that this server declares a valid meta-policy by some other means (a master policy file or an HTTP response header). See the section on meta-policies.
Ignoring <site-control> tag in policy file from (URL).
The 'by-content-type' meta-policy is only applicable to HTTP sites.
Flash Player found a <site-control> tag in a master policy file from the indicated URL, specifying the meta-policy by-content-type in a policy file that was not from an HTTP or HTTPS server. The <site-control> tag has been ignored, but the policy file itself has not necessarily been ignored (there should be a further error message if it is). The by-content-type meta-policy is only valid for HTTP and HTTPS servers, since it relies on Content-Type headers, which are not available from FTP servers or socket servers. You (or whoever controls this server) should choose a valid meta-policy for this server. See the section on meta-policies.
HTTP header from (URL) specifies meta-policy 'by-ftp-filename',
which is only applicable to FTP, not HTTP.
Flash Player found an X-Permitted-Cross-Domain-Policies HTTP response header while retrieving a policy file from the indicated URL, specifying the meta-policy by-ftp-filename. The X-Permitted-Cross-Domain-Policies header has been ignored, but any policy file at this URL has not necessarily been ignored (there should be a further error message if it is). The by-ftp-filename meta-policy is only valid for FTP servers. You (or whoever controls this server) should choose a valid meta-policy for this server. See the section on meta-policies.
Ignoring <site-control> tag in policy file from (URL).
The 'by-ftp-filename' meta-policy is only applicable to FTP sites.
Similar to the above error, but the invalid meta-policy was discovered in a <site-control> tag rather than an HTTP header.
Ignoring <site-control> tag in policy file from (URL).
The 'none-this-response' meta-policy is only allowed in the
X-Permitted-Cross-Domain-Policies HTTP response header.
Flash Player found a <site-control> tag in a master policy file from the indicated URL, specifying the meta-policy none-this-response in a policy file. The <site-control> tag has been ignored, but the policy file itself has not necessarily been ignored (there should be a further error message if it is). The none-this-response meta-policy is only valid in the X-Permitted-Cross-Domain-Policies HTTP response header; it is only intended as a mechanism by which HTTP servers can prevent server scripts from generating policy files. You (or whoever controls this server) should choose a valid meta-policy for this server. See the section on meta-policies.
Policy file at (URL) invalidates its own <allow-access-from>
directives by declaring the meta-policy 'none'.
Flash Player found a <site-control> tag in a master policy file from the indicated URL, specifying the meta-policy none, but also found <allow-access-from> directives in the same policy file. The declared meta-policy none should be enforced for this server; it means that no policy files are permitted on this server, including the master policy file itself. The master policy file is permitted to exist only to declare the meta-policy. Since the master policy file contains <allow-access-from> directives, they will be ignored. You or whoever controls this server should remove the <allow-access-from> directives from this policy file. See the section on meta-policies.
Ignoring 'secure' attribute in policy file from (URL). The 'secure'
attribute is only permitted in HTTPS and socket policy files.
Flash Player found a policy file, from the indicated URL, that contained one or more <allow-access-from> directives that specified the attribute secure="true" or secure="false", but this is neither an HTTPS policy file nor a socket policy file. The secure attribute has been ignored, but the <allow-access-from> directive is not necessarily being ignored (there will be a further error message if it is). The secure attribute, which instructs Flash Player whether to require strong authentication (i.e., HTTPS URLs only) of the domain named in an <allow-access-from> directive, is only legal in HTTPS policy files and socket policy files. This rule has been enforced since policy files were first introduced. This is because the policy file itself is not being transmitted over a tamper-resistant protocol, so a man-in-the-middle attacker could replace a secure="true" declaration with secure="false", which would then allow a non-HTTPS SWF file to retrieve data from this domain, contrary to the policy expressed in this policy file. You (or whoever controls this server) should remove the secure attribute from this policy file.
Found secure='true' in policy file from (URL), but host (host) does not
appear to refer to the local machine. This may be insecure.
Flash Player found a socket policy file, from the indicated URL, that contained one or more <allow-access-from> directives that specified the attribute secure="true" or secure="false", but the socket policy file does not appear to have come from the local machine. The secure attribute should be enforced as specified, but if this socket policy file did in fact come from somewhere other than the local machine, you may have an insecure configuration. The secure attribute, which instructs Flash Player whether to require strong authentication i.e., HTTPS URLs only of the domain named in an <allow-access-from> directive, is effective in socket policy files served from the local machine, because there is no network transmission in which a man-in-the-middle attacker could substitute a different policy file. However, if a socket policy file is served from a remote host, specifying secure="true" may provide a false sense of security, because the socket policy file is transmitted in a way that may be vulnerable to man-in-the-middle attacks. Flash Player does not yet provide a way to retrieve a socket policy file over a secure channel. See the section on socket policy files.
Ignoring invalid <allow-access-from> tag for domain '(domain)' in
policy file at (URL).
Flash Player found a policy file from the indicated URL, containing the indicated string as a value for the domain attribute in an <allow-access-from> directive. This string was not recognized as a valid domain. This particular <allow-access-from> directive will be ignored, although other directives in the same policy file may be valid and accepted. You (or whoever controls this policy file) should try to fix the invalid domain.
Ignoring illegal port number specification '(port-string)' in
policy file at (URL).
Flash Player found a policy file from the indicated URL, containing the indicated string as a value for the to-ports attribute in an <allow-access-from> directive. This string was not recognized as a valid port range. Port ranges may include the wildcard *, individual port numbers, port ranges separated by dashes, or comma-separated lists of individual numbers and/or ranges. This particular <allow-access-from> directive will be ignored, although other directives in the same policy file may be valid and accepted. You (or whoever controls this policy file) should try to fix the invalid port range.