VULNERABILITY DETAILS
When loading an HTTP worklet (with Access-Control-Allow-Origin: *) from an HTTPS Document, the worklet is NOT blocked due to mixed content check.
VERSION
Chrome Version: M69 or later.
Regression since: r562087 https://chromium-review.googlesource.com/c/chromium/src/+/1026945
Operating System: All (tested on Linux)
REPRODUCTION CASE
(0) Start local WPT server:
./third_party/blink/tools/run_blink_wptserve.py
and add "127.0.0.1 foobarbaz" to /etc/hosts
(1) Enable
chrome://flags/#enable-experimental-web-platform-features
(2) Open an HTTPS webpage, say, https://www.google.com/
(3) Open DevTools and execute:
CSS.layoutWorklet.addModule('http://foobarbaz:8001/worklets/resources/empty-worklet-script-with-cors-header.js').then(() => console.log("BAD")).catch(() => console.log("Good (rejected)"))
Expected:
"Good (rejected)" and a console error about mixed content.
Actual:
"BAD". No Mixed-Content error messages.
Please use labels and text to provide additional information.
The immediate cause for this issue is that WorkletGlobalScope's SecurityOrigin is used for mixed content check.
The WorkletGlobalScope's SecurityOrigin is opaque and thus no mixed-content checks are applied.
The Document's origin is HTTPS, and thus HTTP worklets are expected to be blocked as mixed content.
Using the SecurityOrigin of the parent Document instead of the worklet somehow fix this issue (reverting the effect of the regressing CL (r562087)), but this is not a complete solution.
Probably we have to implement
https://html.spec.whatwg.org/#https-state as specced.
Security team & Blink>SecurityFeature people, do we have to merge a fix for this CL into M69?
Comment 1 by hirosh...@chromium.org
, Sep 3