Firefox warns "this connection is insecure" when there is a password input in about:blank extension iframe in https page

RESOLVED INVALID
(NeedInfo from)

Status

()

RESOLVED INVALID
a year ago
a year ago

People

(Reporter: remy, Unassigned, NeedInfo)

Tracking

53 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

a year ago
Created attachment 8870424 [details]
Screen Shot 2017-05-18 at 19.36.15.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170518000419

Steps to reproduce:

We initially reported the issue to Victor Ng <vng@mozilla.com> who invited us to report this as a bug.

Using passbolt firefox extension (https://www.passbolt.com) you get a "this connection is insecure on the login page. The extension creates iframe with base url about:blank?pagemodname . When this iframe contains a password field on a https page, Firefox since version 53 display a warning. I suspect that a URL starting with moz-extension:// (new web extension model) would probably trigger the same issue, but I haven't tested it yet.

It is "necessary" for an extension such as passbolt to interact securely with a web page to be able to insert iframe, so that the main page can not access the content of that iframe (in this case the private key passphrase).


Actual results:

See screenshot.


Expected results:

The page should not trigger any warning when the iframe scheme is either https, about:blank and/or moz-extension://

Comment 2

a year ago
It sounds like a duplicate of bug 1334760, or very similar.
Component: Untriaged → Security
Component: Security → DOM: Security
Product: Firefox → Core
Doing an XHR request in about:blank is probably not blocked as mixed active content, how can we be sure that passbolt is not doing that?

> It is "necessary" for an extension such as passbolt to interact securely with a web page to be able to insert iframe, so that the main page can not access the content of that iframe (in this case the private key passphrase).

If I understand you correctly passbolt injects this page into random webpages? How does it protect against the host page simply removing the iframe and overlaying it with their own version, thereby tricking the user into entering the passphrase? Maybe I misunderstand the use case.


Using moz-extension:// is probably the right choice, I remember adding it to the list of trustworthy origins in bug 1277524 so it should be fine in an iframe on an HTTPS page. Else that would be a bug, I think.
> Doing an XHR request in about:blank is probably not blocked as mixed active content, how can we be sure that passbolt is not doing that?

*XHR request over insecure HTTP
(Reporter)

Comment 5

a year ago
Hi Johann,

Thank you for taking the time to look into this.

> Doing an XHR request in about:blank is probably not blocked as mixed active content, how can we be sure that passbolt is not doing that?

Passbolt only send requests to the registered domain during the setup. By default it is not possible to setup a passbolt instance without HTTPS. It is possible to serve it over HTTP without SSL with some debug flags on, but this is not the default. Also in that case it would make sense the display a warning (HTTPS / about:blank iframe with password in it = no warning, HTTP / about:bank with password input in it = warning).

>  If I understand you correctly passbolt injects this page into random webpages?

Similarly passbolt only insert iframes on the pages of the domain that was selected during the first step of the setup.
Because passbolt is open source we cannot provide a whitelist of URLs directly in the plugin as that would prevent people from self-hosting it, but it is far from random as it needs explicit user validation.

> How does it protect against the host page simply removing the iframe and overlaying it with their own version, thereby tricking the user into entering the passphrase?

This case is handled using the "security token" the three letter and color code that is next the input field in that iframe. Other plugins such as Mailvelope or Criptup use a similar system with a background image that is unique / configurable by the the user. This idea / model was introduced by Cure53 during their Mailvelope review.

> Using moz-extension:// is probably the right choice, I remember adding it to the list of trustworthy origins in bug 1277524 so it should be fine in an iframe on an HTTPS page. 

Great, as long as it's working with moz-extension:// it doesn't make sense to put some work to make this use case work with about:blank, as anyway we have to update to webextension in the coming weeks. We can report if it's the same behavior. The about:blank "trick" was use because firefox didn't allow to insert iframes from the plugin self.data.url. 

Cheers
Maybe you didn't mark your resource as content-accessible? If you're sticking it in a web page (as opposed to a pure extension thing like a panel) I think you need to make it accessible in your package manifest.
Let us know when you've tried moz-extension: and whether it works.
Flags: needinfo?(remy)
This doesn't sound like a firefox "bug", but an issue for an extension to deal with.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.