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.