W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [cors] Set-Cookie / Referer / NTML / cache

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 11 May 2010 15:12:30 -0700
Message-ID: <AANLkTin8WjdP-ef0qDOcAsvUTUv1jaP76b-HNtAmmMut@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Tyler Close <tyler.close@gmail.com>, Maciej Stachowiak <mjs@apple.com>, "Mark S. Miller" <erights@google.com>, WebApps WG <public-webapps@w3.org>
On Thu, May 6, 2010 at 7:52 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Fri, 09 Apr 2010 09:51:16 +0900, Maciej Stachowiak <mjs@apple.com> wrote:
>>
>> On Apr 8, 2010, at 5:20 PM, Tyler Close wrote:
>>>
>>> This unique origin would still need to discard Set-Cookie response
>>> headers to prevent the accumulation of credentials associated with the
>>> unique origin. It would also need to prohibit the reuse of a TLS
>>> client authenticated connection or NTLM authenticated connection. It
>>> would also need to prevent use of cache entries populated by
>>> non-uniform requests. The CORS draft is also unclear on what happens
>>> with the Referer header.
>>
>> Good point. It seems like these should all be raised as issues on CORS. I
>> will do it if you don't beat me.
>
> I think some of this was already addressed, but I have recently done some
> more work on this as it seemed you both were too busy to file issues. I
> renamed "credentials" to "user credentials" to make it more clear what it
> was referring to:
>
>  http://dev.w3.org/2006/waf/access-control/#user-credentials
>
> I added a requirement to not set cookies if the "credentials flag" is set,
> but I think in the end this would be better dealt with by passing a flag to
> the "fetch" algorithm defined in HTML5. The same goes for the Referer
> header. To that extent I have filed two bugs on HTML5:
>
>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=9603
>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=9604
>
> I expect Ian to address these to our satisfaction or provide an alternative
> solution that does.
>
>
> The comment about cache entries was not entirely clear to me. What is the
> problem with HTTP cache? Is the preflight result cache a problem?
>
> If there is anything I missed that would be good to know too.

The problem with cache is as follows:

1. User navigates to Page A which includes an <iframe> with
src="http://foo.com/bar.cgi"
2. The browser requests "http://foo.com/bar.cgi" and sends along the
users cookies for the "foo.com" domain.
3. The foo.com server responds with a resource. The response includes
an "access-control-allow-origin: *" header.
4. The browser the resource in the internal HTTP cache for url
"http://foo.com/bar.cgi"
5. Page A then makes a CORS request to "http://foo.com/bar.cgi",
leaving the .withCredentials flag as false.
6. The browser HTTP code sees the resource in the cache and returns it.
7. The CORS implementation receives a resource which includes
"access-control-allow-origin: *" and returns it to the page.

So here the page receives a resource that was fetched using a request
that included cookies. However the site has only authorized
cookie-less requests.

The solution is to use separate HTTP caches for cookie-enabled and
cookie-less requests (or to include the 'cookies enabled' flag as part
of the key to the cache).

The mozilla implementation similarly never reuses HTTP keep-alive
connections between cookie-enabled and cookie-less requests. Nor
shares ssh connections for https requests between cookie-enabled and
cookie-less requests.

/ Jonas

/ Jonas
Received on Tuesday, 11 May 2010 22:13:24 GMT

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