(XMLHttpRequest 2) Proposal for cross-site extensions to XMLHttpRequest

Here is a proposal for the XMLHttpRequest 2.0 specification for how to 
enable cross-site XMLHttpRequests. I just thought I'd throw it out there 
for everyone to see what security problems they can spot. :-) It's based 
in part of Yahoo!'s JSONRequest proposal and on the comments that proposal 
generated on the WHATWG list.


If the open() method is called with a URI that points to a third-party 
domain, then:

   setRequestHeader() must be prevented from setting the Domain and 
   Referer headers.

   send() must include a Domain: header that consists of the scheme, 
   hostname and port portions of the original domain of the global scope 
   of the script originating the request in every request in causes to be 
   sent to a third-party host. The scheme must be given first, in 
   canonical case, followed by a U+003A COLON. If the scheme supports
   hosts and ports then the colon must be followed by two U+002F SOLIDUS
   characters followed by the canonical punycode representation of the 
   host name. If the port is not the standard port for the given scheme, 
   then the host name must be followed by a U+003A COLON and the port 
   number.

   If the method is GET, then the send() method must fetch the resource 
   indicated by the URI, then must perform an access check (see below), 
   and if that is positive, it must make the document available (see 
   below). If the check is negative, it must act as if there was a 
   network-level failure.

   If the method is not GET, then the send() method must make a GET 
   request to the third-party host at the given URI, without any payload.
   If the request is successful, the user agent must perform an access
   check on the returned document (see below). If the check is positive, 
   then the UA must send the actual request (with the correct method and 
   complete payload), perform an access check on _that_ document (see 
   below), and if it is again positive, must make the return document 
   available (see below). If either document fails the access check,
   then the user agent must act as if there had been a network-level 
   failure.

   Note: The initial request should be cached to the extent allowed by
   its response headers, so that subsequent non-GET requests can use the
   cached response instead of having to hit the network twice for every
   request.


   Access check: If there are response headers with the name 
   "Access-Control", then they must have their values parsed as the data 
   part of an <?access-control?> PI. 

   If there are no such headers, but the document has an XML MIME type, 
   then the document must be processed according to the Access Control 
   specification.

   In either case, if, according to the processing model in the Access 
   Control specification, the headers (if any) or PIs (if any) indicate 
   that the originating site is allowed to access the document, then the
   access check is positive, otherwise it is negative (failed check).


   Making the document available: if the access check for the document
   is positive, then the various responseXXXX headers must be initialised 
   appropriately. The security context of the document must be the same as 
   that of the originating site. The getAllResponseHeaders() method must
   return the empty string, and the getResponseHeader() method must not 
   return any header values except for the following headers: 
   Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, 
   Pragma. The document.cookie attribute must return the empty string,
   and must do nothing when set.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 10 April 2006 20:03:07 UTC