- From: Michael Nordman <michaeln@google.com>
- Date: Mon, 14 Feb 2011 17:04:32 -0800
Fyi... I'm planning on making a change along these lines to chrome soon... * respect "no-store" headers for cross-origin resources * allow HTTPS cross-origin resources On Tue, Feb 8, 2011 at 3:25 PM, Michael Nordman <michaeln at google.com> wrote: > Hi again, > > Just had an offline discussion about this and I think the answer can > be much simpler than what's been proposed so far. ?All we have to do > for cross-origin HTTPS resources is respect the cache-control no-store > header. > > Let me explain the rationale... first let's back up to the motivation > for the restrictions on HTTPS. They're there to defeat attacks that > involve physical access the the client system, so the attacker cannot > look at the cross-origin HTTS data stored in the appcache on disk. But > the regular disk cache stores HTTPS data provided the cache-control > header doesn't say no-store, so excluding this data from appcaching > does nothing to defeat that attack. > > Maybe the spec changes to make are... > 1) Examine the cache-control header for all cross-origin resources > (not just HTTPS), and only allow them if they don't contain the > "no-store" directive. > 2) Remove the special-case restriction that is currently in place only > for HTTPS cross-origin resources. > > WDYT? > > On Mon, Feb 7, 2011 at 5:27 PM, Michael Nordman <michaeln at google.com> wrote: >> On Mon, Feb 7, 2011 at 4:35 PM, Jonas Sicking <jonas at sicking.cc> wrote: >>> On Mon, Feb 7, 2011 at 3:31 PM, Ian Hickson <ian at hixie.ch> wrote: >>>> On Mon, 7 Feb 2011, Jonas Sicking wrote: >>>>> On Mon, Jan 31, 2011 at 6:27 PM, Michael Nordman <michaeln at google.com> wrote: >>>>> > But... the risk you outline is not possible... >>>>> > >>>>> >> However, with the modification you are proposing, an attacker site >>>>> >> could forever pin this page the users app-cache. This means that if >>>>> >> there is a security bug in the page, the attacker site could exploit >>>>> >> that security problem forever since any javascript in the page will >>>>> >> continue to run in the security context of bunnies.com. So all of a >>>>> >> sudden the CORS headers that the site added has now had a severe >>>>> >> security impact. >>>>> > >>>>> > The bunnies.com page stored in the attacker's appcache will never be >>>>> > loaded into the context of bunnies.com. There are provisions in the >>>>> > the appcache system to prevent that. Those provisions guard against a >>>>> > this type of attack via HTTP. >>>>> >>>>> Your proposal means that we forever lock that constraint on the >>>>> appcache. That is not currently the case. I.e. we'll never be able to >>>>> say "open an iframe using the resource which is available in my >>>>> appcache" or "open this cross-site worker using the resource available >>>>> in my appcache". >>>>> >>>>> Or at least we won't ever be able to do that for cross-site resources. >>>> >>>> That's intentional. We don't want it to be possible to get a cache of a >>>> third-party page vulnerable to some sort of XSS attack and then to be able >>>> to load that page with the credentials of its origin, since it would make >>>> it possible for hostile sites to lock in a vulnerability and keep using >>>> it even after the site had fixed the problem. >>> >>> It seems desirable that the third party site could opt in to allowing >>> this. Especially if it can choose which sites should be able to cache >>> it. Which I think is the feature request that Michael starts with in >>> this thread. >>> >>> / Jonas >>> >> >> My feature request is for an opt-in mechanism to facilitate >> cross-origin HTTPS resources. I'm not looking for an opt-in mechanism >> to allow execution of cached cross-origin resources at this time. Anne >> mentioned that CORS might be an option for my feature request... and >> here we are. >> >
Received on Monday, 14 February 2011 17:04:32 UTC