A couple months ago I had a bit of an argument with an Opera developer. He was critical of MS with IE 8, because IE 8 will not pass cookies when doing a cross domain XHR. Like everything from Opera the argument is that it deviates from the standard, and as they like to toot their own standards compliance horn as their marketing message this is pretty much their primary form of criticism against any browser. I had a problem with this, because the concept is inherently flawed and I do not believe that standards (and lets be clear, when they say standards, what they mean is specifications, and not even very well written specifications) should be blindly followed when in contrast to security considerations. This could diverge into a general rant that I have about the W3C not being an effective body to begin with, producing neither horribly useful documentation, nor having an appropriate method to settle on specification to begin with, but I will save that for a later date.

Anyway, Cross domain XHR that passes cookies allows for private data to be retrieved off of remote sites, which is problematic because it only provides a mechanism to authenticate the user (and not a particularly strong one) but no means to truly authenticate the original site who served up a web page with the XHR (oh sure, you could check referrer headers and other such details, but the integrity of those are always suspect; it also increases the impact of XSS). It enables client proxies to 3rd party websites by design; website A asks client to retrieve data from website B for it. There is already a mechanism for two trusted domains to share information; federation and webservices. That way both endpoints as well as the client using the browser can all be authenticated. Yes, this requires more work. Doing it correctly always requires more work than doing it wrong.

Some websites will implement this all correctly- they will be very careful what data they let slip, what actions are exposed to cross domain XHR- but most will not (come on, they can’t even get input validation on their own forms right). It is like justifying the continued use of strcpy in place of strncpy because it is possible to use it correctly and it is just a pain to force developers to specify the buffer size. We as an industry know that we should ban strcpy, because even though it *can* be used safely, it is very common for developers to make mistakes with its use. The same can be said with cross domain XHR- it can be used safely but there are better methods available that inherently enable the developer to be more safe.

Anyway, I bring this all up because Window Snyder of Mozilla fame announced at Blackhat that, while it was pulled from Firefox 3 for security reason, Cross Domain XHR will be added back to Firefox 3.1 and pass cookies. I was very much hoping that both IE and Firefox would implement a safer XHR that did not pass cookies when going cross domain, but it appears that only IE 8 is willing to err on the side of security. That’s too bad. Fortunately NoScript will probably come to the rescue but I am really tired of having to rely on third parties to provide security for something that should be there from the start.

And Opera, sorry, I never was confident you were secure, especially since you don’t freaking star out password fields on your blackberry client, and the Cross Domain XHR only exacerbates things.

~ Joshbw