1

I got a problem when trying to call a remote rest webservice https://stackoverflow.com/questions/5442175/error-on-httpwebrequest

It seems it's due to cross domain policy file missing on the remote server http://forums.silverlight.net/forums/p/183993/419448.aspx

I don't understand the reason to have this file. It doesn't protect the user at all so for what purpose did they create this restriction ?

UPDATE: Reading the explanation from MS I still fail to see how this policy allows user to be more aware since it's all done on servers side WITHOUT EVER NOTIFYING THE USER OF ANYTHING.

UPDATE: Seems people don't agree so after all my question is not so stupid :) Answer would be Secure the service not the User ? Why on earth would twitter for example would like to protect its service without even wanting it ? If a website would want to protect itself it would just well put some login / password :) It is obvious that a site wants greatest access from browser it doesn't matter if browser uses plugin or not why would the site care ?

Community
  • 1
  • 1
user310291
  • 36,946
  • 82
  • 271
  • 487
  • How does username password protect misuing twitter's webservice by other twitter competitor? Honestly question is not stupid but you just need little more experience in context of webservice security. – Akash Kava Mar 27 '11 at 06:29

3 Answers3

4

It's for security and making you actually OPT IN to allowing it.

MSDN explains it the best so there is no point in me re-wording it:

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.

Kelsey
  • 47,246
  • 16
  • 124
  • 162
  • I fail to see how this policy allows user to be more aware since it's all done on servers side WITHOUT EVER NOTIFYING THE USER OF ANYTHING ? – user310291 Mar 26 '11 at 17:25
  • @user310291 it is to secure the service not the user directly. Here is another good SO read: http://stackoverflow.com/questions/587981/what-is-the-sense-of-crossdomain-xml-and-clientaccesspolicy-xml-when-there-is-e-g Your service can't be exploited by clients you have not opt'd in to. – Kelsey Mar 26 '11 at 17:37
  • Secure the service ? Why on earth would twitter for example would like to protect its service without even wanting it ? – user310291 Mar 26 '11 at 18:20
1

Here is something to consider. Assume a world where Silverlight did not require a web service to opt into being used by a Silverlight client or a indeed a Flash client come to that.

Some malcontent manages to find a weakness in a popular web service API and writes an exploit in Silverlight or Flash. Harm is done and users of this web service are upset. Where might the finger of responsibility get pointed? What happens when it gets into the news that a Silverlight or Flash plugin was the "cause" of some breach? Whose reputation is harmed? Answer: Microsoft / Adobe even though in fact it has nothing to do with them.

Ultimately this is about public relations, about the risk of there being a perceived insecurity where none is really warranted.

By including this opt-in requirement these companies massively reduce the number of services that could possibly be exploited using their plugins. Significantly reducing the risk that their plugin would unfairly be tarnished with an uncalled for reputation. For those that do opt-in the policy files can be pointed at as the responsibility of the service provider who made an informed choice to include such a file.

Ultimately if there is a choice between risking your public perception with 100,000,000 potential users or risk some disgruntlement and bewilderment of some 100,000 potential developers I know which one I would pick.

AnthonyWJones
  • 187,081
  • 35
  • 232
  • 306
  • You said "Some malcontent manages to find a weakness in a popular web service API and writes an exploit in Silverlight or Flash. " Then I could say "Some malcontent manages to find a weakness in a popular web service API and writes an exploit in Browser." – user310291 Mar 27 '11 at 11:42
  • Then why not oblige Browser to do the same ? – user310291 Mar 27 '11 at 11:44
  • @user310291: So a browser provider decides to do that with their latest browser. Suddenly services that were __already__ working now stop working when used in their new browser. More bad PR. These decisions can't be completely defended on logical technical merit alone. Besides it is less likely that a browser based Javascript expolit against a site would require a __specific__ browser to be successful. – AnthonyWJones Mar 27 '11 at 12:26
0

Imagine you have a webservice, which is on your website, it displays live stocks and you want this website to be used by only your silverlight client.

Now I can write a silverlight client and put it on my website that will fetch data from your website, I can steal your data and users will feel it's my data. As there is no way o determine who is connecting it.

So silverlight loaded from my domain will not connect unless you allow from your domain. This is not for server client security but this is for cross domain security. Same as JavaScript cross domain security that you can not access any objects loaded from different domain.

Akash Kava
  • 39,066
  • 20
  • 121
  • 167
  • That's clearly not the reason. Cross domain security protects the user from evil silverlight applets, and not your website from the competition. The user can easily circumvent the protection by granting additional privileges. – CodesInChaos Mar 26 '11 at 17:37
  • not the same as Javascript cross domain since the server cannot circumvent this by adding a cross domain policy file which alleviates this without user even knowing it – user310291 Mar 26 '11 at 18:30
  • @CodeInChaos where in silverlight hosted in browser you can elevate privileges? If you notice the example in msdn it's quite similar. Cross domain policy is for anything that is in browser, anything with elevated privilidges is sort of native app which has full control. – Akash Kava Mar 27 '11 at 06:19
  • @user310291 by same as JavaScript, I mean the concept of cross domain call security. Try to understand, your site is contains banking web services, I can easily connect to your webservices from my silverlight hosted on my site and it can do wrong things. – Akash Kava Mar 27 '11 at 06:26