Socket policy files

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.

Socket policy file background

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.

Socket master 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:

• A fixed port number provides a standard way to serve a socket policy from a host. Previously, this arrangement was a decision that each host administrator had to make for themselves. With a fixed port number, a standalone socket policy file server can bind to port 843 by default, and it is easier for an administrator to find a socket policy on an unfamiliar machine.
• A master location provides a way to declare a socket meta-policy. Socket meta-policies are similar to the URL meta-policies discussed earlier: they control what socket policy files are permitted to exist on a host. This is explained further in the section below on socket meta-policies.
• Serving a socket policy file from port 843 provides a way for host administrators to indicate their desire to opt into new socket rules, even for Phase 1 versions of Flash Player. This is explained further in the section below on opting into strict socket rules.
• A fixed master location can be checked automatically by Flash Player, without ActionScript having to call 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

Socket meta-policies are similar to URL meta-policies. There are a few differences:

• Socket meta-policies affect socket policy files, not URL policy files. A socket meta-policy affects an entire host, not just a single URL server.
• Socket meta-policies can only be declared in a socket master policy file. The syntax is the same as for declaring a meta-policy in an URL master policy file, using the <site-control> tag. Socket meta-policies cannot be declared in HTTP response headers, as HTTP is not involved.
• A different set of meta-policies is available for use as socket meta-policies than is available for use as URL meta-policies, and the default socket meta-policy is different from the default URL meta-policy.

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.

Strict socket rules

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:

• A SWF file may no longer make a socket connection to its own domain without a socket policy file. Prior to version 9,0,115,0, a SWF file was permitted to make socket connections to ports 1024 or greater in its own domain without a policy file.
• HTTP policy files may no longer be used to authorize socket connections. Prior to version 9,0,115,0, an HTTP policy file, served from the master location of /crossdomain.xml on port 80, could be used to authorize a socket connection to any port 1024 or greater on the same host.

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.

Opting into strict socket rules

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.

• If a host serves a socket policy file from port 843 (a socket master policy file), strict socket rules will be applied for the entire host. This is true regardless of the contents of the policy file; even if the socket master policy file is empty, or declares the meta-policy 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.
• If an HTTP server on port 80 declares a URL meta-policy in its master policy file at /crossdomain.xml, then that master HTTP policy file will not authorize socket connections to the same host. This configuration activates only one of the two strict socket rules for its host—the rule about SWF files connecting to their own hosts is unaffected.
• If a non-master socket port serves a socket policy file, strict socket rules will be applied for that particular port. All socket connections to this port will require permission from a socket policy file, which will most likely be the same socket policy file that is being served from this port. An occasional unintended consequence of this rule is described in the section on immediately strict sockets: if a socket port 1024 or higher serves a socket policy file that does not list its own domain, then SWF files from that domain, which previously were permitted to connect without a policy file, will be unable to connect.

Secure domain lists

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.

Address-based socket policy file scopes

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.

Socket policy file behaviors exposed to server hosts

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:

• When a SWF file attempts to make a socket connection, even to its own domain, Flash Player will first attempt to contact port 843 to see if the host is serving a socket master policy file.
• When an ActionScript 1.0 or ActionScript 2.0 SWF file attempts to make an 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.

Firewall traversability and socket policy files

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:

1. Socket meta-policies will not be honored; any socket policy file will be allowed to permit access (though only by users behind the restrictive firewall).
2. For Phase 1 versions of Flash Player, if a host is using the existence of a socket master policy file to signal opt-in to the new rules, that opt-in will not be seen by Flash Player. Users behind the restrictive firewall may still be vectors for DNS rebinding attacks that target socket ports greater than or equal to 1024.
3. If a host is relying on its socket master policy file to authorize socket connections, then users behind the restrictive firewall will not be able to establish those connections.

These consequences may sometimes cause minor problems, but Adobe does not believe they should cause major problems. Here is why:

• If a user is behind a restrictive firewall and cannot see port 843, they may not be able to see the target port either, which moots all three disadvantages listed above. There are a few ports that firewalls almost always allow, such as 80 for HTTP, but many ports will be off-limits, including probably most or all ports greater than or equal to 1024. This last point especially means that issue (2) is unlikely to occur very often.
• For DNS rebinding attacks that target servers behind firewalls, access to port 843 is not likely to be a problem, because it would be unusual for a firewall to block access to any ports on servers inside the firewall.
• For issue (1) above, anyone wishing to circumvent a socket meta-policy (which is itself probably somewhat unusual) is unlikely to find it attractive that their only available vectors are users behind restrictive outbound firewalls.

Why action is needed

There are two reasons to serve a socket policy file (probably a socket master policy file from port 843) on your host:

• If you maintain any SWF files that make socket connections to your host, and they currently connect without a socket policy file (because they are connecting to their own domain, or because they rely on an HTTP policy file), such SWF files are not able to connect for users with a Phase 1.5 version of Flash Player (9,0,124,0 or later).
• Whether or not your host deliberately serves socket policy files, or even any Flash Player compatible content at all, malicious parties may attempt to make unauthorized socket-level connections to your host using a DNS rebinding attack. Opting into the strict socket rules by serving a socket master policy file helps ensure that users of Phase 1 versions of Flash Player cannot be used as vectors for such an attack.

The workflow for configuring socket policy files takes you through the steps necessary to serve a master socket policy file from your host.

Page 4 of 7

Previous Page

Next Page