[whatwg] AppCache feature request: An https manifest should be able to list resources from other https origins.

[Michael Nordman]

Fyi: This change has been made in chrome.
* respect "no-store" headers for cross-origin resources (only for HTTPS)
* allow HTTPS cross-origin resources to be listed in manifest hosted on
HTTPS

On Mon, Feb 14, 2011 at 5:04 PM, Michael Nordman <michaeln at google.com>wrote:

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