Closed Bug 1404163 Opened 7 years ago Closed 6 months ago

Mixed-content blocker should block <img crossorigin=> requests

Categories

(Core :: DOM: Security, defect)

defect

Tracking

()

RESOLVED WONTFIX
Webcompat Priority P3

People

(Reporter: kmckinley, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: privacy, Whiteboard: [domsecurity-backlog1])

Attachments

(1 file)

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
It appears that we fetch the image, but do not display it.

See https://mixed-content-tests-mozilla.org/tvyas/crossorigin.html
Group: core-security → dom-core-security
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.
Assignee: nobody → kmckinley
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [domsecurity-active]
Group: dom-core-security
Keywords: privacy
Assignee: kate+bugzilla → nobody
Status: ASSIGNED → NEW

Resetting priority and other flags so it shows up in our next triage meeting - we should re-evaluate that bug.

Priority: P2 → --
Whiteboard: [domsecurity-active]

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

Priority: -- → P3
Whiteboard: [domsecurity-backlog1]

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 )

Webcompat Priority: --- → ?
Webcompat Priority: ? → P3
Severity: normal → S3

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?
Severity: S3 → --
Priority: P3 → --

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.

Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: