Re: [whatwg/fetch] COEP:credentialless and the HTTP cache. (#1253)

If I understand the discussion correctly, this is a bit of a rehash of #307, but specific to COEP: credentialless. Maybe there is a solution to this particular issue that does not solve #307, however.

In this issue, the problematic scenario is the following:

1. https://evil.com/not-coi fetches https://bank.com/sensitive.json in a non-cross-origin-isolated context, with credentials
2. https://bank.com responds with some sensitive data, forgets to set a `Vary: Cookie` header
3. the browser caches the response
4. https://evil.com/coi fetches the same resource in a cross-origin-isolated credentialless context
5. the cache entry is used, which means `COEP: credentialless` is bypassed
6. evil.com can perform a high-banddwidth spectre attack and leak the sensitive data

Now, if I understand @sleevi's point correctly, the issue with the proposed fix (aligning spec and chromium with gecko) is that it fails to address other caches' handling the same request.

Suppose the user loads b.com through a proxy (be it a CDN or a local MITM). Then instead of step 3 we have:

3a. the proxy caches the response
3b. the browser caches the response with `includeCredentials: true`

And instead of step 5. we have:

5a. the browser cache entry is not used, as the `includeCredentials` bit on the request is `false`
5b. the proxy cannot tell that credentials are not included and should matter, responds with the cached entry

Resulting in the same security issue.

Finally, the concern is that we would fix this issue with a Fetch spec change, then announce "mission accomplished" and forget to find a solution to the proxy problem.

Is my understanding correct?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1253#issuecomment-1380471351
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1253/1380471351@github.com>