824871 - Regression - nsMixedContentBlocker sets wrong Security State for http pages with https iframes

Status: RESOLVED WORKSFORME

(Core :: DOM: Security, defect, P1)

Description

[Tanvi Vyas[:tanvi]]

This is a regression from the patches applied to bug 782654.

https://people.mozilla.com/~tvyas/WrongSiteIdentityMessage.png

I found a bug in the code that landed on nightly.  Suppose you visit a page that is http and it has an https iframe within the page.  If that https iframe has mixed content, we set the identity state to STATE_IS_BROKEN when it should be unknown (http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsMixedContentBlocker.cpp#77).  We should instead check if the load is within an iframe or if the rootDoc is https.  If the rootDoc is not https, then we should allow the load and return, without calling eventSink and changing the security state.

POC can be found here http://people.mozilla.com/~tvyas/mixediframe2.html

+++ This bug was initially created as a clone of Bug #782654 +++

Comment 1

[Tanvi Vyas[:tanvi]]

Attachment: Prevent http pages flagged as mixed content when they have mixed content iframes v1

I fixed the bug - https://people.mozilla.com/~tvyas/RightSiteIdentityMessage.png

Patch is attached and ready for review.  We need to land this in nightly before the merge to Aurora (FF20), or people will get confusing site identity messages in FF20.

Push to try - https://tbpl.mozilla.org/?tree=Try&rev=cc2cc023df89

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Tanvi Vyas [:tanvi] from comment #0)
> I found a bug in the code that landed on nightly.  Suppose you visit a page
> that is http and it has an https iframe within the page.  If that https
> iframe has mixed content, we set the identity state to STATE_IS_BROKEN when
> it should be unknown
> (http://mxr.mozilla.org/mozilla-central/source/content/base/src/
> nsMixedContentBlocker.cpp#77).  We should instead check if the load is
> within an iframe or if the rootDoc is https.  If the rootDoc is not https,
> then we should allow the load and return, without calling eventSink and
> changing the security state.

Let's say we have attacker.com framing https://mozilla.org/. Whether or not we allow mixed content on https://mozilla.org affects the security of mozilla.org, so we cannot allow it simply because attacker.com chose to frame it. Otherwise, our defenses against attacks that inject mixed content would be trivial to work around: just get the user to navigate to a page where you can insert an iframe that in turn frames the victim site.

Consequently, I think that STATE_IS_BROKEN is the correct state for the iframe. (If/how we present the STATE_IS_BROKEN state for an iframe in the security UI we have is another thing.)

When the user chooses to un-block blocked mixed content in this case, we probably should un-block mixed content only in the top document (and possibly same-origin or same-eTLD iframes), but not framed content--unless the UI somehow makes it clear that we're decreasing the security of the victim (framed) site. This would be similar to how per-origin permission prompts enable features (such as AppCache) only in the top-level document. (How does click-to-play plugins deal with this case?)

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 695897 [details] [diff] [review]
Prevent http pages flagged as mixed content when they have mixed content iframes v1

I think I agree with Brian. We could allow same-eTLD perhaps, but
always... doesn't sounds too good.

Comment 4

[Tanvi Vyas[:tanvi]]

There are two issues that were identified in the bug comments.

1) An http page has an https iframe.  Mixed active content is blocked.  Should mixed contente on the https iframe load?

2) An https page has an https iframe.  Mixed active content is blocked.  The user overrides the blocking and wants the mixed active content to load.  Do we load the mixed active content on the https top level page only?  The https page and the https subdocuments?  The https page and only same origin https subdocuments?

Situation 2 is separate from this regression bug and should be filed as a blocker to bug 815321 (the Mixed Content Blocker Master Bug).  This bug was to address the odd UI that shows up on nightly in situation 1.

For Situation 1:

Chrome and IE both block the mixed content on the iframe page.  Chrome shows it's shield its url bar, and IE shows an info bar at the bottom of the page that tells the user that insecure content was blocked.  If we do want to block this content now without working out how to explain to a user that content on a subdocument has been blocked, we can make sure that the icon and the site identity info doesn't change - it should match the connection top level page and not the iframed pages.  The door hanger will still exist and the user can choose to load the mixed content.  This wouldn't cause a change to the icons or the site identity text, since they currently represent the connection to the top level page and not the subdocuments.

I'll start writing a patch for this.

Comment 5

[Tanvi Vyas[:tanvi]]

Comment on attachment 695897 [details] [diff] [review]
Prevent http pages flagged as mixed content when they have mixed content iframes v1

This is included in the patch to bug 822367.

Comment 6

[Honza Bambas (:mayhemer)]

What happens when an http page loads, say, two different https mixed iframes?

What happens when an http page loads an https mixed iframe that loads another https mixed iframe?

Or whatever crazy combination may happen...

I would suggest we block mixed in any iframe, maybe inform, and don't allow override.  the "maybe" and "don't" are here because UI becomes overcomplicated as it is hard to present the state.  and most users wouldn't understand what's going on.

Comment 7

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Tanvi Vyas [:tanvi] from comment #4)
> 1) An http page has an https iframe.  Mixed active content is blocked. 
> Should mixed contente on the https iframe load?

No, because this would facilitate attacks on the the framed victim site as explained in comment #2.
> 
> 2) An https page has an https iframe.  Mixed active content is blocked.  The
> user overrides the blocking and wants the mixed active content to load.  Do
> we load the mixed active content on the https top level page only?  The
> https page and the https subdocuments?

This is bug 826599 now.

> Chrome and IE both block the mixed content on the iframe page.  Chrome shows
> it's shield its url bar, and IE shows an info bar at the bottom of the page
> that tells the user that insecure content was blocked.  If we do want to
> block this content now without working out how to explain to a user that
> content on a subdocument has been blocked, we can make sure that the icon
> and the site identity info doesn't change - it should match the connection
> top level page and not the iframed pages.

Agreed.

> The door hanger will still exist
> and the user can choose to load the mixed content.  This wouldn't cause a
> change to the icons or the site identity text, since they currently
> represent the connection to the top level page and not the subdocuments.

This is to be decided in bug 826599.

Users don't understand iframes or subresources. Basically, the security indicators should be pessimistic and choose display the state of the worst part of the page. And, this is part of the rational for disallowing the unblocking of mixed content in iframes that aren't same-origin to the main page (bug 826599).

Comment 8

[Tanvi Vyas[:tanvi]]

I believe this is fixed.  If an http page includes an https iframe, mixed active content on the https iframe will be blocked by default.  Closing worksforme.