W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

XMLHttpRequest security section draft

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 20 Mar 2006 11:00:19 -0800
Message-ID: <441EFBC3.9070200@sicking.cc>
To: Web APIs WG <public-webapi@w3.org>
Here's a draft for a security section of the XHR spec. It's probably in 
desperate need of editing from someone with more spec writing experience 
then me, but it's a start.

/ Jonas

Implementations that run code originating from untrusted sources will probably want to place additional constraints on some of the features defined in this specification. This is not required and an implementation is free to ignore this section.

The restrictions are there to stop untrusted users of the API from using the implementation to retrieve sensitive data. Specifically, an implementation in a web browser will often want to restrict pages from a website A to retrieve data from website B. The reason for this is that website B could reside inside a corporate firewall. If data could be retrieved from website B then website A could use the browser effectively circumvent the firewall.

Another possible security attack exists if website B requires authentication, like for example a web bank. If website A were allowed to access data from website B and the user had recently visited the bank and at that time logged in, the page from website A would have access to private information like statements. If correctly crafted, a page from website A could even initiate transactions transferring money out of the browser-users bank account.

To stop these attacks the implementation should only allow a page loaded from website A to access other pages on the same website. Two websites are considered separate if they use separate DNS names, even if these names refer to the same IP. This is because the two websites could be hosted at a hosting service that place several websites on a single server and then use the requested hostname to choose which website to serve. Additionally, separate TCP port numbers or separate protocols (like http vs. https) are considered as separate websites.

The implemtation must be careful to always restrict access to the same website, not just during the initial HTTP request. For example if that request results in a redirect the implemenation should check that the redirect points to the same website and otherwise deny access.

Another feature that an implementation could limit is the setRequestHeader method. If the implementation allows the 'host' header to be set and two websites are hosted on the same server one website might be able to access sensitive information from the other website.

// Should talk about restrictions in HTTP methods
Received on Monday, 20 March 2006 19:00:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT