OOR-CORS should be enabled for most extension content scripts |
||||
Issue descriptionSince r620935 (73.0.3666.0) CORB started to be enforced also for extension content scripts (except for a relatively short allowlist of extensions that depend on the baked-in/grandfathered-in legacy behavior). One strange and somewhat surprising effect of this change is that XHRs/fetches made from content scripts are 1) *not* subject to CORS, but 2) are blocked by CORB. We should consider fixing the above, by leveraging OOR-CORS to enable CORS for most extension content scripts (except the ones on the CORB allowlist). Some notes: - Enabling CORS is more risky than enabling CORB, because CORB only covers html/xml/json and CORS covers all content types. - OOR-CORS would still need to suppress CORS if 1) extension permissions ask for it, (AFAIK this is communicated via network::mojom::NetworkContext::SetCorsOriginAccessListsForOrigin) 2a) the request is made from an extension on the CORB allowlist 2b) the request comes from an extension frame (not from a content script) (maybe 2a+2b can be determined based on URLLoaderFactoryParams::is_corb_enabled which URLLoaderFactoryManager sets to true when CORB [and CORS] should be enforced) PS. Note that CORB is somewhat orthogonal to CORS: - CORB applies to no-cors requests (like <img> and <script> request) and CORS doesn't. CORB will continue to be a useful defense here, even once OOR-CORS ships. - OOR-CORS will make CORB obsolete for CORS requests (until that happens CORB is a meaningful defense against Spectre) assumming that OOR-CORS can use a trustworthy request_initiator (issue 920634). PPS. This bug has been found/motivated by the discussion here: https://twitter.com/frgx/status/1083215549654392832
,
Jan 10
I feel responsible for this bug - this is something I overlooked/missed when working on issue 846346. Therefore - let me assign this bug to myself. OTOH, I might not have time to work on this bug until M74 or M75, so feel free to take over this bug.
,
Jan 10
Also - for repro steps one can try launching Chrome with --force-empty-corb-allowlist --enable-features=NetworkService cmdline flags and trying to use one of the extensions from the allowlist (see Google-internal doc [we're trying to avoid unnecessarily disclosing identities of extensions on the allowlist] here: https://docs.google.com/document/d/1ReuTBgn6HDIO0QKsjzBZz2Bz9F9_sEW4X-rz6IogURo).
,
Jan 10
nasko@ points out that this might be something that we should hold off with until manifests v3. I don't have a strong opinion - I can be convinced either way I think.
,
Jan 15
,
Jan 15
,
Jan 16
Lack of CORS can actually break some fetches. Let's consider a fetch from https://www.grubhub.com to https://api-gtm.grubhub.com/: 1. When such fetch is initiated from a webpage, it is subject to CORS and 1.1. the outgoing request contains the Origin header and 1.2. the server replies with "access-control-allow-origin: https://www.grubhub.com". 2. When such fetch is initiated from a content script, it bypasses CORS and 2.1. the outgoing request doesn't have the Origin header and 2.2. consequently the server doesn't respond with access-control-allow-origin 2.3. because of 2.2 corb blocks the response
,
Jan 16
Another interesting twist in #c7 is that the website obviously sends out the fetch request with "Origin: https://www.grubhub.com" header, but it is unclear what the extension content script's behavior should be (currently request_initiator would be chrome-extension://...). The website might reasonably reject requests with "Origin: chrome-extension://..." header...
,
Jan 16
(6 days ago)
We should not be sending headers containing chrome-extension://... on the wire, which allows servers to arbitrarily respond differently to each extension. Since extensions are supposed to be part of the browser itself, it shouldn't be visible on the wire that a request is made by an extension (whether the extension itself or a content script belonging to it). |
||||
►
Sign in to add a comment |
||||
Comment 1 by lukasza@chromium.org
, Jan 10