Cross Site XMLHttpRequest

Cross-Site XMLHttpRequest allows a web page to read information from other web servers using norm XMLHttpRequest. In the past this has not been permitted since the other server may be sitting inside a corporate firewall or may be a server where the user is logged in.

To solve this problem it is suggested that the accessed server can signal back to the browser that it is ok for other sites to access certain pages on the server. Firefox checks for this and only returns the response to the page if the server explicitly allows it. Otherwise the browser will throw away the response from the server and throw an exception.

Details

There are currently two draft specs from w3c for how this should work. The signaling for when a document is accessible is spec'ed in the access-control draft spec [1]. This states that the site can insert <?access-control?> processing instructions into XML files that says which sites can access the file. It also allows for http-headers to be added to allow access to be controlled to any file type.

The PI contains lists of URL patterns that describe which URLs can access the file. These patterns can contain wildcards, but follow strict parsing rules rather than being general URLs.

Additionally [2] is a draft spec for how XMLHttpRequest should interact with the access-control spec. This spec describes some headers that should be included when making a cross site request. (Though I personally wonder if this part should be moved into the access-control spec.) It also describes how to deal with http methods other than GET and POST.

Suggested Implementation

A goal of the implementation is that it should be reusable for other things than XMLHttpRequest. For example document.load should be able to do the same cross-site loads with the same restrictions. As should XSLT and XBL.

To do this we'll set up an nsIStreamListener that sits between the normal nsIStreamListener and the nsIChannel. Once onStartRequest is called we check for access control headers. If the headers deny access we cancel the channel with a network error failure. If headers allow access we pass through all calls to the outer caller.

If headers don't say either way and the content type is an XML one (do we have a good way to determine that?) we set up a parser and ourselfs as sink. We'll then listen to notifications until the first start-element notification. At the same time we have to store all incoming data that is fed to the parser. If the access control PIs doesn't indicate that access should be granted we cancel the channel.

If access control is granted we forward calls to the outer caller and stream the buffered data to it.

Issues

• We have to check that the code in onStartRequest in the original streamlistener doesn't do things that are too late to do once the delayed onStartRequest is called.

• Is it possible to cancel with a network error if we get a 404 or 401 or similar? This would be a good way to avoid making it possible for the site to check for the existence of files on the server or check if the user is logged in or not.

Security worries

• The first thing that worries me is that you can make POST submissions to any url and include XML data as payload. It is already possible to make POST submissions to any url, but the only possible payload is plain/text encoded form data or multipart/mixed encoded files and form data. With Cross-Site XMLHttpRequest it would be possible to send XML data. In particular there is worry that this would make it possible to do SOAP requests to any server. Note that while the page would be unable to access the data returned by the SOAP request, that isn't necessary if the request itself is "transfer all users money to account 12345-67". To avoid this we could either use the model as for non-GET-non-POST requests defined in the XHR spec [3], or we could use something like [4]

• Should we try to follow these specs even when accessing files on the same domain? From the sites point of view they can't rely on that anyway since all browsers don't support the access-control spec (and old versions never will).

• We have to make sure to not notify the onreadystatechange listener or any other listeners until we've done all access control checks. Otherwise it would be possible to check for the availability of files on other servers though you couldn't actually read the content.

• We have to make sure to not put data in .responseText until we've passed access control checks even for XML files.

• We have to make it impossible to distinguish between a access-control-failed error and network errors such as 404s. Can the implementation "recancel" a canceled channel?

• Should we check for PIs even if HTTP headers has said that access is granted? It'll always be possible to circumvent those headers using .mimetypeOverride which'll make us not treat the doc as XML and thus we won't even look for PIs. Alternatively we could ignore the .mimetypeOverride when checking for PIs but that might be a problem with poorly configured servers (which is the whole reason for .mimetypeOverride)

• We should make sure to make it impossible to set authentication headers since that would make it easier for a site to attempt (distributed) brute force hacking against authenticated servers. Note though that such hacking would be significantly complicated by the fact that the server must be password protected but still have files that it grants access to a 3rd party server, which doesn't really make a lot of sense.