42 out of 56 rated this helpful Rate this topic

Making a Service Available Across Domain Boundaries

Silverlight

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.
Copy
<?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:
1. the wildcard (“*”) - which allows all headers that have not been blacklisted
2. 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.

Copy

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <allow-http-request-headers-from domain="*" headers="SOAPAction,Content-Type"/>
</cross-domain-policy>

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.

Send comments about this topic to Microsoft.

Copyright © 2010 by Microsoft Corporation. All rights reserved.

Did you find this helpful? Yes No

Not accurate

Not enough depth

Need more code examples

(2000 characters remaining)

Community Content Add

FAQ

403.4 error getting crossdomain.xml when root of domain requires SSL

I was planning to require SSL for the root of the domain hosting my WCF services. I am using a silverlight client to access these services and everything works fine when running the client from within the domain but when running the client from another domain I'm getting a 403.4 (SSL Required) error when the client <apparently> tries to "GET" crossdomain.xml using HTTP. Is there a way to configure the client to use HTTPS instead? (or I am open to other suggestions).

Thanks. (failed requrest trace info below)

1. GENERAL_REQUEST_START SiteId="2", AppPoolId="DefaultAppPool", ConnId="1610612741", RawConnId="0", RequestURL="http://jwwdev.net:80/crossdomain.xml", RequestVerb="GET"
2. PRE_BEGIN_REQUEST_START ModuleName="RequestMonitorModule"
3. PRE_BEGIN_REQUEST_END ModuleName="RequestMonitorModule", NotificationStatus="NOTIFICATION_CONTINUE"
4. PRE_BEGIN_REQUEST_START ModuleName="FailedRequestsTracingModule"
5. PRE_BEGIN_REQUEST_END ModuleName="FailedRequestsTracingModule", NotificationStatus="NOTIFICATION_CONTINUE"
6. GENERAL_ENDPOINT_INFORMATION RemoteAddress="192.168.1.20", RemotePort="1065", LocalAddress="192.168.1.20", LocalPort="80"
7. GENERAL_REQUEST_HEADERS
          Headers="Connection: Keep-Alive
          Accept: */*
          Accept-Encoding: gzip, deflate
          Accept-Language: en-US
          Host: jwwdev.net
          Referer: http://localhost:44545/ClientBin/GuiClient.xap
          User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"
8. URL_CACHE_ACCESS_START RequestURL="/crossdomain.xml"
9. URL_CACHE_ACCESS_END PhysicalPath="", URLInfoFromCache="false", URLInfoAddedToCache="true", ErrorCode="The operation completed successfully. (0x0)"
10. GENERAL_GET_URL_METADATA PhysicalPath="", AccessPerms="617"
11. HANDLER_CHANGED OldHandlerName="", NewHandlerName="StaticFile", NewHandlerModules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule", NewHandlerScriptProcessor="", NewHandlerType=""
12. MODULE_SET_RESPONSE_ERROR_STATUS ModuleName="IIS Web Core", Notification="BEGIN_REQUEST", HttpStatus="403", HttpReason="Forbidden", HttpSubStatus="4", ErrorCode="Access is denied. (0x80070005)", ConfigExceptionInfo=""

History

2/9/2012
jwrighttok

Any chance getting this to work with Firefox and Chrome?

Any ideas? Thanks.

History

11/3/2011
Michael23

How does cross domain restrictions really work?

In the first paragraph:

"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."

Shouldn't the above be phrased as:

"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. If the same control is hosted at http://fabrikam.com/mycontrol.aspx, it will not be able to access services on http://contoso.com/service.svc."

And then,

"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."

Shouldn't this be phrased as:

"This prevents a Silverlight control hosted at http://contoso.com from being used maliciously at http://fabrikam.com to access the services at http://contoso.com/service.svc."

Also - below makes no sense because if one is going through the trouble of hosting a malicious control, I am sure they wouldn't mind adding a cross domain policy file on their "malicious" service root.

"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. "

Should be changed to

"For example, Services hosted at http://contoso.com/ can only be accessed by Silverlight controls hosted on that same domain by default – for example at http://contoso.com/mycontrol.aspx , but not by controls hosted at http://fabrikam.com/. This prevents a malicious Silverlight control hosted on the http://fabrikam.com domain from calling unauthorized operations on a service hosted on the http://contoso.com domain. "

History

7/9/2010
Fast Boat

9/29/2011
tmtgslnd

Crossdomain access issue with WCF service hosted on Windows Service

The article says to copy the crossdomain and accesspolicy xml to the web root, But in my case I am hosting the WCF in a Windows service which is accessed by Silverlight 4 Application. I have copied the files within the service exe folder, but doesn't help.

Can someone help me to resolve this issue please?

Kind Regards
Abish

History

8/25/2011
Abish Asharaf

Erratum

The article says; "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." $0$0 $0 $0This is wrong - for HTTP, you need it to be <domain uri=”https://*” />$0

History

7/29/2011
m0thr4

crossdomain exception..........

Hi,
I have a silverlight application which is calling wcf service.Service has been developed with "AspNetCompatibilityRequirements".But I am running the service from solution itslef I am not hosted in IIS.So please tell me where I need to keep the clientaccesspolicy and crossdomain policy files.??

my service url is http://localhost:51660/Service1.svc

folder hirarchy is Solutionfolder(with all the projects folders) >> Service project folder >> Service files..
in the above hierarchy where i need to copy the xml files????

History

7/6/2011
chandrashekhar.byreddy3009

Deploy searching for development server

After deployment, I checked with Fiddler. My deployed website was still trying to make requests of the ASP.NET development server - I recognized the port. Any idea why? I do have clientaccesspolicy at the root of my site, but it is looking for it on the development server.$0 $0 $0$0

History

4/19/2011
TechyGeek00x

ClientAccessPolicy & BLOB-Storage

If you would like to retrieve data from the Windows Azure BLOB storage via Silverlight, make sure your clientaccesspolicy.xml is written lower case.

History

2/28/2011
Andreas Nägeli

Service at cross domain with netbios name

I have the exact problem too. Same behavior (taking long time for the response) and finally getting the same exception. It only happens when deploying. It works perfect when debugging on Visual Studio and even deployed on my machine, but doesn´t work when deploying to the server. All the connection strings are correct. It´s a LINQ webservice wich connects to a remote sql DDBB $0I would like to know how you managed to fix it, if possible. Its driving me crazy...$0

History

2/14/2011
JBLince

Service at cross domain with netbios name (Itau BBA - Brazil)

i have the same problem. Only 1 client (1 specific domain user), the clientaccesspolicy return ok (i checked using fidller) but the SL4 application doesn't works. The "async" is called but the "completed" take a long time to respond. Message returned:

[Async_ExceptionOccurred]
Arguments:
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=4.0.51204.0&File=System.dll&Key=Async_ExceptionOccurred
at System.ComponentModel.AsyncCompletedEventArgs.RaiseExceptionIfNecessary()

History

1/10/2011
Alex Kubota

Service at cross domain with netbios name

We had a problem with service and cross domain boundary. There was no calls made from Silverlight app to the service located at different domain and everything looked good when I followed instructions descripted here until we published the app. Xap-application was published to domain1 and a service was running at domain2. There was no calls from xap to the service when it was published to the server but everything worked fine when it was ran from Visual Studio. The problem was that the service at domain2 was referenced with netbios name and after launching the xap-app from domain1 the netbios name wasn't workin for some reason.

History

1/7/2011
Äitiysvaatteet

Service at cross domain with netbios name

History

1/7/2011
Äitiysvaatteet

Breaking change

ADO.NET DataServices (WCF DataServices) will fail with InvalidOperationException (InnerException = Security Exception)
if policy file lokks like shown above.

Change policy file as follows:

<allow-from http-request-headers="*">

History

4/22/2010
Damir Dobric

6/7/2010
Thomas Lee

Broken Link

The following link is broken:

For more information about cross-scheme access, see Network Security Access Restrictions in Silverlight.

It should link to: http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx

History

5/24/2010
Rob Dil

6/7/2010
Thomas Lee