Local HTML files can load cross-origin resources without being blocked by CORB
Reported by
luan.her...@hotmail.com,
Aug 11
|
|||||||
Issue descriptionVULNERABILITY DETAILS Reading https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md I didn't see any mention of how CORB would behave if a local HTML file tried to load a cross-origin resource and decided to test to see what would happen. It seems a local HTML file is able to load cross-origin resources without being blocked by CORB (SiteIsolation.XSD.Browser.Action: "Allowed without sniffing" increases after opening the PoC and no warning is shown in the console). VERSION Version 70.0.3514.0 (Official Build) dev (64-bit) REPRODUCTION CASE corb.html: Loads https://google.com inside a script tag.
,
Aug 13
This is definitely known and WAI *at the moment* - there is an explicit check in CrossOriginReadBlocking::ResponseAnalyzer::ShouldBlockBasedOnHeaders: // Allow requests from file:// URLs for now. // TODO(creis): Limit this to when the allow_universal_access_from_file_urls // preference is set. See https://crbug.com/789781 . if (initiator.scheme() == url::kFileScheme) return kAllow; OTOH, I don't think this is WAI for *the long-term* - we should probably try to get rid of this exception, because: - CORS *is* indeed enforced for file://-initiated cross-origin requests. Therefore CORB defense in-depth shouldn't impact the web(file?)-visible behavior. - The security boundary here is a bit blurry, but I guess one could imagine an attacker-controlled origin getting access to a victim origin by social-engineering a user into saving attacker-controller files and opening them from a file:// scheme. (given the social-engineering aspect, I'd say that this is a "medium" severity according to https://www.chromium.org/developers/severity-guidelines?) FWIW, I think there is no previous bug explicitly tracking this work. I put together https://crrev.com/c/1172935 to see if any tests fail if we just yank out the exception.
,
Aug 13
Thanks lukasza@! Given it is WAI for now, I'm removing all the security labels. We should probably treat it as a functional bug or feature.
,
Aug 13
FWIW, there are only 2 failing tests after the WIP https://crrev.com/c/1172935: http/tests/devtools/search/sources-search-scope-many-projects.js http/tests/devtools/search/sources-search-scope-in-files.js In both cases, the blocked resource is: http://127.0.0.1:8000/devtools/search/resources/search.html (fetched [RESOURCE_TYPE_XHR] from a file: origin) Can somebody familiar with DevTools help us understand why the request is not subject to CORS in the test? Do we need to make a special CORB carve-out for DevTools requests? Or is the observed behavior an artifact of how the test is set up?
,
Aug 31
pfeldman@ - could you please help us understand the behavior of the DevTools test pointed out in #c4 above?
,
Sep 19
@lukasza: not sure what you are asking - these resources are fetched using XHR, what's going on there?
,
Dec 3
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by jialiul@chromium.org
, Aug 12