W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

[access-control] Implementation comments

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 14 Sep 2008 13:20:00 +0200
Message-ID: <63df84f0809140420rdd78790iaac1cca28168813f@mail.gmail.com>
To: public-webapps@w3.org

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.


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?


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

/ Jonas
Received on Sunday, 14 September 2008 11:20:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT