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

[Michael Nordman]

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