New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 677845 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Jan 2017
Cc:
█ mkwst@chromium.org
est...@chromium.org
tsepez@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

iframe with http content in https page should only give a warning, not be blocked

Reported by teo8...@gmail.com, Jan 2 2017 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce the problem:
1. visit a https://whatever.com page that contains an iframe with src="http://otherdomain.com"

What is the expected behavior?
The content should not be blocked; you should get just a warning in the console, and the grey "https" in the address bar (as opposed to the green "https" with a lock icon) to indicate mixed content, just like when you have images whose src is http

What went wrong?
The content is blocked and not loaded at all, like with scripts.

Did this work before? N/A 

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 24.0 r0

There is already a security model that sandboxes the content of an iframe ans won't allow any active script in it to access whatever is outside it, right? So, unless that model is broken (which would be a separate issue), there shouldn't be any need to block the iframe content any more than an image, video, audio or (!!) <object>.

Comment 1 by kenrb@chromium.org, Jan 2 2017

Cc: tsepez@chromium.org mkwst@chromium.org est...@chromium.org
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Via-Wizard-Security Type-Bug
We distinguish between 'active' and 'passive' mixed content, and an iframe document is considered active content, which distinguishes it from something like an image and has higher risk in the event of a MitM tampering attack.

Your point about iframe sandboxing is fair, and this has been considered in the now-archived  bug 285301 .

I'm removing security flags because this isn't a vulnerability, and cc'ing people who are interested in this topic.

Comment 2 by ajha@chromium.org, Jan 4 2017

Labels: Needs-Triage-M55

Comment 3 by mkwst@chromium.org, Jan 9 2017

Status: WontFix (was: Unconfirmed)
This is the model browsers have generally agreed upon, specified in https://w3c.github.io/webappsec-mixed-content/#categorize-settings-object. I think if we're going to make changes to our mixed content blocking, we'd be making it stricter, rather than more lax.
►

Sign in to add a comment