Flash Player Article

Policy file changes in Flash Player 9

Changes in behavior due to immediate strictness

While most of the Policy file changes in Flash Player 9,0,115,0 will initially generate only developer warnings, a few of the changes will immediately result in changed functionality that may prevent SWF applications from working as intended. We have tried to apply these immediate changes only for patterns of behavior that we believe are highly unlikely to occur in legitimate content. Still, we realize some legitimate content will be 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.

Malformed policy files

Unlike all other changes described in this article, Flash Player's restrictions on malformed policy files are 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:

• Leading or trailing extraneous content—anything (other than XML comments and declarations) that comes before the opening <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.
• A top-level XML tag that is not <cross-domain-policy>.
• Text (other than comments) inside any tag.

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:

• http://www.adobe.com/xml/schemas/PolicyFile.xsd
• http://www.adobe.com/xml/schemas/PolicyFileFtp.xsd
• http://www.adobe.com/xml/schemas/PolicyFileHttp.xsd
• http://www.adobe.com/xml/schemas/PolicyFileHttps.xsd
• http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd

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.

Within-domain redirects

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.

Content-type whitelist

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+xml

Content-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.

Immediately strict sockets

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 will be rolled out in two phases, with violations generating only warnings in Phase 1, unless hosts opt in to the new rules. However, for a few special kinds of sockets, the strict rules are applied immediately, even in Phase 1. These are:

• Sockets on the local machine where Flash Player is running, except sockets that are identified as 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.
• Sockets at link-local IP addresses, except sockets that are identified as *.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.
• Sockets on ports numbered 1024 or higher that serve their own socket policy files, and do not list their own domain in policy file contents. This is actually not a separate rule; it is a consequence of the system for opting in to strict socket rules. Any socket that serves its own socket policy file automatically opts into the new rules. If a SWF file is making a connection to such a socket in its own domain, under the old rules, a policy file would not have been necessary, but under the strict rules, a socket policy file is necessary. If the socket policy file served by the socket happens not to list its own domain, SWF files from the same domain may not be able to connect.

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.

Page 2 of 7

Previous Page

Next Page