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

Hi again,

Just want to wake this thread up and say that I still see CORS as a
good fit for this use case, and I'm curious Jonas about what you think
in light of my previous post?

-Michael

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.
>
> On Mon, Jan 31, 2011 at 5:41 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Mon, Jan 31, 2011 at 2:57 PM, Michael Nordman <michaeln at google.com> wrote:
>>> I don't ?fully understand your emphasis on the implied semantics of a
>>> CORS request. You say it *only* means a site can read the response. I
>>> don't see that in the draft spec. Cross-origin XHR may have been the
>>> big motivation behind CORS, but the mechanisms described in the spec
>>> appear agnostic with regard to use cases and the abstract section
>>> seems to invite additional use cases.
>>
>> The spec does say what the meaning of the Access-Contol-Allow-Origin
>> header means. You're trying to modify that meaning.
>
> A strangely existential statement :)
>
>> Consider things from a web authors point of view. The author develops
>> a website, bunnies.com, which contains a HTML page which performs
>> same-site, and thus trusted, XHR requests. The HTML page additionally
>> exposes an API based on postMessage to allow parent frames to
>> communicate with it.
>>
>> Since the site exposes various useful HTTP APIs it further has adds
>> Access-Control-Allow-Origin: <origin>
>> Access-Control-Allow-Credentials: true
>>
>> to a set of the URLs on the site. Including the url of the static HTML
>> page. This is per CORS safe since the HTML page is static there is no
>> information leakage that doesn't happen through a normal
>> server-to-server request anyway.
>>
>> 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.
>>
>> That's why I'm hampering on the semantics.
>>
>> Another issue is that if a site *is* willing to allow resources to be
>> pinned in the app-cache of another site, it might still not be willing
>> to share the contents of those resources with everyone. If we reuse
>> the existing CORS headers to express "is allowed to be app-cache
>> pinned", then we can't satisfy that use case.
>>
>> For example a website could create a HTML page which embeds a
>> user-specific key and exposes a postMessage based API for third party
>> sites to encrypt/decrypt content using that users key. To allow this
>> to happen for off-line apps it wants to allow the HTML page to be
>> pinned in a third party app-cache. But it doesn't want to expose the
>> actual key to the third party sites. If CORS was used to allow
>> cache-pinning, this wouldn't be possible.
>>
>>> I do appreciate the using CORS for this feels like blurring the lines
>>> between two different things. ?I wonder if there should be additional
>>> request/response headers in CORS to convey the intended "use" of the
>>> resource and whether that particular "use" is allowed?
>>>
>>> If not CORS, what mechanism would you suggest to allow HTTPS resources
>>> from another origin to be including in a cache manifest file? Any
>>> means for the 'other' origin to opt in will suite my needs.
>>
>> I don't really care if this is part of CORS spec or not, but it needs
>> to be different headers than Access-Control-Allow-Origin to avoid
>> overloading the meaning of that header, and thus the effect of adding
>> it.
>>
>> The header-value should probably include some sort of limit on how
>> long the resource is allowed to be cached, and maybe there should be
>> ways that the site can signal that a given url should be used as
>> fallback.
>
> I think these two requirements add unnecessary complexity, and in the
> use case that brought me here, "as a fallback" is definitely not
> desired.
>
> Honestly, I'm not so convinced that pinning in an appcache is much
> different than providing "read access". Such cross origin resources
> are available to be loaded as subresources into main pages using that
> particular appcache, only in the context of the manfest file's origin.
> They don't escape beyond that boundary. Looks a lot like a form of
> "read access" extended to the offline case.
>

Received on Friday, 4 February 2011 14:15:44 UTC