Re: [access-control] Implementation comments

On Sep 14, 2008, at 4:20 AM, Jonas Sicking wrote:

>
> Hi All,
>
> After having implemented (most of) the AC spec I found a couple of  
> comments:
>
> 1.
> Most serious is that the combination of Access-Control, XMLHttpRequest
> Level 2 and ProgressEvents allows an evil site to detect the existence
> of servers sitting behind the same firewall as the user. The evil site
> would run the following JavaScript code:
>
> xhr = new XMLHttpRequest();
> xhr.open("POST", siteToTest, true);
> xhr.setRequestHeader("Content-Type", "text/plain");
> xhr.upload.onprogress = siteFound;
> xhr.send(veryLargeStringOfDummyData);
>
> For this request no preflight should be done according to current AC
> spec. However the event listener for upload progress events will be
> called before any header data is received, i.e. before any
> Access-Control checks can be done. This means that this listener is
> called even if the AC checks fail, allowing the code to detect that
> the site exists.
>
> To fix this I propose that we keep the current behavior stated by the
> spec as a default behavior, but state that a embedding spec is allowed
> to require preflight requests on any request, even if Access-Control
> does not require this, if it would otherwise be possible to detect the
> existence of a server.
>
> We'd then require preflight requests if there are any event listeners
> registered on the XMLHttpRequest.upload object. We'd further have to
> forbid registering such listeners if a preflight-less AC request has
> started.

How about always sending upload progress events for a cross-site  
request, even if the server doesn't exist? Or alternately, send them  
in such a way that you can't tell whether the server cut off the  
connection suddenly or whether it doesn't exist?

However, requiring preflight in this case also seems acceptable.

> 2.
> The way that the preflight result cache is defined gives some sup
> optimal results. For example, say that a site first makes two GET
> requests with two different custom headers are made to a URI. We'd
> have the following traffic for the preflight requests (details removed
> for simplification):
>
> Request 1:
> OPTIONS /foo HTTP 1.1
> Access-Control-Request-Headers: X-Custom-1
>
> Response 1:
> 200 OK
> Access-Control-Allow-Headers: X-Custom-1
> Access-Control-Max-Age: 3600
>
> Request 2:
> OPTIONS /foo HTTP 1.1
> Access-Control-Request-Headers: X-Custom-2
>
> Response 2:
> 200 OK
> Access-Control-Allow-Headers: X-Custom-2
> Access-Control-Max-Age: 3600
>
> If the site then wanted to make a request that included both the
> X-Custom-1 *and* X-Custom-2 headers the spec currently requires a new
> preflight request since there is no entry in the preflight cache with
> both headers set. Rather there are two entries, one with one of the
> headers and one with the other. It seems to me that the text should be
> changed to allow a request to be made without requiring another
> preflight.
>
> Or am I misunderstanding the spec and this is already allowed?

I agree, any header that has been allowed individually before should  
be considered allowed in combination. The spec should make this clear  
if it doesn't already.

>
> 3.
> I think we should look into putting more headers on the white list
> that doesn't require preflights. Specifically the following headers
> seems like they should be safe
>
> Range
> If-Unmodified-Since
> Cache-Control: no-cache
>
> since they can already happen in an HTML implementation that has a
> local cache (which I think is pretty much every implementation that I
> know of).

Do caching HTML implementations normally send Range without If-Range?

In general I would be wary of extending the set of headers allowed  
without preflight. Are there specific common use cases for these?

Regards,
Maciej

Received on Sunday, 14 September 2008 22:39:45 UTC