Wednesday, November 21st, 2007

Cross Domain XHR W3C proposal

Category: Security, XmlHttpRequest

<p>The W3C has a new proposal titled Enabling Read Access for Web Resources which defines access control primitives to be used for cross domain XHR.

You can set control via a HTTP header:

  1. Access-Control: allow < *.example.org> exclude < *.public.example.org>

or an XML processing instruction:

  1. < ?access-control allow="allow.example.org" deny="deny.example.org"?>

so no cross_domain.xml.

Kris Zyp has written up his thoughts on the proposal:

A number of things to understand about this proposal:

  • It does not create any new vulnerabilities with existing servers. Cross domain XHR will always fail with existing servers until they have specifically added headers to define the access control. In other words it doesn’t add new vulnerabilities to the web, rather it allows those who want to add cross site access the ability to due it in a secure manner without hacks like JSONP or fragment identifier messaging.
  • Both GET and POST can currently be executed cross site with scripts tags or form submission, so many threats such as CSRF and DOS already exist, the proposal does not introduce them.
  • The proposal states that cookies should be removed from cross site requests. This will reduce the incident of cross site request forgery, and forces developers to use more secure explicit forms of authentication maintanence.
  • Developers that allow cross site access still must ensure that they are not providing privileged information to sites that should not be accessing the information. Developers that allow POST and other modifying operations should take similiar precautions.
  • This provides a fine-grained access control level. When servers define access control headers that allow cross site access, they can specify which web page domains are allowed to access their resources.

Kris also has a comparison with JSON approaches:

Cross Domain JSON Comparison

The core XMLHttpRequest object itself has also seen a recent new draft.

Related Content:

Posted by Dion Almaer at 6:56 am
6 Comments

+++--
3.4 rating from 51 votes

6 Comments »

Comments feed TrackBack URI

This is great news! It will remove the necessity of my numerous poor-man’s-proxy scripts to broker my AJAX requests…

But what will be the migration strategy for the various web and app servers to adopt it?

Comment by Joe Travaglini — November 21, 2007

…interesting… the more news, feedback, thoughts on this, the better.

Comment by Mark Holton — November 21, 2007

Very nice. At the very least, it would remove an annoyance I have with my scripts. If I have a.domain.com and b.domain.com, JavaScript sees them as separate domains and refuses to allow XMLHTTP connections between the two. With this, I could set up each to get connections from the other and finally be able to communicate between all of my *.domain.com websites!

Comment by Jason Levine — November 21, 2007

Interesting proposal. I hope it gets adopted although there’s certainly a need for something even more comprehensive.

Out of curiousity, where it states “…forces developers to use more secure explicit forms of authentication maintanence.” what exactly would those be? I’m in need of auth maintenance on a current project in this XHR context and am intrigued by what this statement implies.

Comment by Barnaby Claydon — November 21, 2007

While it’s not possible we have to use script on-demand. Globo Videos started using this approach in the new version.

Comment by Tiago Albineli Motta — November 22, 2007

very nice implementation. hope this will come soon!

Comment by backdraft — November 23, 2007

Leave a comment

You must be logged in to post a comment.