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"?>

<cross-domain-policy>

  <allow-access-from domain="*.west-wind.com" />

  <allow-access-from domain="*.americanparanoia.com" />

</cross-domain-policy>

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>...