1528189 - Sandboxed form password input warns about an insecure connection despite the valid HTTPS endpoint it's submitted to

Status: NEW

(Toolkit :: Password Manager, defect, P3)

Description

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Run the following HTML form on a domain with a valid HTTPS connection:

<form enctype="application/x-www-form-urlencoded" method="post">
  <label>
    Your organization
    <input type="text" name="tenant" minlength="4" maxlength="255" value="" autocomplete="organization" required>
  </label>
  <label>
    Email Address
    <input type="email" name="email" minlength="6" maxlength="255" autocomplete="email" required>
  </label>
  <label>
    Password
    <input type="password" name="password" minlength="6" maxlength="255" autocomplete="current-password" required>
  </label>
  <button type="submit">Submit</button>
</form>

Enter the password field and start editing.

Actual results:

When you enter the password field you'll see the dropdown with the warning "This connection is not secure. Logins entered here could be compromised. Learn more." which is completely misleading because when the form's action attribute is empty the form is submitted via HTTPS to the same endpoint it's rendered from (according to this HTML spec 4.10.21.3 item #12 https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#form-submission-algorithm). It's also displayed that way in the Network section of the dev tools.

Expected results:

I expect this security warning to be not displayed because the form is submitted via HTTPS and there is no security risk.

Comment 1

[Paul_B]

Hi reporter,

Thank you for taking the time to add this report. However, I was not able to reproduce the issue that you mentioned. I ran the form here https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_basic and I was able to enter the password without any issues/dropdowns visible on both the latest Firefox release build and Nightly build, on Ubuntu 18.04 and Windows 10. I did not notice anything in the Network section.

Could you please retest this using the latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Out of curiosity I think I tracked this down to:

https://searchfox.org/mozilla-central/rev/93905b660fc99a5d52b683690dd26471daca08c8/toolkit/components/passwordmgr/InsecurePasswordUtils.jsm#69

In case someone's interested in poking at it :)

Comment 3

[mail]

I tested again and found the cause.

This happens only when I have content-security-policy HTTP header served from the web-server.

So, the conditions are:

1. Valid HTTPS connection
2. The server sends content-security-policy: default-src 'none'; img-src data: https:; style-src 'nonce-<some-nonce>'; sandbox allow-forms allow-popups allow-scripts; frame-ancestors 'none'
3. HTML form served with the header above:

<form enctype="application/x-www-form-urlencoded" method="post">
  <label>
    Your organization
    <input type="text" name="tenant" minlength="4" maxlength="255" value="" autocomplete="organization" required>
  </label>
  <label>
    Email Address
    <input type="email" name="email" minlength="6" maxlength="255" autocomplete="email" required>
  </label>
  <label>
    Password
    <input type="password" name="password" minlength="6" maxlength="255" autocomplete="current-password" required>
  </label>
  <button type="submit">Submit</button>
</form>

4. Focus the password input and you can see the This connection is not secure. Logins entered here could be compromised. Learn more. message in the drop-down.

Comment 5

[Matthew N. [:MattN]]

(In reply to mail from comment #3)

This happens only when I have content-security-policy HTTP header served from the web-server.

2. The server sends content-security-policy: default-src 'none'; img-src data: https:; style-src 'nonce-<some-nonce>'; sandbox allow-forms allow-popups allow-scripts; frame-ancestors 'none'

Hello, thanks for debugging, this was a somewhat intentional change so I'd like to learn more…

What is the use case for having such a policy on a login form? The Firefox password manager avoids working on sandboxed documents and I think third-party password managers also wouldn't autofill on them. The reason is that sandboxing is generally used for untrusted content.

Comment 7

[mail]

Hello Matthew,

The login form is served from our identity provider, so it's as strict as it can be (mostly to protect users from malicious browser extensions).

Despite our strict CSP password managers (e.g. LastPass) are able to fill the form in Chrome and standard browser auto-completion also works in all browsers including Firefox. sandbox allow-forms allow-popups allow-scripts; means that forms, new windows and scripts are allowed according to https://content-security-policy.com/ . I assume that's why the password managers work in other browsers but Firefox.

Regardless the policy and whether scripts are allowed or not, Firefox should not display misleading messages to our users making them think our product is insecure, especially when the security is the main focus of the product.

Comment 8

[Matthew N. [:MattN]]

(In reply to mail from comment #7)

The login form is served from our identity provider, so it's as strict as it can be (mostly to protect users from malicious browser extensions).

If you're saying that password manager extensions work then it's unclear to me how you are protecting from "malicious browser extensions"?

Despite our strict CSP password managers (e.g. LastPass) are able to fill the form in Chrome and standard browser auto-completion also works in all browsers including Firefox. sandbox allow-forms allow-popups allow-scripts; means that forms, new windows and scripts are allowed according to https://content-security-policy.com/ . I assume that's why the password managers work in other browsers but Firefox.

I'm a bit confused as you are saying login autofill/autocomplete works in Firefox but then say it doesn't work in Firefox… which one is it?

Regardless the policy and whether scripts are allowed or not, Firefox should not display misleading messages to our users making them think our product is insecure, especially when the security is the main focus of the product.

Dan, what do you think we should do about this case? What should be our signal to show or not-show the warning?

Thanks

Comment 9

[mail]

If you're saying that password manager extensions work then it's unclear to me how you are protecting from "malicious browser extensions"?

As I said "as strict as it can be". Our customers need to use password managers, but since the page also allows customization by the organization and there are other extensions that can embed their resources we should put some limitations there, etc.

Despite our strict CSP password managers (e.g. LastPass) are able to fill the form in Chrome

in Chrome is the main part. Password managers don't work in Firefox even though the scripts are allowed in CSP, only browser auto-completion works. I don't know the exact reason behind it.

In general, I noticed that Firefox behaves in its own way when it comes to CSP, for instance, prevents in-line SVG styles from loading when CSP contains style-src 'nonce-<some-nonce>'; but Chrome loads them just fine.

I understand that saying "works in Chrome" does not help here but as a developer/user I would like to have the same behavior across all the browsers.

I'm a bit confused why the issue topic shifted to discussing the CSP definition we have. It's absolutely irrelevant why we have this CSP. The facts are:

1. The form is submitted via HTTPS and secure
2. Firefox displays the warning to the users that the form is insecure (which is based on assumption the form is submitted via HTTP)

As I said, regardless the CSP the behavior is wrong and should be fixed.

Comment 10

[Daniel Veditz [:dveditz]]

Dan, what do you think we should do about this case? What should be our signal to show or not-show the warning?

There are (at least) two issues swirling around here, whether we should show the "insecure" warning, and whether we should auto-fill passwords.

If the data: document comes from a secure (https) load or was written by a secure page I'd expect the isSecureContext check to return true, and that we shouldn't show the warning if it's also submitting to a secure URL (as in this case). I don't think we should blindly trust data: urls so I hope the original source is available to the .jsm where you're making this determination. We need that to correctly compute relative URLs so we have it /somewhere/.

Not allowing the password manager on null-principal pages is a reasonable choice: the domain has explicitly sandboxed the content which is a signal "I don't fully trust this content". If the sandbox has allow-same-origin that would be a different story (and in fact we would support the password manager in that case).

On the other hand browsers or password managers that require user-interaction before filling in a password could make a reasonable argument that the user interaction demonstrates that the user is going to fill it in anyway so might as well make it convenient for the cases that are legitimate. But our password manager, sadly, fills in without interaction in the common case and that's unsafe in sandboxed content.

Comment 11

[Matthew N. [:MattN]]

To be clear, I wasn't trying to re-open the debate on autofill… I just care about the warning for this bug. I specifically asked about the insecure warning in the bug where this got implemented and my understanding then was that showing the warning was fine in this case as it's untrusted content. Are you saying we should stop showing the insecure warning due to the null principal if we wouldn't otherwise show it for that field? https://hg.mozilla.org/mozilla-central/diff/3514b960ff95/toolkit/components/passwordmgr/nsLoginManager.js

Comment 12

[Daniel Veditz [:dveditz]]

No, not quite what I was saying. If the document is sandboxed and not allow-same-origin then that IS a strong signal that the site doesn't trust the content. That's what the spec says the sandbox is for. Seems worth warning the user about, but the specific string we're using says the "connection" is not secure. That's not true and leads to arguments like this bug.

I think we do need A warning. In the more typical sandbox case it's pretty easy to imagine the untrusted content trying to create a fake login form to phish the credentials off to another site, taking advantage of the REAL site's url in the addressbar. It's a minor confusing bug to say the "connection" is secure rather than saying the content is untrusted.

e.g.
from: "This connection is not secure. Logins entered here could be compromised. Learn more."
to: "This content is not trusted by this site. Logins entered here could be compromised. Learn more."

Either way it's not going to make this reporter any happier so I don't know how important it is to add a new string for it.

Comment 13

[Matthew N. [:MattN]]

OK, thanks for clarifying. I'm calling this P3 then (could be P5) since as you say, it doesn't seem like it's going to fix the reporter's problem.

Reporter, I guess the solution for you is adding allow-same-origin to the sandbox rules.