Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mixed Content iframes on localhost #73

Open
mozfreddyb opened this issue Jan 15, 2025 · 3 comments
Open

Mixed Content iframes on localhost #73

mozfreddyb opened this issue Jan 15, 2025 · 3 comments

Comments

@mozfreddyb
Copy link

mozfreddyb commented Jan 15, 2025

It has come to our attention that none of the 3 manor browser engines block insecure iframes on websites hosted on localhost. While this was reported as a private security bug, we have decided to talk about this in public because all browsers behave the same. Firstly, because the impact is relatively low and secondly to foster better conversations. (We are working on making the above report public).

The test case is as simple as putting http://example.com in an <iframe> on a page hosted at localhost.

As per the [spec section §4.3 "Does settings prohibig mixed security contexts?"], mixed-content should kick in is based off of whether an origin is potentially trustworthy, which http://localhost definitely is.

We have prototyped a patch in Gecko but do not want to make a unilateral change without cross-browser alignment.

I can see these options:

  • Admit that all browsers behave the same and write it into the standard.
  • Agree on this being fixed across multiple browsers and collaborate.
  • Fix this but provide some sort of opt-out e.g. in DevTools.

CC @estark37, @annevk, @dveditz

(Edit: Credit belongs to Khiem Tran)

@annevk
Copy link
Member

annevk commented Jan 15, 2025

For a while at least we thought we had the invariant that when a document was a secure context, all documents nested inside of it were a secure context too.

I believe that invariant got broken at some point, but I cannot find any evidence right now. In particular I thought data: URLs might break it, but they don't.

This would break it however. If this is truly the only exception, that would be rather unfortunate.

@mikewest
Copy link
Member

I agree with @annevk from a theoretical perspective.

Practically, my guess (in the complete absence of data) is that we'll find that a larger-than-desirable percentage of pages loaded from loopback would violate this constraint. I can add a metric to Blink to see how wrong that guess is, but I'd like to make a decision here with that number in hand rather than in the abstract.

@mikewest
Copy link
Member

(I'll try to get https://chromium-review.googlesource.com/c/chromium/src/+/6179417 landed in the somewhat near future)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants