W3C - Enabling Read Access for Web Resources
16 November 2007W3C has recently created a proposal for adding cross domain capabilities to the XMLHttpRequest (XHR) object. The proposal specifies how XHR can communicate with servers so that servers can explicitly opt-in to provide controlled access to their resources from other sites. I believe this proposal has great potential for providing a solid robust mechanism for secure mashups that isn’t built on various hacks. 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 advices agents not to expose any trusted data, such as cookies, HTTP header data, inappropriately, but it is unclear how that is determined.. This will hopefully 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.
This proposal seeks to adds similiar functionality as JSONRequest in terms of adding secure cross site access. Here is a short contrast between JSONRequest and this new proposal (W3C/AC):
| JSONRequest | W3C/AC | |
| Format constraint | JSON data only | Any format (provided as text through XHR) |
| Opt-in method | Add header Content-Type:application/json-request | Add header Access-Control: allow <*.example.org> |
| Domain Control | Only programmatically based off request source information | Fine grained control determined by Access-Control information |
| Performance | JSON can be parsed natively for improved performance | non-GET operations required a previous GET operation which can take extra time |
| Headers | Cookies removed, no user defined headers | Cookies and headers may still be sent. Spec advices agents not to expose any trusted data, such as cookies, HTTP header data, inappropriately, but it is unclear how that is determined. |
| HTTP Methods | GET, POST | Any (non-GET require explicit permission) |
| POST access | No prior authentication required (but cookies are still stripped) | Must be explicitly allowed in headers prior to the POST |
The W3C/AC in combination with getters/setters and a possible sandboxing mechanism in ES4 would also potentially allow sites to load and sandbox cross site advertisement scripts (one of the greatest XSS vulnerabilities on the web). I am all for this proposal. I know that new proposals that could open new vulnerabilities naturally cause fear and uncertainty, but this is a well thought out proposal that provides a solid mechanism for providiong cross site data, and is vastly better than the hacks we are currently working with. Both W3C/AC and JSONRequest would be both be fantastic additions to the browsers and open up huge opportunities for improving security of cross-domain mashups.
One Response to “W3C - Enabling Read Access for Web Resources”
April 15th, 2009 at 10:59 am
I can tell that this is not the first time at all that you write about this topic. Why have you chosen it again?