Anne van Kesteren has a blog post deriding MS for deviating from the proposed standard with the inclusion of XDomainRequest. Your can read the horribly dry standard as well as the design decisions behind it here. To be blunt, the standard (as well as Mr. van Kesteren) is wrong and MS is right in this case, though if you have read a previous post of mine it should be evident that I think standards bodies generally suck at including security. I think the W3C has a habit of focusing on what web developers want to do, and not whether they *should* be able to do it (essentially the same problem MS had pre-SDL; give the users what they want, not what is in their best interest).
Key to the proposed standard, ”cookies and authentication information should be sent in the request”, which is a horrible, horrible idea. Sure, it allows the inclusion of session specific information, information for a specific user, from an external domain in the web page the user is viewing which could have some interesting mash-up results, but it also allows the website making the request to access to that information. In response headers, which necessarily need to be queriable from JavaScript to see if the request worked, that cookie information is going to be readable as will the potentially sensitive information returned as content. There is no good reason why my website should have access to any other website’s cookie info.
One could argue that a website can always deny a request from an external source unless it happens to be from a specific domain (hah, as if that would be spoofed), and essentially grant content only to predetermined trusted callers, but there is already a mechanism for that. If I have an agreement with Amazon to access their user specific data from my website, I can do so through a webservice call in my server side code. It does require a bit more work, but that extra work will require both parties to think very carefully about what is exposed and what level of access to give.
If this is implemented in a browser, it will be exploited. Large websites with a strong security record will likely implement this functionality securely, but there are a whole lot of companies out there without strong security records, with marketing people calling the shots, who will allow unrestricted third party websites to make calls to their protected content. The security community will figure out how to steal cookie information using it (with the current proposal, it would be sort of trivial). The idea that “Cookies and authentication information is already sent cross-site for various HTML elements, such as img, script, and form. This means that such a request does not introduce a new attack vector.” as the design decisions for the W3C proposal states, is hopelessly naive. Citing requests made outside of JavaScript, where the browser returns no significant information to potentially malicious scripts, is very different from making said requests and granting access to the response and content inside of script. That the standards body can’t grok the difference is quite worrisome.
Microsoft is absolutely correct in their implementation of XDomainRequest. It should only have access to information that the whole world has access to, and it should not pass any sensitive information (like sessionIDs stored in cookies) that the original domain does not already have access to. Is it restrictive, absolutely, but for the blackhats as well as the web developers. That is sort of the point. There are secure ways to retrieve information from another domain. It does require more work. It also requires more work for me to have to verify my identity when using my credit card than it would if everyone would just trust me, but I think we can all agree that is for my own good.
For all of you complaining about MS not supporting the standard with this, please stop considering for a moment what you could do with the W3C proposal, and consider what a malicious person could do.
~ Joshbw
7 comments so far
Leave a reply