Explanation of Cross Domain and Client Access Policy files for Silverlight
2011-06-29 15:58
543 查看
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
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
相关文章推荐
- Explanation of Cross Domain and Client Access Policy files for Silverlight
- Silverlight clientaccesspolicy.xml files for the Enterprise
- Silverlight 2.0 beta 1与crossdomain.xml和clientaccesspolicy.xml
- crossdomain.xml 和 clientaccesspolicy.xml
- clientaccesspolicy.xml vs. crossdomain.xml
- crossdomain.xml和clientaccesspolicy.xml
- 若允许Tomcat所有域访问,将clientaccesspolicy.xml和crossdomain.xml加入%TOMCAT_HOME%\webapps\ROOT 目录下即可
- Silverlight Crossdomain Access WebService And Debug
- crossdomain.xml 和 clientaccesspolicy.xml
- Silverlight Crossdomain Access WebService And Debug
- Cross-domain calls and server side debugging of Silverlight application
- Cross-domain calls and server side debugging of Silverlight application
- Geometric regularity criterion for NSE: the cross product of velocity and vorticity 2: $u\times \om\cdot \n\times \om$
- Joint Learning of Single-image and Cross-image Representations for Person Re-identification
- A solution for conflict of structure loc_t in header files of vac compiler and informix esql on AIX
- 概述CSLA.NET 3.6 (Overview of CSLA .NET 3.6 for Windows and Silverlight)
- 论文阅读:Joint Learning of Single-image and Cross-image Representations for Person Re-identification
- 1607.CVPR-Joint Learning of Single-image and Cross-image Representations for Person ReID 论文笔记
- zz - reprint and rework of "A few Good Metadat options for Silverlight"
- 概述CSLA.NET 3.6 (Overview of CSLA .NET 3.6 for Windows and Silverlight)