Open jub0bs opened 1 year ago
Well, the design of Access-Control-Expose-Headers
did not take Spectre and friends into account. Implementations could maybe do better there, but some headers that are not safe listed need nevertheless be processed, so that might be tricky to completely pull off. (This should probably be tracked in Fetch at some point, though I'm not aware of anyone actively being interested in fixing this.)
cc @arturjanc
I think Chromium is handling this correctly today. It was certainly not handling this correctly when I wrote it a while back (we piped redirects back to the renderer to handle frame-src
and form-action
). I don't know the state of other browsers these days; hopefull we've generally aligned on handling this kind of thing in a privileged process.
Regardless, the example could probably be reformulated to make a different point: handle CORS for the preflight, but don't enable CORS access for the resource itself. That would likely enable origins to use fetch()
to read data they shouldn't, unless you're very careful about evaluating fetch metadata headers and etc. Would you like to take a stab at that @jub0bs ?
@mikewest does Chrome actually remove the Location
header for opaque-redirect filtered responses before passing those to the website process? Or for a normal CORS response that happens to have a Location
header in it that's not safelisted? (I wasn't referring to the normal case of following redirects, which should indeed happen in the network process, but maybe this document is.)
@annevk: You mean something like fetch('...', { redirect: 'manual' })
? I don't think we do. (And I also see more subresource redirect-handling code in our renderer process than I thought we had. So we might not be handling this as high up the stack as I thought after all.)
Yeah, and also just fetch('https://cross-origin.example/')
in general as you might think that secrets in response headers that are not safelisted using Access-Control-Expose-Headers
are safe, but you would be mistaken. (But arguably you shouldn't be mistaken and browsers should make more of an effort.)
FWIW in our original internal Spectre-related remediation we assumed that a response to a known URL with a Location
header redirecting to a user-dependent location (e.g. something with a secret per-user token) could leak, and tried to protect some endpoints with this behavior via CORP and server-side logic using Fetch Metadata headers. However, we haven't been very consistent about this and were hoping that work on OOR-CORS and related changes in browsers would make this less of a concern in the long run.
Thank you all for your input.
@mikewest
Would you like to take a stab at that @jub0bs ?
Sorry for the late reply. Now that I have a better understanding of the issue, I can certainly take a stab at it.
Hey @jub0bs, are you still interested in sending a PR for this?
@letitz Yes! Sorry, I forgot about this. I'll see what I can do this weekend.
No worries, and thanks for contributing :)
Example 3 reads like this:
I'm not sure I understand how the location could leak, even if the ACAO header was present on the response to the actual (preflighted) request... Since
Location
is not a CORS-safelisted response-header name, client code would only be able to read the value of that header if the response listed the header name in question in itsAccess-Control-Expose-Headers
header.Am I missing something?