Wednesday, November 21st, 2007
Cross Domain XHR W3C proposal
Category: Security
, XmlHttpRequest
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:
HTML:
-
-
Access-Control: allow <*.example.org> exclude <*.public.example.org>
-
or an XML processing instruction:
XML:
-
-
<?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:
The core XMLHttpRequest object itself has also seen a recent new draft.
3.4 rating from 45 votes
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?
…interesting… the more news, feedback, thoughts on this, the better.
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!
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.
While it’s not possible we have to use script on-demand. Globo Videos started using this approach in the new version.
very nice implementation. hope this will come soon!