- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 11 May 2010 15:12:30 -0700
- 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 UTC