How to evade Silverlight cross-domain security law?

Question

how to evade Silverlight cross-domain security law?

This point is one that I need to go round Cross-domain calls - Browser or Client - Allowed when it is configured per client access policy file hosted on server.

Any ways? Articles? Libs?

Answer 1

Typically I think you could use a web service on your server to handle this. You should make what you pass through to your web service very specific. Do not allow the web service to just take a generic URL or else you could leave you web service open to be exploited.

Check out the following thread on the silverlight site talking about cross domain policy files as well:

http://silverlight.net/learn/videos/all/how-to-use-cross-domain-policy-files-with-silverlight/

Answer 2

Use some sort of proxy on a server you control - i.e. a service that your end user connects to and that itself connects to the network.

Any other answer will be almost by definition exploiting a vulnerability that will be patched in future versions of Silverlight.

Answer 3

The other posters have answered your question--or rather, the question you should have asked--so I'm probably wasting my breath.

But it might help--not only help us to read your question, but help you to resolve it on your own--if you try to reframe it in a more useful way. Instead of asking, "How do I do X," where X is something that cannot be done by design, you should ask, "What alternatives are there to doing X, since X cannot be done by design?"

In this case, the Silverlight cross-domain restriction is a security feature that's intended to be impossible to evade (and as rjmunro points out, even if there were a way around it, you wouldn't want to build a product upon it, since it will almost certainly be closed in the future).

There's another reason to ask yourself about alternatives that can fill the same role: this question focuses your attention on the security purpose of the cross domain restriction. If you ask yourself how to "evade" the cross domain restriction, you may well say, "Aha! I can just set up a simple web proxy open to all!" Unfortunately, this allows anyone to evade the cross domain restriction and execute in the context of your proxy.

By asking, "What alternatives are there to doing impossible cross domain calls," you (hopefully) remind yourself of why the cross domain policy exists, and--hopefully--consider the security implications of whatever alternative you implement.