COEP and redirects

[annevk]

I don't think we specifically discussed (opaque) redirects. They are same origin, but opaque to not leak any "HTTP only" secrets as per https://fetch.spec.whatwg.org/#atomic-http-redirect-handling.

How should this work with the cache API and such? Ideally they would continue to work and any secrets never make it to a process where they could be obtained, but that was also a viable strategy for opaque responses that was deemed too complicated.

Given that they are same origin CORP is also not a great header for them.

cc @whatwg/cross-origin-isolation @wanderview @perryjiang @asutherland @yutakahirano

[yutakahirano]

In Chromium every single redirect is reported to the renderer process.

If we want to stop telling non-final redirect locations to renderer process, that would be difficult to implement.

[annevk]

We do require document-level redirects to have COOP+COEP set. So the main problem would be some redirect from a non-COOP+COEP environment being smuggled in through the cache API.

[yutakahirano]

I'm not sure I understand. Are you talking about the following scenario?

1. Fetch an opaque response response at a non cross origin isolated environment A.
2. Persist response to the storage via the cache API
3. Load response from the storage into a cross origin isolated environment B.
4. Extract some "HTTP only" secrets from response at B.

[annevk]

Yes. And in general it appears problematic that if you have top-level A and it frames B which redirects to C, A can attack B's "HTTP only" secret as long as A and B are same-origin.

[yutakahirano]

Do you think it's problematic even when A, B and C are all same-origin?

[annevk]

Maybe? Hard to say in the abstract. We definitely don't reveal B's redirect location (or any other information about it) today.

[yutakahirano]

Chatted with @annevk at IRC. I think I now understand @annevk's concern so let me summarize it.

The problem is not specific to cross-origin, not specific to navigation and not specific to "manual" redirect mode.

Let's think about the following fetch operation which is initiated on a COEP enabled environment and experiences redirects.

const res = fetch(url, {mode: 'same-origin', redirect: 'follow'});

The redirect information, redirection location for example, is not exposed to scripts. But malicious scripts can sniff the information using SAB and similar powerful APIs that are only allowed in COEP enabled environments.

[yutakahirano]

I'm not sure how severe this kind of information leak would be, but I know that fixing this would be very difficult in Chromium, as I said at #5223 (comment).

[mikewest]

It's not clear to me what would need to change in any spec for Chromium to prevent redirect information from entering a given renderer process. The fact that we don't do so today is historically grounded, but not an essential feature of our implementation. I agree that it would be a ton of work to move various checks from the renderer to the browser process, and that the risk might not justify that effort (especially since it would be a trade-off against implementation of things like COEP/COOP, which seem more clearly necessary and less nice-to-have).

It does remain a hole in Chromium's defense against side-channel attacks, and it seems like something Chromium ought to consider a bug. But it also seems pretty clearly to be allowed by the wording of both Fetch and COEP. Does something about either need to change?

[annevk]

So I think the main thing here is that we added special semantics to cache.match() for COEP/CORP to simplify the implementation, but did not do anything for redirects. Meaning the solution to hide redirect secrets would end up being so involved it would never be done. (It was already considered too complex for the more general problem of opaque responses.)

Could we require the CORP header for redirects you want to store in the cache? Is that too much of a hack?

[annevk]

cc @wanderview @jakearchibald @asutherland