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

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

From: Darin Fisher <darin@meer.net>
Date: Mon, 10 Apr 2006 20:38:04 -0700
Message-ID: <443B249C.7060508@meer.net>
To: public-webapi@w3.org

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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC