Issue metadata
Sign in to add a comment
|
Security: SRI integrity check performed on fetch()ed non-CORS cross-origin resources
Reported by
tomvango...@gmail.com,
Apr 4 2018
|
||||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS An integrity check (following the SRI standard) is performed on resources that are not same-origin or that were not given explicit access through CORS. This allows an adversary to brute-force the content of opaque resources. See the SRI spec for more details: https://w3c.github.io/webappsec-subresource-integrity/#is-response-eligible and https://w3c.github.io/webappsec-subresource-integrity/#cross-origin-data-leakage VERSION Chrome Version: Tested on Version 65.0.3325.181 (Official Build) (64-bit) - stable Operating System: Tested on macOS 10.13.3. REPRODUCTION CASE PoC file: https://poc.tom.vg/sri/test.html (see attached) This returns: Correctly identified logged-in page. Correctly identified page as not being logged-in page. It should contain: ERR: could not identify logged-in page. --- Note: on <script> elements with an integrity attribute, the check is not performed.
,
Apr 4 2018
Are you able to reproduce this issue in Chrome Canary? (Similar to Issue 812667 ).
,
Apr 4 2018
In Chrome Canary (Version 67.0.3388.0) the integrity check is indeed not performed. From console: "Subresource Integrity: The resource 'https://labs.vagosec.org/sri/logged-in.html' has an integrity attribute, but the response is not eligible for integrity validation."
,
Apr 4 2018
Tested on the latest HEAD. here is the print out I got. ERR: could not identify logged-in page. Correctly identified page as not being logged-in page. Version 67.0.3389.0 (Developer Build) (64-bit) on Linux.
,
Apr 4 2018
Hey Tom! I agree with Eric that this looks like a dupe of Issue 812667 , which I believe we merged back to M66. Do you still see issues with the behavior in Beta+?
,
Apr 5 2018
,
Apr 5 2018
The issue is still present in Version 66.0.3359.81 "Blocking Cross-Site Documents for Site Isolation" might mess a bit with the reported results -- on Windows the logged results seemed OK at first, but that was just because the integrity check was done on empty string. Best to look at console output as well when checking.
,
Apr 5 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 6 2018
yhirano: It looks like c7bfc96d2c218e8b1592d379da1fe256767cdf27 was merged to the wrong branch. M66 is 3359 but it was merged to 3355.
,
Apr 6 2018
Wow. Sorry about that. I'll reopen the original bug.
,
Apr 6 2018
,
Aug 18
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by jialiul@chromium.org
, Apr 4 2018Labels: OS-Mac