903211 - Allow Mixed Content Frames that are Sandboxed

Status: NEW

(Firefox :: Security, defect)

Description

[Tanvi Vyas[:tanvi]]

We lump frames into the "Mixed Active" category for two reasons:

1) They may be able to navigate the top level page
2) They can trick the user into disclosing sensitive information through form fields.
(See https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/#Mixed_Content_Frames for more details).

What if the iframe is sandboxed?  If an HTTPS page includes an HTTP sandboxed iframe that does NOT have the allow-top-navigation and allow-forms values, does that alleviate the mixed Active content risk?  If so, should we add treat this situation as mixed passive instead?  If not, why?

If the sandboxed iframe has allow-scripts, then a MITM attacker can still inject script onto the HTTP frame that could try to install malware.  No other passive content could cause a malware installation.  So perhaps the sandboxed frame would also have to not allow-scripts.  This is much trickier, and makes this case quite uncommon since most websites will require script to function properly.

Thoughts?

Comment 1

[sjw]

I think this is a verry good point. We should handle this like mixed passive content (warning in error console and no padlock in adressbar, but not blocked and the mixed content blocker hidden).

Comment 2

[Tanvi Vyas[:tanvi]]

(In reply to Tanvi Vyas [:tanvi] from comment #0)
> If the sandboxed iframe has allow-scripts, then a MITM attacker can still
> inject script onto the HTTP frame that could try to install malware.  No
> other passive content could cause a malware installation.  So perhaps the
> sandboxed frame would also have to not allow-scripts.  This is much
> trickier, and makes this case quite uncommon since most websites will
> require script to function properly.
> 

Plugins are blocked by default in an iframe sandbox, and there is no way to unblock them.  So in order to have a drive-by-malware attack, the MITM attacker would have to leverage a vulnerability with Firefox itself.  This reduces the threat surface, especially for our up-to-date users.  Then again, there could always be an attack we don't know about.

Is there a way for a sandboxed iframe to get around a allow-top-level-navigation restriction with the ability to run scripts?

Comment 3

[Mikko Rantalainen]

As a CMS programmer, I'd be interested in use cases that allow CMS to be secure (HTTPS connections, HttpOnly+Secure cookies, possibly pretty strict CSP) but still allows users to add content that allows embedding external content in <iframe> elements. The content that would need to work is video services similar to youtube and vimeo, but lets assume that those 3rd party services do not support HTTPS connections. Another use case is embedding content from services such as http://www.geogebratube.org/ and http://www.kerpoof.com/ which definitely need scripting within the iframe.

In short, all use cases that I can think of require following:

- Host document decides the size of the iframe element (host document is served with HTTPS connection).
- Embedded iframe is served from different domain using HTTP connection.
- Embedded iframe does not need to interact with the host document.
- Embedded iframe needs to be able to use scripting.
- Embedded iframe needs to be able to open a link in a new tab or window (e.g. embedded youtube video with a link to the original youtube page containing the video) but it does not need to navigate the host document. The usual popup blocking would still be active, of course.
- Embedded iframe needs to be able to use plugins. (Flash player and possibly Java plugin. Fortunately, the latter is going down fast...)

With the exception of possible phishing attacks inside the iframe, I can see no problem with allowing all of the above as long as we're talking about attacks toward the host site. The phishing attack can be dwarfed by the host document using visible frame or some other technique to provide required hints to prevent user from entering passwords or other sensitive data within the iframe.

I'd be totally okay with losing the lock icon in the URL bar as long as the browser still keeps using SSL/TLS connection. In fact, I'd be happy to have the browser UI look like the CMS site were served with HTTP connection if I could get mixed content stuff to work without issues. In short, I would really want to use secure connections for the host document and still be able to embed 3rd party content.

The point I'm trying to do is *I don't need to try to convince my users that the host site is secure*. I'd still love to use encrypted connections for the host document to avoid direct attacks towards my site. Current Firefox UI implementation hints the user that HTTP served host document that embeds HTTP served 3rd party content is okay, but HTTPS served host document that embeds HTTP served 3rd party content is suddenly a huge security risk. That does not seem sane to me. Losing EV certificate green color for using mixed content would make sense but I'm not interested in EV decorations for my use case.

Also note that because I'm talking about CMS system where visitors can add content, the attacker is able to provide his or her attack using HTTPS connection so this mixed content blocking is just adding false sense of security. A possible attack would be along the lines

<iframe width="640" height="480" src="https://attacker.net/phishing.html"></iframe>

and this would be considered as "secure" according to user agent indicators. The same applies to any XSS vulnerability within the CMS system.

If only there were separation between "secure connection" and "secure site"/"secure content". I'm granting for the former, not for the latter for my use case.

Comment 4

[Frederik Braun [:freddy]]

(In reply to Tanvi Vyas [:tanvi] from comment #2)
> Is there a way for a sandboxed iframe to get around a
> allow-top-level-navigation restriction with the ability to run scripts?
No, sandboxed iframes convey a display-only capability. If there was a way, it would be a browser bug. That being said, I agree on regarding sandboxed iframes as passive content.

Comment 5

[Devdatta Akhawe [:devd]]

Even if allow-forms is absent, can't the "attacker" (with JS capabilities) just draw something that looks like a form and send data using XHR or image tags etc?

I think sandbox with scripting, forms, navigation, and same-origin disabled (i.e., no "allow-*" in attribute value) can be considered passive content.

Comment 6

[Eric Burnett]

I would argue that a sandboxed iframe without allow-top-navigation is sufficient, and allowing it (or some other form of opt-out) is in fact necessary.

(In reply to Tanvi Vyas - out until 9/4 [:tanvi] from comment #0)
> If the sandboxed iframe has allow-scripts, then a MITM attacker can still
> inject script onto the HTTP frame that could try to install malware.  No
> other passive content could cause a malware installation.  So perhaps the
> sandboxed frame would also have to not allow-scripts.  This is much
> trickier, and makes this case quite uncommon since most websites will
> require script to function properly.

As noted above, for an MITM'd allow-scripts iframe to install malware, it must do so *without plugins*, which means it would need to exploit a hole in the browser itself. This same argument applies to truly passive content - a MITM'd image could exploit a PNG bug, for example. I don't consider that a sufficient argument against sandboxed iframes either, although I will grant that the attack surface is larger for scripts.

The idea of MITM malware being an issue also implicitly assumes that the user never browses any other HTTP pages. For if they do, the MITM could simply attack those pages instead, leaving the user no better off. And the idea of a locked-down environment where there are no HTTP pages being browsed, yet there is a sandboxed HTTP iframe available to attack, seems sufficiently implausible.


On the flip side, There are strong use-cases for wanting HTTP iframes on HTTPS pages. See the CMS comment above, or for example within Google we have many (internal and external) pages that allow the preview or review of arbitrary HTTP ads. The containers these are embedded into needs to be HTTPS, since they are publisher or advertiser specific, but we cannot assume the ads support HTTPS (and in fact the majority do not). We've examined the various workarounds available, but they all require a lot of effort (generally user-side), reduce security significantly, and/or are a terrible user experience. Some ideas considered:
 - Serve everything from HTTP
 - Disable with browser flag (assuming one exists)
 - Implement a rewriting proxy to serve content from HTTPS
 - Kick content out to a new tab/window
Note that user confusion is not an issue for these use-cases - these iframes are clearly delineated within their pages, so users are not going to be confused if they see a form show up.

And really, if a site owner has taken the effort to put an HTTP iframe on an HTTPS page, but opt-out (via sandbox or other) of this security protection, it seems reasonable to assume they had a valid reason to do so.

If you have any other ideas for how we can safely display insecure content, I'd love to hear them. As it stands we have multiple products that will be broken by this.

Comment 7

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

I suspect that when CSP 2 is published, there's going to be a huge increase in the number of sites are going to prohibit framing via the frame-ancestors directive (the replacement for X-Frame-Options). In fact, everybody should be using frame-ancestors to prevent framing by default. This means that, even independent of mixed content blocking policy, things
like Google Translate and CMS systems are going to have extreme difficulty without implementing proxies to convert the originally HTTP content into HTTPS. As far as I understand, the same applies to Google's ad preview mechanism.

Therefore, the idea of using iframes for these mechanisms seems like a lost cause.

Comment 8

[Eric Burnett]

Presumably anything intended to be embedded (content or ads) would *not* set this attribute, or they'd be wholly broken. So iframes will be as viable for that use-case in a CSP2 world as before.

Unexpected iframing, e.g. arbitrary pages via Google Translate (if that's how it works), may presumably be impacted by CSP2. That's somewhat irrelevant to this bug though.