Browser Security Gets Even More Confusing (Cross-site Request Draft)
justin January 10th, 2008
I honestly thought that I’d covered all the ground I could on same-origin policy, but I just stumbled across the W3C draft on Access Control for Cross-site Requests. Apparently, this is implemented in the upcoming Firefox 3 and (given the author) can be expected to show up in Opera too. It seems this protocol’s sole purpose is to allow cross-site XMLHttpRequests to get through the same-origin policy. I admit serious dismay that no one is taking the opportunity to shore things up a bit while making new holes (especially considering my previous thoughts on the subject). However, I understand that developers are probably clamoring for the chance to make shiny new AJAX mashups and widgets. That said, I cannot understand is how this particular solution is the best we can get. Here’s a rough explanation of how the protocol works:
For a cross-site GET, the request is issued, and the response is checked for access-control headers (or header directives in the document), which determine what requesting domains are allowed to make cross-site requests. If the requesting domain is allowed, the response is made available to the script; otherwise, it fails.
A POST (or DELETE) is a bit different, and is handled in multiple steps in order to prevent unwanted side effects:
- The browser issues a GET request for the desired URL with a Method-Check header listing the method of the request that will follow.
- The server responds with access-control headers telling it what methods are allowed or denied for a particular set of origins.
- If the origin and method combination are allowed, the browser issues the cross-site POST request.
Now, this certainly adds some complexity to the browser implementations, but overall it isn’t too bad. The protocol also includes authorization caching to reduce the chattiness. However, things get much more complicated when you look at the server. One notable fact is that access-control logic will have to be implemented for every server page that handles cross-domain requests. So, rather than consolidate things into one easy to audit policy file, the logic will instead be spread out across potentially any page on the site (because even the static pages can include access-control directives in XML headers). You can also expect to see a lot of mistakes with the POST handling.
So, I have to ask, what is the value in spreading the origin policy exceptions across the entire web site? I’d expect that it’s going to make web-app security auditing a whole lot more complicated. I will preempt the argument that a policy file would expose site structure and cross-site relationships, as I’d maintain that information is already more than easy enough to get when spidering the site. Finally, doesn’t anyone else care about shoring up all the existing cross-site stuff so we have a little more defense against things like XSS and XSRF? Because I can’t see any way of Access Control for Cross-site Requests ever addressing the security problems we currently see every day.
