1451003 - Cache-Control header is ignored in Cache API

Status: RESOLVED INVALID

(Core :: Storage: Cache API, defect, P2)

Description

[Jun (Request needinfo for comment, I ignore other updates)]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

1. Go to https://test.shhnjk.com/cookie_secret.php
2. Go to https://attack.shhnjk.com/nocache.html and reload (just to make sure that Cache is added).
3. Go to https://test.shhnjk.com/delete_cookie.php
4. Finally, go to https://attack.shhnjk.com/nocache.html again.


Actual results:

Alert appears in step 4.


Expected results:

https://test.shhnjk.com/cookie_secret.php respond with following header.
"Cache-Control: no-cache, private, no-store, must-revalidate"

This indicates that clients should never cache the response. But response can be still cache using Cache API.

On the other hand, responding with "Vary: *" would correctly disallow caching with Cache API. This is most probably because Cache API spec explicitly mentions about Vary header in step 5 of put function (https://w3c.github.io/ServiceWorker/#dom-cache-put).

That's said, document such as MDN (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary#Directives) suggests to use Cache-Control, so this should be fixed.

Comment 1

[Jun (Request needinfo for comment, I ignore other updates)]

This example shows an example of caching cross-origin resource with script but same can be done with Fetch API, CSS resources, media resources, etc.

I'm guessing that this bug is similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1408194.

Comment 2

[Daniel Veditz [:dveditz]]

Jason: who owns cache-control stuff?

Comment 3

[Jason Duell]

bkelly:  My guess here is that necko HTTP caching is working fine, but the Cache API needs to learn to pay attention to Cache-Control?  Does that sound right?

Comment 4

[Jason Duell]

ni'd :overholt too in case bkelly does't have cycles

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

Cache API is like IDB.  If a site loads a fetch() or xhr that happens to be marked no-store we can't really prevent them from storing it somewhere.  For example, a site could read the body and store a new synthetic response without the header to easily bypass any restriction we try to enforce here.  Or it could put in local storage, etc.

The one exception to this is possibly for opaque no-store.  In that case the body is not available.  The chrome folks filed a spec issue for this:

https://github.com/w3c/ServiceWorker/issues/1299

For now, though, this is working as intended.

Comment 6

[Jun (Request needinfo for comment, I ignore other updates)]

https://www.mozilla.org/en-US/security/advisories/mfsa2018-06/#﷒0﷓
"This can result in previously stored, locally cached data of a website being accessible to users if they share a common profile while browsing."

If this is a threat Firefox cares about, then this bug can do the same. None of Google, Twitter, etc uses `Vary` header. Instead, they uses `Cache-Control` header. Attacker page can cache Google or Twitter page. And later see those caches through devtool or another doing same request from same page.

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Jun from comment #6)
> https://www.mozilla.org/en-US/security/advisories/mfsa2018-06/#﷒0﷓
> "This can result in previously stored, locally cached data of a website
> being accessible to users if they share a common profile while browsing."
> 
> If this is a threat Firefox cares about, then this bug can do the same. None
> of Google, Twitter, etc uses `Vary` header. Instead, they uses
> `Cache-Control` header. Attacker page can cache Google or Twitter page. And
> later see those caches through devtool or another doing same request from
> same page.

That advisory was about an http cache issue where a no-store response could be leaked even after a site wiped all of its DOM storage.  So if the user logs out of their banking site, an old version of their credentialed no-store page could still be pulled from http cache using a particular method.  Ideally we wouldn't cache no-store pages at all in http cache, but we do keep them to support things like view-source and devtools inspection, etc.

Comment 8

[Jun (Request needinfo for comment, I ignore other updates)]

(In reply to Ben Kelly [Part-time, not reviewing][:bkelly] from comment #7)
> (In reply to Jun from comment #6)
> > https://www.mozilla.org/en-US/security/advisories/mfsa2018-06/#﷒0﷓
> > "This can result in previously stored, locally cached data of a website
> > being accessible to users if they share a common profile while browsing."
> > 
> > If this is a threat Firefox cares about, then this bug can do the same. None
> > of Google, Twitter, etc uses `Vary` header. Instead, they uses
> > `Cache-Control` header. Attacker page can cache Google or Twitter page. And
> > later see those caches through devtool or another doing same request from
> > same page.
> 
> That advisory was about an http cache issue where a no-store response could
> be leaked even after a site wiped all of its DOM storage.  So if the user
> logs out of their banking site, an old version of their credentialed
> no-store page could still be pulled from http cache using a particular
> method.  Ideally we wouldn't cache no-store pages at all in http cache, but
> we do keep them to support things like view-source and devtools inspection,
> etc.

Maybe my question wasn't clear. Is following threat model of Firefox? If so, This bug can be used to accomplish the same goal.
`locally cached data of a website being accessible to users if they share a common profile while browsing`


Repro
1. Sign in to Google or Twitter
2. Go to https://attack.shhnjk.com/cacheme.html
3. logout from Google or Twitter
4. Go to https://attack.shhnjk.com/cacheme.html again and it still has your authenticated response (which you can read response from devtool).

Since this is cached in attackers cache storage, Google or Twitter wiping their DOM storage would not help removing cache.

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

I can't really state what is or is not a valid threat model for consideration by firefox.  I think that's more in Daniel and Al's bailiwick.

The advisory in comment 6 was in regards to an http cache bug that was exposing browser internal information.  To support some features, firefox actually hangs on to some no-store data at the http cache level.  That should never be exposed to content script, though.  So it was really fixing a spec issue that has some security implications, particularly in settings where multiple users might end up using the same machine with the same http cache.  That issue was marked sec-low, I believe.

I do tend to agree with Eric here, though:

https://bugs.chromium.org/p/chromium/issues/detail?id=828420#c8

Multiple users in the same profile is generally not going to be difficult to secure.  I don't think that means we should have left our http cache bug unfixed, though.

In regards to the demo in comment 8, I believe that is covered by the spec issue raised by google in response to your issue against chrome:

https://github.com/w3c/ServiceWorker/issues/1299

But perhaps the proposed From-Origin header would be a better approach?

https://github.com/whatwg/fetch/issues/687

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

> Multiple users in the same profile is generally not going to be difficult to secure.

This should read "is generally going to be difficult to secure".

Comment 11

[Jun (Request needinfo for comment, I ignore other updates)]

Yeah, I agree with Eric too. This is why I filed a bug to both to see what the threat model is for Chrome and Firefox.

Comment 12

[Honza Bambas (:mayhemer)]

This seems to me (at least partially) as a re-iteration of the no-store caching problem we already track in bug 1318234.

Hence, if there is anything the networking/cache layer has to do, then it's already tracked there.

If there is anything any of the DOM APIs have to do, it has to be tracked in DOM.  Hence, moving this bug to DOM.

Comment 13

[Jens Stutte [:jstutte]]

(In reply to Ben Kelly [:bkelly, not reviewing] from comment #9)

In regards to the demo in comment 8, I believe that is covered by the spec
issue raised by google in response to your issue against chrome:

https://github.com/w3c/ServiceWorker/issues/1299

But perhaps the proposed From-Origin header would be a better approach?

https://github.com/whatwg/fetch/issues/687

Do we have a clearer picture on this today?

Comment 14

[Anne (:annevk)]

From-Origin is now Cross-Origin-Resource-Policy and will ship in Fx 74. Recommending sites to use Cross-Origin-Resource-Policy: same-origin on their resources seems like the correct approach. Selectively honoring certain cache-related headers in certain scenarios is not something that's going to work reliably long term, unless test coverage is real good and nobody forgets about it when there's new cache-related headers.

I also agree with the analysis in https://bugs.chromium.org/p/chromium/issues/detail?id=828420 that this is not a security issue. If you allow your resource to be loaded across origins it can be attacked, period. Caching or no caching doesn't meaningfully change that.