Mark OOR-CORS as safe against compromised renderers.
At this points, OOR-CORS is working with trustworthy inputs:
- network::ResourceRequest::request_initiator is validated against
network::mojom::URLLoaderFactoryParams::request_initiator_origin_lock
in network::CorsURLLoaderFactory::IsValidRequest. See also the CL
description of https://crrev.com/c/2917236 and
https://crrev.com/c/2925752.
- network::ResourceRequest::isolated_world_origin is ignored unless
network::mojom::URLLoaderFactoryParams::ignore_isolated_world_origin
is set to false (the default is a secure true). Such factories are
only vended out to renderer processes hosting the contents of a
<webview> tag, when a Chrome Platform App injects content scripts -
see DoContentScriptsDependOnRelaxedCorbOrCors,
ShouldInspectIsolatedWorldOrigin, and OverrideFactoryParams functions
in //extensions/browser/url_loader_factory_manager.cc
(Note that in the long-term, once Chrome Platform Apps are removed, we
want to remove the network::ResourceRequest::isolated_world_origin
field. This is tracked in https://crbug.com/1098410.)
Fixed: 920634
Change-Id: Id58b446cd39df9c9494f8ccb8f7a74ab16b29121
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2984232
Reviewed-by: Nate Chapin <[email protected]>
Reviewed-by: Yutaka Hirano <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: Karan Bhatia <[email protected]>
Reviewed-by: Charlie Reis <[email protected]>
Commit-Queue: Łukasz Anforowicz <[email protected]>
Cr-Commit-Position: refs/heads/master@{#896702}
diff --git a/docs/security/compromised-renderers.md b/docs/security/compromised-renderers.md
index 358a56c..b7e56be 100644
--- a/docs/security/compromised-renderers.md
+++ b/docs/security/compromised-renderers.md
@@ -281,7 +281,7 @@
## HTTP request headers
Compromised renderers shouldn’t be able to control security sensitive HTTP
-request headers like `Host` or `Sec-Fetch-Site`.
+request headers like `Host`, `Origin`, or `Sec-Fetch-Site`.
Protection techniques:
- Using `AreRequestHeadersSafe` to reject `Host` and other headers that
@@ -290,13 +290,6 @@
by comparing against `request_initiator_origin_lock` in
`network::CorsURLLoaderFactory::IsValidRequest`.
-**Known gaps in protection**:
-- `Origin` header. Tracked by
- https://crbug.com/1098410 (removing
- `network::ResourceRequest::isolated_world_origin` which is used
- in some security decisions instead of `request_initiator` to support
- an allowlist of extensions that need to bypass CORB/CORS).
-
## (WIP) SameSite cookies
