Feature request: require https to fill in form

[dseomn]

General information

• Operating system + version: Debian testing
• Browser + version: Firefox 94.0-1
• Information about the host app:
  • How did you install it? package manager
  • If installed an official release, put a version ($ browserpass --version):
  • If built from sources, put a commit id ($ git describe --always):
• Information about the browser extension:
  • How did you install it? package manager
  • Browserpass extension version as reported by your browser: 3.7.2

---

Exact steps to reproduce the problem

1. Create a password for localhost or 127.1.2.3 (in case localhost was a hardcoded exception that allowed http).
2. Go to a page over cleartext HTTP at that address.
3. Use the extension to fill in a login form on that page.

What should happen?

It would be nice if there were some way to prevent accidentally filling in forms on non-HTTPS sites. Maybe disable the form fill, so the user would have to manually copy/paste the data?

What happened instead?

It filled in the form the same as if it were over HTTPS.

[erayd]

There are legitimate reasons for needing to fill into HTTP sites - it's a fairly common use-case for things that are not on the public internet - so disabling that capability entirely as you suggest is not something we will be doing.

However, we could certainly add a confirmation step that warns the user and asks if that is really what they want to do - something similar to what we currently do for filling into foreign-origin iframes. This will prevent accidentally filling to an insecure origin, but without damaging functionality.

[erayd]

@maximbaz We should address the foreign-origin confirm() deprecation at the same time, as this is already something that needs changing before the API goes away.

[max-baz]

I would like to add that filling a form in itself is almost never leaking any credentials over HTTP, it's the action of submitting a form that does it, regardless of whether the form was filled using extension or pasting from clipboard. It doesn't feel like blocking or confirming specifically form filling functionality and not clipboard interaction would be very obvious to the user, don't you think so?

I can see a benefit of adding a confirmation dialog doe the HTTP modal auth scenario though, where browserpass sends credentials right on selecting an entry 🤔

[erayd]

I would like to add that filling a form in itself is almost never leaking any credentials over HTTP...

HTTP is trivial to MITM and inject javascript to grab the contents of form fields, regardless of whether or not they are submitted. While filling a form on an untampered page does not usually result in this happening, the threat model is similar - i.e. we are defending against an attacker who somehow has control over at least part of the network between the client and the server, either to modify traffic or simply to monitor it.

I agree with your comments about the clipboard. We want to be ensuring that it's something the user actually wants to do, and explain why we are asking them; simply making things harder (by disabling autofill) isn't a good way to communicate this.

You raise a good point about modal authentication - I agree that a confirmation there would be a good idea.