Explanation Of Cross Domain And Client Access Policy Files For Silverlight

Referred URL

http://www.devtoolshed.com/explanation-cross-domain-and-client-access-policy-files-silverlight

Taking some of the good ideas from Adobe Flash in regards to security policy, Silverlight has implemented a similar security model to block unauthorized cross domain network calls. This plugs a potential security hole where a malicious Silverlight application could run on a page the user is viewing and make API and network calls to domains that the user is not on without his or her knowledge. Microsoft has a quick write-up on some of the security issues this solves here: http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx.

Commonly, this issue is usually encountered in Silverlight when you see an exception like this:

An error occurred while trying to make a request to URI "http://localhost/myservice.asmx". This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services.

In order for Silverlight to call a remote resource on a different domain from where the XAP file was served such as a Web Service or RSS feed, the domain where the service or feed resides must grant access to the Silverlight application. The way this is done is using an XML file with the name "clientaccesspolicy.xml" or "crossdomain.xml".

As the above diagram illustrates, when your Silverlight application communicates with the server that served the application, the communication here is allowed because this is on the same domain from where your app was served. But when your Silverlight application attempts to communicate with a 3rd party remote server, a policy must exist (which is defined in either the "clientaccesspolicy.xml" or "crossdomain.xml" file) that allows this communication. If not policy exists on the domain different from the domain from where your Silverlight app was served, the communication is not allowed (hence the name "cross domain script attacks" because it is communication a-"cross" domains).

Difference between Cross Domain and Client Access Policy files

"crossdomain.xml" was created originally for use with Flash applications. But Silverlight also supports this file. "clientaccesspolicy.xml" is specific to Silverlight and allows you to configure specific access rules for HTTP/HTTPS communication and allowable domains.

To enable communication to a server for a specific Silverlight application, both files do not need to be present. You can choose either one depending on your preference but at least one of the files must be there with the correct rules configured. If you want to enable access for both Silverlight and Flash applications, then you might consider just having a "crossdomain.xml" file (or you could still have both this case).

Both the Cross Domain and the Client Access Policy files are XML but have different elements and format.

Example of Client Access Policy file

Client Access Policy files give you more granular controls over traffic types, access to resources, and specific HTTP header information. The following example will allow any and all request to this web server from Silverlight:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <!-- Silverlight 3 or higher requires the http-request-headers attribute. -->
    <policy>
      <allow-from http-request-headers="*">
          <domain uri="http://*" />
          <domain uri="https://*" />
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

You can specify that only a specific file can be accessed. For instance, here we only allow HTTP traffic from any domain and we only allow these requests to serve the "myfile.xml" file:

<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="http://*" />
      </allow-from>
      <grant-to>
        <resource path="myfile.xml" include-subpaths="false" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Here we only allow the domains microsoft.com and repeatsys.com access:

<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="http://www.microsoft.com" />
        <domain uri="http://www.repeatsys.com" />
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

This example shows how to use the wildcard (*) to allow any sub-domain of a specific domain access. Here we are allowing all requests from any sub-domain of devtoolshed.com access:

<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="http://*.devtoolshed.com" />
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Example of Cross Domain file

The following example will allow any and all requests to this web server from Flash or Silverlight:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy 
  SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

Technically, this completely eliminates any security from the cross domain policy so although this is really convenient for development purposes, it should probably not be used in production in most cases.

If you wanted to only allow certain domains to access the system, your file could be configured like this:

<!DOCTYPE cross-domain-policy 
SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="www.microsoft.com" />
  <allow-access-from domain="www.devtoolshed.com" />
</cross-domain-policy>

If you wanted to block all access to your server from any Silverlight or Flash application, you could use this code:

<!DOCTYPE cross-domain-policy 
  SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
</cross-domain-policy>

Also note, you can use the wildcard (*) character to handle the situation of multiple sub-domains on a specific domain. For instance, this file shows how to allow all sub-domains from devtoolshed.com to communicate with the server:

<!DOCTYPE cross-domain-policy 
  SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-access-from domain="*.devtoolshed.com"/>
</cross-domain-policy>

Where do I put the crossdomain.xml or clientaccesspolicy.xml file?

The crossdomain.xml or clientaccesspolicy.xml MUST be located at the root of your web server. If you put the file(s) in a sub-directory where your website files might be, they don’t count and won’t work. The file(s) need to be in the root of your web server so if your domain is www.devtoolshed.com, then the file(s) should be located at:www.devtoolshed.com/crossdomain.xml or www.devtoolshed.com/clientaccesspolicy.xml respectively.

What is the order that Silverlight requests these files?

When a Silverlight app communicates to a remote server, it first requests the "clientaccesspolicy.xml" file and then if that is not found, it falls back on the "crossdomain.xml" file to check if it exists. If neither does, communication will fail if this request is to a different domain than the one from which the Silverlight app was served from.

A great diagram of the process to request the file is available at:https://community.dynamics.com/blogs/cesardalatorre/comments/9579.aspx

It is a bit confusing at first thought because Silverlight is actually the one that deciphers the policy even though the policy is set and maintained at the web server where the resources that are being requested reside. Once you get over that mental hurdle, the rest is pretty easy to understand.

Domains and sub-domains are different

Also note that when we say "domain" this does not include sub domains. To a Silverlight app, the domains "www.devtoolshed.com" and "fudge.devtoolshed.com" are completely different. They must both be allowed separately. Sub-domains on a specific domain are treated as different domains to cross domain policies.

HTTP and HTTPS are different

HTTP and HTTPS are treated as separate types of requests and must be specifically allowed. Even after doing this, you may still have problems in your Silverlight app if you are running HTTPS and try to make an HTTP call or vice versa so watch out for cross SSL communication (this is kind of a separate issue from the cross domain security issues but worth noting here).