Mixed-content blocker should block <img crossorigin=> requests
Categories
(Core :: DOM: Security, defect)
Tracking
()
Webcompat Priority | P3 |
People
(Reporter: kmckinley, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: privacy, Whiteboard: [domsecurity-backlog1])
Attachments
(1 file)
191 bytes,
text/plain
|
Details |
Even though images are optionally-blockable content in the mixed-content blocking standard[1], images with crossorigin set are considered blockable content[1][2]. Firefox allows them to be loaded. Images are correctly blocked as mixed-content in Chrome. [1] https://w3c.github.io/webappsec-mixed-content/#category-optionally-blockable https://w3c.github.io/webappsec-mixed-content/#should-block-fetch
Reporter | ||
Comment 1•7 years ago
|
||
It appears that we fetch the image, but do not display it. See https://mixed-content-tests-mozilla.org/tvyas/crossorigin.html
Updated•7 years ago
|
Comment 2•7 years ago
|
||
When running the example from comment 1, I observe the following behavior: > Loading mixed (insecure) display content “http://mixed-content-tests-mozilla.org/tvyas/redminus1.jpg” on a secure page[Learn More] crossorigin.html > Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://mixed-content-tests-mozilla.org/tvyas/redminus1.jpg. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). What happens is that our CORS implementation blocks the load in this case, but in fact mixed content blocker should already block the load. So we shouldn't even see the "Loading mixed (insecure) display content..." message.
Updated•7 years ago
|
Reporter | ||
Updated•6 years ago
|
Comment 3•5 years ago
|
||
Resetting priority and other flags so it shows up in our next triage meeting - we should re-evaluate that bug.
Comment 4•5 years ago
|
||
So it seems that Chrome is also not blocking the image request of [1] itself (which it should according to the spec) but then Firefox as well as Chrome enforce the missing CORS headers and the CORS code blocks the load.
We should update our mixed content blocker implementation to account for 'crossorigin' and actually block the image request there.
Anyway, now that we understand the exact problem we can put it back in the backlog because it doesn't seem to be that critical as of now.
[1] https://mixed-content-tests-mozilla.org/tvyas/crossorigin.html
Comment 5•5 years ago
|
||
A user just reported on webcompat.com a site where this is causing Fennec/Fenix to show the page as insecure, while Chrome mobile does not (details at https://webcompat.com/issues/42674 )
Updated•3 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 6•6 months ago
|
||
This needs a re-triage.
- mixed2 auto-upgrading should upgrade, this bug still assumes blocking or a degraded UI
- but should it also upgrade with "crossorigin" set?
- if so.... do we?
Comment 7•6 months ago
|
||
I found earlier (January 2023) discussions about this within the Mixed Content spec.
Marking this WONTFIX and quoting https://bugzilla.mozilla.org/show_bug.cgi?id=1806114#c2:
In analyzing existing browser behavior, we have instead decided to change the spec: Apparently no browser has ever marked CORS requests as blocked and just considered them as mixed display content. On top, Chrome already upgrades CORS requests as part of their mixed content lvl2 implementation.
The comment in https://github.com/w3c/webappsec-mixed-content/issues/63#issuecomment-1386714463 (and the thread around) has more information and additional pointers to spec and wpt changes.
Description
•