Using Silverlight version 4 for cross-domain communication requires guarding against several types of security vulnerability that can be used to exploit Web applications. Cross-site forgery is a class of exploits that becomes a threat when allowing cross-domain calls. This exploit involves a malicious Silverlight control transmitting unauthorized commands to a third-party service, without the user's knowledge. To prevent cross-site request forgery, Silverlight allows only site-of-origin communication by default for all requests other than images and media. For example, a Silverlight control hosted at http://contoso.com/mycontrol.aspx can access only services on that same domain by default – for example http://contoso.com/service.svc, but not a service at http://fabrikam.com/service.svc. This prevents a malicious Silverlight control hosted on the http://contoso.com domain from calling unauthorized operations on a service hosted on the http://fabrikam.com domain.
To enable a Silverlight control to access a service in another domain, the service must explicitly opt-in to allow cross-domain access. By opting-in, a service states that the operations it exposes can safely be invoked by a Silverlight control, without potentially damaging consequences to the data that the service stores.
Silverlight 4 supports two different mechanisms for services to opt-in to cross-domain access:
- Place a clientaccesspolicy.xml file at the root of the domain where the service is hosted to configure the service to allow cross-domain access.
- Place a valid crossdomain.xml file at the root of the domain where the service is hosted. The file must mark the entire domain public. Silverlight supports a subset of the crossdomain.xml schema .
For more information about cross-scheme access, see Network Security Access Restrictions in Silverlight .
To use a clientaccesspolicy.xml file to allow cross-domain access
Build a service that enables access by a Silverlight client. For more information about how to do this, see How to: Build a Service for Silverlight Clients .
Create a clientaccesspolicy.xml file that allows access to the service. The following configuration allows access from any other domain to all resources on the current domain.
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="SOAPAction">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Alternatively, if you want to allow access from only one other domain, such as http://contoso.com, replace the <domain uri="*"/>
line within the <allow-from>
element of the clientaccesspolicy.xml file above with the line <domain uri="http://contoso.com"/>
.
To allow access to an HTTPS service from any Silverlight control hosted over HTTP application, you need to put the <domain uri=”http://*” />
element inside your <allow-from>
element.
The valid values for the headers attribute are:
- the wildcard (“*”) - which allows all headers that have not been blacklisted
- a comma-separated list of allowed headers. These allowed headers can use a wildcard suffix, for example, “X-CUSTOM-*”.
To enable the service for access over TCP sockets, add <socket-resource port="4502" protocol="tcp" />
to the <grant-to>
element, where the 4502 is the port value where the service is hosted.
Save the clientaccesspolicy.xml file to the root of the domain where the service is hosted. If, for example, the service is hosted in http://fabrikam.com then the file must be located at http://fabrikam.com/clientaccesspolicy.xml.
Test that the access is enabled by invoking the service from the other domain.
To use a crossdomain.xml file to allow cross-domain access
Build a service that enables access by a Silverlight client. For more information about how to do this, see How to: Build a Service for Silverlight Clients .
Create a crossdomain.xml file that contains the following configuration. The file must be configured to allow access to the service from any other domain, or it is not recognized by Silverlight 4.
Save the crossdomain.xml file to the root of the domain where the service is hosted. If, for example, the service is hosted in http://fabrikam.com, then the file must be located at http://fabrikam.com/crossdomain.xml.
Test that the service is enabled by invoking the service from the other domain.