369503 - Prevent or warn about insecure access to content by plugins in secure pages

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Gervase Markham [:gerv]]

I recently received an email from Yngve Pettersen, Opera's security guy, suggesting that as a group, the browser manufacturers need to do something about unsecured access to content by plugins embedded in secure pages.

CCing beltzner so he can take this as input into his thoughts about security UI (specifically, the 'mixed content' UI) in Firefox 3.0.

Yngve wrote:

As I pointed out in my "Secure Sites that arent't" article in August <URL: http://my.opera.com/yngve/blog/show.dml/382945 > I ran into a Flash applet for hotel bookings (www.wynnlasvegas.com) on a secure page that did two things:

  1. The applet loaded content from an unsecure server as part of its 
     initialization
  2. It POST submitted credit card details to an unsecure server

In case 1, the padlock should be taken away, and Opera did (I am not sure about other browsers on this point).

Case 2 was the serious problem, because no secure to unsecure form submit warning was displayed to the user (we fixed that in 9.10). I am not aware that other browsers display a warning for this case (plugin POST submit).

I've just been testing https://www.beatport.com/ , a music shopping site, which is not just doing both of the above from an applet, their design is based on mixed security (most of the images) and unsecure POST submits from the secure page (and they are complaining about the warning dialogs from Opera)

Both of these cases break the security module implied by selecting a secure page, and I think they should be treated as such.

May I suggest, if you have not already done so, that you implement padlock removal (and include the mixed security warning if you have one) for case 1 and 2, and that you implement a unsecure form submit warning for any unsecure (POST) submit from an applet in a secure page?

I've also seen a couple of other cases where secure and unsecure content is mixed. for those browsers I've tested the padlock have been removed, but the results concerning the dialog about mixing security that some browsers can display have been decidedly  ... mixed (pun not intended).

It is in particular elements that are originally referenced by a https URL, but then redirected to a HTTP that are causing the problems.

I've seen this type of cases for

  - Stockbroker images of stock prices.
  - inline stock analyze documents
  - External unsecure CSS files (which would give an attacker quite some 
    control)
  - External unsecure Javascript files (which would give full control) I saw 
    this on a payment page due to a reverse proxy configuration error

IMO the only reason these mixings can have survived on the sites as long as they did and in some cases still do, is because warnings about the situation are not displayed prominently enough, or at all (Opera just removes the padlock, which may be too little).

I've started to think that the best way to handle such mixing would be to block it completely. Such a change should probably be coordinated  among all the browser vendors to avoid problems.

What do you think?


--Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Does this really need to be security sensitive? This isn't something that evil-doers can use to hack the user.

Comment 2

[Daniel Veditz [:dveditz]]

Depends on the plugin, doesn't it? If you've got a flash script loading things insecurely and modifying the page based on what it loads... 

Or even if it's just loading and displaying live stock market data, and you think you're securely connected to your broker's site but the data is streaming insecurely and unbeknownst to you is coming from an hacker wanting you to panic and sell short. Or the applet *is* what you use to buy/sell and isn't at all secure from eavesdropping at your local wifi cafe -- we warn when you post insecurely from a secure page, why should applets get a free pass?

Comment 3

[Boris Zbarsky [:bzbarsky]]

I think the problem is the following code in nsPluginHostImpl::NewPluginURLStream:

5994         nsnull, /* do not add this internal plugin's channel
5995                 on the load group otherwise this channel could be canceled
5996                 form |nsWebShell::OnLinkClickSync| bug 166613 */

That prevents notifications from being sent to the security code.  That bug has wonderful comments like:

  "this patch is a temp solution for 1.2 release"

Comment 4

[Kai Engert (:KaiE:)]

for reliably preventing insecure loads we require a fix for bug 62178.

Comment 5

[Josh Aas]

NPAPI plugins are trusted code and they can open network connections without going through the browser/NPAPI. Many do. We can probably do a bit more to help people here but ultimately it is a battle we can't win with NPAPI.

I don't see a reason to keep this bug hidden any more. It'll benefit from a wider discussion here. Do you agree, dveditz?

Comment 6

[Gervase Markham [:gerv]]

CCing Tanvi, as the person working in this area.

Gerv

Comment 7

[Tanvi Vyas[:tanvi]]

The Mixed Content Blocker will now block Mixed Active Content on HTTPS pages.  We do not block Mixed Display Content by default.  What's the difference?  There are some definitions here: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/#Mixed_Content_Classifications.  We do not show the lock icon if there is any mixed content loaded on a page.

This bug is about plugin subrequests (TYPE_OBJECT_SUBREQUEST).  Some plugin subrequests may be active (script) and some may be passive (images).  Unfortunately, Firefox can't tell the difference.  In order to avoid breaking plugin functionality across various websites (even youtube), we had to treat TYPE_OBJECT_SUBREQUEST as Mixed Display Content.  Ideally, we'd be able to differentiate the two and block the active requests, but we'd need help from plugin developers for this.  Bug https://bugzilla.mozilla.org/show_bug.cgi?id=836352 talks about this long-term goal and proposals some potential solutions.

For forms on HTTPS pages that post to HTTP, Firefox shows an alert type warning to users before their data is submitted.  This has been in the browser for ages, can't be turned off, and I have no plans to change this functionality.  Since this has been around for ages and it is quite annoying, I'm hoping the majority of the web just isn't posting from HTTPS to HTTP.  This is what it looks like:
https://people.mozilla.com/~tvyas/MixedContentPost.png

I'm not sure if this warning comes up when a plugin on an HTTPS page includes a form that posts over HTTP.  If someone could create a plugin and test that out, that would be great.

Comment 8

[Jonathan Kingston [:jkt] he/him]

This was actually resolved in: Bug 1190623