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

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, 7 February 2011 17:27:08 UTC