Confused about cross-domain calls


  • Hi folks,

    I am confused about the cross-domain calls policy in Silverlight 3.

    At the moment I have not done anything in my application to enable/disable cross-domain calls (so I am using the default policy). I am running the app in Visual Studio's builtin server.

    I have already some code in the app that uses WebClient.DownloadStringAsync() to download content from and it works fine.

    Then I wanted to download content from and I got a security exception.

    My understanding is that the access rights would be defined in the crossdomain.xml file, but that would be the one at

    So the exception I get is because Google is preventing access from RIA client? 

    Is there anything I can do about it?

    Any input appreciated.



    Sunday, April 11, 2010 10:28 PM


  • You're right : the xml policy file must be in the server root. If you control the server you can add SL support, if you do not control the server (like google one) you can just play with what they are accepting. If they do not offer a SL policy, you'll not be able to download anything.

    Monday, April 12, 2010 9:19 AM

All replies

  • You're right : the xml policy file must be in the server root. If you control the server you can add SL support, if you do not control the server (like google one) you can just play with what they are accepting. If they do not offer a SL policy, you'll not be able to download anything.

    Monday, April 12, 2010 9:19 AM
  • Thanks for the confirmation. I guess I'm gonna have to use a web service as a proxy then.
    Monday, April 12, 2010 7:51 PM
  • Coming back to that topic though, to say I think it is a huge limitation.

    I had in mind to create a Silverlight RSS reader. Turns out I can't retrieve any RSS feeds since they are in different domains and most of them do not have a cross domain access policy.

    Am I missing something?

    Is the upcoming Silverlight 4 release going to make it any better/worse?
    Tuesday, April 13, 2010 11:39 PM
  • You're right. I'm also thinking this is a huge limitation that is very bad for Silverlight. For example, there's a while ago, I started to develop a cool SL tool allowing to ping servers and have an eye on it. .. Until I discovered this limit without findind any solution (else than building a proxy on one of my servers, but I was not able to distribute the tool since I don't want all the users of my tool to pass thought my server !).

    So, it's a bad limitation. SL app should be able to download any public content. anyone can read a RSS or ping a server, I can't understand this limitation in SL.

    And I did not see anything correcting this in SL4 (or I missed something).

    Thursday, April 15, 2010 9:35 AM
  • Well it's a security restriction

    In all cases, there is a need to provide security and prevent Silverlight applications from initiating unauthorized connections. Potential networking threats to be mitigated include:

    • Denial of Service (DoS) attacks – A large number of remote hosts are used to attack a target site so that the target is unable to service valid requests.

    • DNS Rebinding attacks – Use DNS to force a remote host to rebind a trusted host name (site of origin) to a victim’s IP address, thus allowing access to a host other than site of origin.

    • Reverse tunnel attack – Use a remote client’s outgoing connection as a back tunnel to the client’s private network

    More info:

    So if the server does not allow cross domain access (some of them yes, facebook, twitter), you have to use a proxy service, or not sure if your application is an out of browser + elevated permissions you have that restriction.



    Friday, April 16, 2010 1:01 PM
  • To be perfectly clear, of course I know it is for "security" reason", but I do not agree this reason.

    If a content is free to download on the web, if a server is accepting to be pinged, then there is no valid reason to cut these possibilities only in SL. THere thousands ways to hack a server, suppressing just one possible kind of hack is not reasonnable. Let servers manage their own security. Every piece of software can be used to hacked a server. Even JaveScript, all tools have weakness (outlook, IE, safari,...). So the "best practices" are to build solid servers not to cut the possibilities of client tools.

    This is my point of view, of course.

    Saturday, April 17, 2010 6:33 AM
  • Well I think security is a tetchy issue, as you said servers must be solid but if somebody publishes in the news "Silverlight Application knocks down server XYZ"... it will make a lot of people (without proper knowledge but with power of decisition) go back and not to invest on Silverlight.

    I think something similar happens with the SL HTML embedded control, not working on web app's because of security.

    Too much years of ActiveX bad reputation have lead us to this current scenario :).



    Saturday, April 17, 2010 8:35 AM
  • Part of the problem hare is this:

    say MS left it open in the way you descibe....

    say that evil black hat developer writes an app that messes with some big sites by creating a distributed attack on them...

    in the press how will the headlines read?


    and in the last paragraph would be the detail that some developer wrote the evil app.

    sad but true.  MS has to be very carefull to not get any more bad press cause the public, the politicians and the press are all fast to jump on a new MS story and go of on how evil they are.


    Saturday, April 17, 2010 9:04 AM
  • Totally agree, I'm the first one that gets angry whenever something is cut by security restrictions (cross domain, embedded HTML, getting images from cross domain...), but one important thing is that right now nobody is thinking about not using Silverlight because of security concerns, that didn't happen for instance with the ActiveX Technology.



    Saturday, April 17, 2010 11:26 AM
  • I perfectly understand the "marketing" reason. Of course SL must not be associated with hack or piracy.
    So, even if it is annoying, I fully agree the need of the sandbox, the trusted level and all those things, because no one must (at least now, when SL try to take over the world dominated by flash) be able to create a malicious software using SL.

    But the xml policy file is another story :technicaly this is avoiding to develop tools, apps or gadgets that interact with the web. This is not reasonnable. SL must not avoid developers to access _public_ resources of the Web. If some web sites managing sensible data are storing credential in a cookie, they must be listed, banned from the web and their developers hang on the next first tree. But SL must allow to access public resources.

    Another point to prove this is stupid : I can currently build a SL app that will use a proxy on my server to make all those prohibit things.

    Do you thing, if I'm a bad hacker and if I hack bank accounts using a SL/Proxy combination, that people will understand that this is not the SL fault because there is "proxy" (what is that?) that help the SL app to make the hack ? So avoiding this directly from SL is stupid, useless, and avoid the vast majority of "good" developers to create innovative tools using SL. IMHO this is worst for SL market peneration than a possible CSRF hack using SL on a weak server...

    Well, that's my opinion and I know this is a controversial subject and "pro" and "con" will not change their mind easily !

    So ... Happy coding to all ! Drinks

    Sunday, April 18, 2010 1:48 PM
  • Hi all, great conversation.

    I work on Silverlight's security -- hopefully this post about why cross-domain policy files are necessary can help provide some rationale.

    >>>SL must not avoid developers to access _public_ resources of the Web

    It'd be great if we could allow this -- the problem is, it's hard to tell if a resource is public.  The best way we know of it to have the site publish a policy file to indicate that it intends to be public.  I agree, it's not perfect, it'd be great if we had a better way to tell.

    >>>I can currently build a SL app that will use a proxy on my server to make all those prohibit things.

    Yes, but the cookies that get sent for that request will be for, not  CSRF is really about making malicious requests in the context of a victim user.  If you make the request from, wouldn't have any way to associate that request with the victim's account.  (at least not for the popular auth schemes I'm aware of)

    You mentioned in that SL should consider displaying a confirmation dialog to the user before allowing an app to make a connection to a URL w/o a policy.  This is an interesting idea -- it may be something we could consider in a future release.

    Sorry for the inconvenience.



    Wednesday, April 21, 2010 6:46 PM
  • @Jesse: I’m reflecting the discussions in both threads and I’m asking myself whether it would be possible to ignore the policy file restriction when communicating via the client-http stack or not. Only the browser-http stack sends browser-cookies along the request or responses to authentication negotiation such as NTLM or Kerberos. When communication via client-http stack CSRF isn’t possible anymore, right? This would keep the plugin secure by design and lets the possibilities open to consume any web resource without having the policy file in place.

    Thursday, April 22, 2010 4:04 AM
  • Interesting article, and interesting idea the thing of warning the user if the application is trying to make a cross domain call without proper policy, even it could have a tick/check box indicating "don't warn me anymore on calls for this cross domain".



    Thursday, April 22, 2010 4:37 AM
  • Thanks Jesse for your answer.

    I really thing a confirmation dialog will be a good way to mix the two goals : security and usability of SL.

    My point of view about what is "public" or not on a server is very very simple : if it can be accessed from outside, this is public. If a server doesn't want you to access the ressource, no need of any policy file : the ressource is hidden, its folder has no read rights, etc.

    But of course, a hack is always possible.. So the confirmation dialog is not a perfect solution, but will be better than just cutting all possibilities (because policy file can't be added on most servers it is like killing all possibilities).

    Thanks again for your answer (and hoping the dialog option will be studied as a valid option to please everyone :-) ).

    Thursday, May 13, 2010 2:44 PM