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

Nice proposal.  Some comments below:

> 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.
>   


But, it can set "Cookie" and "Authorization" headers?  That
should be okay.


>    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.
>   


I assume that IP address literals are also supported (w/ "[]"
escaping for IPv6 address literals).


>    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. 
>   

Are there any cases where the allowed contents of the PI would
not be allowed as a HTTP header value?


>    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).
>   

Can you clarify what happens when an "Access-Control" header
does not agree with an <?access-control?> PI?  Or, suppose
there are multiple "Access-Control" headers.


>
>    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.
>   

It seems like it should be okay for getAllResponseHeaders() to
return the subset of response headers that getResponseHeader()
may see.

-Darin

Received on Tuesday, 11 April 2006 03:38:34 UTC