If it's possible, I would like to add dev@dropbox.com (which suggested that we posted this as a bug) and also avlidienbrunn@gmail.com as we both were involved.

Maxime at Dropbox also sent this:
https://www.w3.org/TR/2015/WD-html51-20150506/browsers.html#security-concerns-with-offline-applications-caches

It seems like the specification of how Application Cache should work actually states the following:

"manifests can only specify fallbacks that are in the same path as the manifest itself. This means that a content injection upload vulnerability in a particular directory on a server can only be escalated to a take-over of that directory and its subdirectories. If there is no way to inject a file into the root directory, the entire site cannot be taken over."

Which is not really how it works today.

Having a manifest.txt, xss.html and load-manifest.html inside a subdirectory (/u/123), where the manifest says:

FALLBACK:
/ /u123/xss.html

will actually set that fallback for the complete origin when visiting /u123/load-manifest.html

mkwst@, are you able to assess this issue?

adding requested ccs

Setting to medium/stable, as the origin checks really do seem problematic.

I would be thrilled to add tons of restrictions to appcache, up to and including removing it from the platform. :)

Reassigning to michaeln@, and CCing Jake, who both know things about our appcache implementation. They should be able to answer the above questions in a more informed way than I.

* manifest can be set even though page has Content-Security-Policy: sandbox

This seems like a bug. Sandboxed pages should have an opaque origin, and shouldn't be able to set an appcache for the origin from which they were delivered. Is this the case for HTML files, or just SVG?

* manifest can be set on origin, even being on a suborigin

I expect this is related to the above: we might not be correctly consulting `SecurityOrigin` for suborigins. CCing jochen@ for the spec issue.

* manifest FALLBACK can fetch resources not allowed by CSP

I don't think this is something CSP can reasonably limit, in the same way that it doesn't limit what ServiceWorkers can do with an outgoing request. The fact that appcache isn't CSP-aware is certainly bad, but it's a deeper problem with appcache, not an issue with CSP per-se.

* an SVG-file can set a manifest (even if mime is image/svg+xml)

This seems strange. Is it expected behavior, Jake/Michael?

* an XML can set manifest (using xmlns=xhtml)

Ditto, but less surprising.

* a file below a path (u/XYZ) can set FALLBACK for the complete origin

Service workers' decisions to the side, path-based restrictions don't have much security impact. I'm not sure that we should pretend that they do. But we're apparently not following the spec's guidance here, so we should either make that an explicit decision, or align with the spec.

Dev asked for me to add maxime.s.serrano@gmail.com to the CC list, as they've been working together on the issue.

michaeln: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

michaeln: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sounds like the change to make is in Blink is to ignore the manifest attribute value when the securityOrigin.HasSuborigin() or when the securityContext.IsSandboxed(). That should prevent creation of new application caches from those contexts.

I'll take a stab at doing that in HTMLHtmlElement::MaybeSetupApplicationCache().

* manifest FALLBACK can fetch resources not allowed by CSP

I think we leave this one alone, multiple pages with different CSPs can refer to the same manifest. Pages can get added after the appcache is established.

* SVG/XML

I'm not sure if its expected or not per the spec, its not really a security issue afaict.

* a file below a path (u/XYZ) can set FALLBACK for the complete origin

The spec got changed sometime after apps using this feature were release. Changing this behavior would absolutely break existing apps.

First some history and then an idea about a mitigation...

Back in 2011, it was decided that the text/cache-manifest mimetype requirement was too onerous and needed to be relaxed, so we did so.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14701
https://bugs.chromium.org/p/chromium/issues/detail?id=103939

Sometime later, we reinstated the mimetype requirement for a powerful non-standard feature.
https://bugs.chromium.org/p/chromium/issues/detail?id=372634


We could require the mimetype for FALLBACKS at "/" or urls not nested down under the manifest's directory.

hey! thanks for the pings. Your mitigation sounds good but I am confused: per https://bugs.chromium.org/p/chromium/issues/detail?id=367812 and https://bugs.chromium.org/p/chromium/issues/detail?id=372634 it looks like it should already be the case that the mimetype is required?

That reinstated the the content-type requirement for a specific case where the manifest was using the non-standard CHROMIUM-INTERCEPT feature, otherwise the content-type is ignored.

I'm suggesting we could require it for "dangerous" FALLBACK usages too.

aah ok. That sounds good to me! 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ee52d446e0aaea1ac7375ab3e7a916230688d4b8

commit ee52d446e0aaea1ac7375ab3e7a916230688d4b8
Author: michaeln <michaeln@chromium.org>
Date: Mon Apr 17 22:21:36 2017

Prevent appcache creation from suborigins and sandboxed pages.

Ignore the manifest attribute value when loading the document.

BUG= 696806 

Review-Url: https://codereview.chromium.org/2813123002
Cr-Commit-Position: refs/heads/master@{#465043}

[modify] https://crrev.com/ee52d446e0aaea1ac7375ab3e7a916230688d4b8/third_party/WebKit/Source/core/dom/DocumentTest.cpp
[modify] https://crrev.com/ee52d446e0aaea1ac7375ab3e7a916230688d4b8/third_party/WebKit/Source/core/loader/appcache/ApplicationCacheHost.cpp
[modify] https://crrev.com/ee52d446e0aaea1ac7375ab3e7a916230688d4b8/third_party/WebKit/Source/core/loader/appcache/ApplicationCacheHost.h

michaeln@ - any more changes expected or can we mark this as fixed?  Thanks!

I think we should leave it open to mitigate the last bullet item too.

There are 6 items listed in the OP. The first two are taken care of, the third is 'not a bug', the next two are not a security matter, but that last one scares people. 

My vote would be to require the C/T for some subset of FALLBACK uses.

Hi,
Great job getting this resolved.
Will this qualify for a bounty?

This will qualify for bounty consideration once it's marked as fixed, looks like there's some remaining work per #26.

Friendly security sheriff ping. :)

michaeln: do we need some more consensus on how to address the last bullet point, more discussion, or is a fix possible and awaiting time / someone to do it?

Security sheriff ping x 2.

michaeln@ and I chatted - the outstanding issue is already tracked as  issue 422987  so we can go ahead and mark this fixed.

Congrats! The VRP Panel decided to award $2,000 for this bug. Thanks!

Thanks a lot!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot