Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

Cross Domain Support in IE 8 and Silverlight/Flash Applications

On this page:

Peter Bromberg posts a quick note about the IE 8 Cross Domain Request object which allows making cross domain calls from within the browser. If you'll recall traditionally the XmlHttp object now standard in all main stream browsers does not explicitly support cross domain calls, which are blocked for security reasons. What's a real pisser about this though is that there are other ways to make this happen by using <script> tags and nested IFrames, so I've always thought that this restriction isn't exactly something that really helps since there are other ways to perform those malicious tasks anyway. All it does is make legitimate x-domain access a pain in the ass as you pretty much have to proxy through a server to get the data and the retrieve it with Ajax. There are also other options like JSONP which is actually similar in behavior to the new x-domain control.

The IE 8 cross domain request object is supposed to address this shortcoming by providing an explicit API for making the x-domain calls. I haven't played with this myself, but looked over the documentation and Peter's post and the idea is basically that the server has to respond with a special header that says it supports and authorizes the cross domain call by adding a special header to the output ("XDomainRequestAllowed: 1").

Maybe I'm missing something here, but isn't that kind of pointless? The threat of a cross domain call is that somehow malicious script can get into a page and then 'phone home' sensitive data.  The malicious code can take local browser data (like Cookies or other stored data) and forward it to another URL which can then capture and thus compromise the data. That's classic cross domain hi-jacking.

Ok, so how does requiring the server to have the this custom header help? If your goal is to hijack user browser information and post it to some URL you as the malicious hacker can easily enough add the header to your server target url. Assuming that the malicious target has control over the target server (likely) it's completely trivial to include this header. I don't get it...

Cross domain callbacks can be tricky to detect and catch, but this sort of thing seems just a complete waste. Given that other ways still exist (namely the <script> tag hole) why are we bothering trying to veil a technology that doesn't solve the problem in the first place. Sure having this cross domain object is useful because you can at least get at the data more directly than having to screw around with script tags or IFrames, but if that's the case I'd have fixed or provided similar functionality maybe with a new flag on XmlHttp. Why the heck do we need another new object that's not even going to be standards compliant on top of it.

Cross Domain Policy Files - Same Issue?

Incidentally the same issue applies with Cross Domain Policy files that Flash and now Silverlight 2.0 uses (Silverlight can use Flash Cross Domain files):

<?xml version="1.0"?>
  <allow-access-from domain="*.west-wind.com" />
  <allow-access-from domain="*.americanparanoia.com" />

This file is stored on the Web Server in the root directory or any directory up the hierarchy to the virtual. The client reads this file from the Web server and based on that enables cross domain access to the server.

Again I wonder what this accomplishes. How is this helping prevent a malicious hacker site from placing a policy file on their machine and allowing the cross-domain access?

Somebody enlighten me <g>...

Posted in HTML  JavaScript  

The Voices of Reason


March 16, 2008

# re: Cross Domain Support in IE 8 and Silverlight/Flash Applications

This prevents accidental exposure of internal web services via a malicious web app. Take e.g. a Silverlight app that tries to connect to IPs in the range 10.1.*.* to see if anything is responding and then sending those responses home. Anyone within the network would expose the entire intranet by just navigating to a site with the malicious web app on it. By explicitly having to enable x-domain acccess on a server you can be sure that your webservices are only exposed to machines you want them to.

Rik Hemsley
March 16, 2008

# Server end is the problem

Don, I think Rick was making the point that IE asks the server on which the application is hosted whether it's allowed to go 'cross-domain'. Surely this means that the control is in the hands of the server 'owner' - not the person using the app via IE?

Rick Strahl
March 16, 2008

# re: Cross Domain Support in IE 8 and Silverlight/Flash Applications

@Don - I agree with Rik. I don't think that we're talking about protecting the server with these mechanisms. Servers are always vulnerable to any IP/port attacks from non browser HTTP/IP clients from any desktop app.

Unless I'm missing something these machinations - the server header in IE 8 and a cross domain file - are meant to 'acknowledge' to the client that it's safe to use the remote domain for x-domain calls.

My point is that if the server is in control of a malicious party in a phone home sceneraio, the server can place any policy files or Http headers it wants and so I don't understand how this helps prevent a cross site scripting attack.

If a malicious user plants a Silverlight app on a page (maybe loaded via malicious script code embedded in a comment (if the Html shown wasn't encoded) etc.), captures Cookies data from the page and then sends the browser's cookie information to the malicious hacker's server. How does the server policy/header prevent that scenario given the mailicious party has access to the server and can place/modify any content it presents? Isn't that the classic cross site scripting scenario that's not being prevented here?

Cross site scripting is a real problem, but it seems to me these machinations do little more than make it difficult for legitimite applications to actually access remote data. If it's that easy to get by it there might as well be no restrictions...

Steve Sanderson
March 17, 2008

# re: Cross Domain Support in IE 8 and Silverlight/Flash Applications

Rick, there are two major flavors of cross-site attack: cross-site scripting (XSS) and cross-site request forgery (CRSF).

Above, you describe a XSS scenario and its risks (e.g. cookie stealing, phoning home) and correctly observe that the new cross-domain request object doesn't make any difference in protecting a site from it.

What you're missing is the CRSF scenario. Current browsers prohibit me, from www.pirate.com, using script to cause a GET or POST request to www.bank.com and actually reading the response data back in my script that I host on www.pirate.com. This is important because requests sent to www.bank.com will include the cookies for that domain and may therefore be treated as authenticated requests, for which the server will return sensitive information. You don't want that sensitive information to be retrievable by the script running in www.pirate.com.

This new header allows cross-domain requests to read data across domains *only* if the target domain opts-in on a *per-request* basis. Obviously, www.bank.com isn't going to opt in for any sensitive URLs, but it might choose to do so for some kind of non-sensitive API (stock quotes or whatever).

Peter Bromberg
March 19, 2008

# re: Cross Domain Support in IE 8 and Silverlight/Flash Applications

Ian Griffiths has an interesting post with his discoveries abou this:



Joe Brinkman
March 21, 2008

# re: Cross Domain Support in IE 8 and Silverlight/Flash Applications

I would think that the large majority of XSS attacks do not involve a hacker actually "owning" the server, but rather are the result of a hacker being able to inject a small portion of code. In most scenarios, the files on the server are not compromised and thus the hacker would have no control over the policy files.

Rick Strahl
March 21, 2008

# re: Cross Domain Support in IE 8 and Silverlight/Flash Applications

@Joe - if you mean by "owning" the server, as in hacked into your server/site that not what I meant <g>. I meant owning a remote server that is used as drop point for any hacked data (cookies, other confidential page data possibly).

If a hacker injects script code on your server/site, and uses XSS to send data to his remote server - that's the real problem the way I see it. And nothing in the above prevents that since the hacker can own the remote server and run whatever policy files or HTTP headers he wants.

Joe Brinkman
March 22, 2008

# re: Cross Domain Support in IE 8 and Silverlight/Flash Applications

@Rick, Maybe I am misunderstanding the intent of the headers and policy files. Are those not served from the originating domain? It would seem that that is the appropriate domain that needs the protection not the target domain. So if my site is www.dotnetnuke.com, I believe the intent is that dotnetnuke.com's policy would have to allow scripts to talk to any domain other than DotNetNuke.com. The policy should be served by the domain hosting the page not the domain hosting the script. My reading of the Access Control for Cross-Site Requests working draft (http://www.w3.org/TR/access-control/) and the beta MSDN docs on XDR indicates that this is the model that is used. Although Microsoft's documentation is a bit sparse, I have not found anyone who has shown any working code that indicates which is the correct interpretation, although I have seen a couple of examples where devs have said that they tried serving the headers from the target server as you suggested above and it did not work. This would seem to support my interpretation of the intent of XDR. Once I get home tomorrow, I'll try to do some testing to see if I can actually get this to work.

Rick Strahl
March 23, 2008

# re: Cross Domain Support in IE 8 and Silverlight/Flash Applications

@Joe - The more I read about this the more confusing it gets. I would think if the hosting domain can specify what domain IT allows that would make a lot of sense, but I don't think that's the way it works.

So, I did a quick test in Silverlight to see WHERE the crossdomain.xml file is looked for. Neither client nor server includes a crossdomain.xml file. I created a small app on my local machine that does:

        private void btnTest_Click(object sender, RoutedEventArgs e)
            WebClient client = new WebClient();
            client.DownloadStringCompleted += new DownloadStringCompletedEventHandler(client_DownloadStringCompleted);
            client.DownloadStringAsync(new Uri("http://www.west-wind.com/info.txt"));

        void client_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)

Hooked up Fiddler and it's DEFINITELY going to www.west-wind.com/clientaccesspolicy.xml and crossdomain.xml both of which fail because they are not there.

So it's definitely on the TARGET server, not the originating domain that needs the cross domain file.

If I then add a crossdomain.xml file like this on www.west-wind.com:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy 
  SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
  <allow-access-from domain="*" />

The request works.

So my question remains. What the heck does a server side policy do for anybody? It doesn't protect the client and XSS attacks. If www.west-wind.com were the server of a malicious hacker to phone home to, access would be allowed.

Dave Reed
March 30, 2008

# re: Cross Domain Support in IE 8 and Silverlight/Flash Applications

My take on it, the x-domain policy file isn't trying to prevent cross-site scripting. A hacker who successfully injects code into their target site can already use a simple script element to send data to their server, so why would they even care about a new technology that does the exact same thing?

What it does do is allow the client to not only make a request to another domain, but to READ the data in the response (without invoking JSONP, etc). A cross-site scripting attack cannot read response data.

Imagine I manage to inject script into west-wind.com that sends a request to www.bank.com/myaccounts, gets the response, and sends it to www.pirate.com. That way anyone who happens to log into their bank.com account, and then happens to navigate to west-wind.com, will expose their bank data to pirate.com. That isn't possible today because you can't READ the data that comes back from bank.com (unless bank.com foolishly publishes sensitive data via JSON-P). Well, now thanks to a cross domain policy, bank.com can expose webservice data easily to other domains, like stocks.com, without making them vulnerable to this kind of attack since they get to choose who they trust. What you get is a cleaner x-domain system that doesn't require customized authentication to prevent the entire world from accessing it.

Jon Galloway
December 12, 2008

# Silverlight Crossdomain Access Workarounds

I was testing out some typography with Silverlight and figured I’d try grab some text from Wikipedia

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024