Explanation of Cross Domain and Client Access Policy files for 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).

Your XML must be well formed


Even if the clientaccesspolicy.xml or crossdomain.xml file is present, if
it is not well-formed XML, then it will fail to load and communication will be
not be allowed. In Silverlight version 3 or higher, the clientaccesspolicy.xml
file MUST contain the "http-request-headers"
attribute or the
file will be treated as not well formed.

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