OOR-CORS shouldn't trust the renderer (e.g. for request_initiator) |
|||||||||
Issue descriptionI assume (?) that today OOR-CORS trusts some of the information provided by the renderer process via network::ResourceRequest struct. We should ensure that this trust is either not necessary or the information is cross-verified against trustworthy data coming from the browser process. For example, network::ResourceRequest::request_initiator should be compared against network::mojom::URLLoaderFactoryParams::request_initiator_site_lock using network::VerifyRequestInitiatorLock helper function. Note that there are some complexities and risks here: - HTML Imports may result in request_initiator_site_lock incompatibility (see https://crbug.com/871827#c9) - request_initiator surprisingly differs from Origin header in a significant portion of requests - see NetworkService.URLLoaderFactory.OriginHeaderSameAsRequestOrigin UMA
,
Jan 10
,
Jan 10
With manifest v3, content scripts should behave exactly like other scripts on the page when it comes to cross-origin requests. As such, it seems to me that it is desirable for the request_initiator for content scripts of manifest v3 extension to be not to be the extension origin, but rather the origin of the document the script runs in. This way content scripts do indeed behave just like any other script on the page, which IIRC is the goal of v3.
,
Jan 10
+rdevlin.cronin@ for the discussion of request_initiator VS content scripts in #c3
,
Jan 10
Re #3 that sounds reasonable to me (and yes, one goal for MV3 is to de-magic-ify some of the content script behavior). It may be interesting to still be able to differentiate between a content script request and a page request for e.g. metrics or devtools purposes, but not security decisions.
,
Jan 11
,
Jan 15
,
Jan 15
,
Jan 17
(5 days ago)
initiator lockdown sounds an ideal improvement for URLLoader(Factory) and ResourceRequest. cc: nhiroki, just in case. Worker script loading may do something tricky among two contexts, the host frame and created worker.
,
Jan 18
(5 days ago)
+Karan brought up a good point, which is that it would potentially be nice to still allow content scripts to XHR their own origin (i.e., pages belonging to the corresponding extension). I'm not fully sold on this, since it a) it would require allowing the renderer process to fetch resources from any extension that injected a script and b) extensions can always fall back to messaging, but I'm curious for thoughts and estimates on how much work/complexity this would add. What do y'all think?
,
Jan 18
(5 days ago)
Also worth noting that if a renderer is compromised, it could theoretically just send any extension message it wanted, but at least that gives the opportunity for well-structured message handlers (vs being able to request any extension resource).
,
Jan 18
(4 days ago)
It would be interesting to see how often are extensions using the ability to xhr/fetch their own origin from content scripts. If we decide to do away with it, extensions will do one of the two things: - Make these web accessible resources. (Not ideal, these resources are then visible to every other origin). - Use extension messaging to get these from the background context. (Bit more inefficient, and extensions will need to have a background context). |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by lukasza@chromium.org
, Jan 10