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

[Michael Nordman]

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