- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 14 Sep 2008 15:34:38 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: public-webapps@w3.org
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