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

[Michael Nordman]

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.