Password Theft In Hidden Password Field Through Autofill
Categories
(Toolkit :: Password Manager, defect)
Tracking
()
People
(Reporter: levitnudi, Unassigned)
Details
(Keywords: reporter-external, Whiteboard: [reporter-external] [web-bounty-form] [verif?])
Attachments
(1 file)
While email and password autofill feature is important and good for a smooth user experience, there's a terrible chance that attackers are using it every day to steal user credentials. Mozilla browser allows for password autofills previously entered by users across websites hosted on the same domain and all its subdomains. This is a very simple demo to show how this attack can be reproduced and possibly prevented.
-
Upload below html file in any domain / subdomain or localhost with previously saved logins i.e emails and passwords. The purpose of this is to allow the browser to give email and password autofill options with previously used credentials.
-
This demo shows how a hidden password field can be used to steal autofill credentials of that site. For example, a 3rd party code / plugin on a wordpress website that the owner has nothing to do with could be installed e.g to aid in collecting newsletter or subscription emails. Such a plugin can use this autofill feature by hiding a password field beside the email field and sending both email and password to the attacker's website.
Solution
- Disable password autofill in hidden / invisible password fields.
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Clearing priority/severity so this gets triaged.
Comment 2•4 years ago
|
||
I'm pretty sure this is a dupe, and a conversation we have had many times over the years, :tgiles, can you see if you can find it?
To autofill passwords or not boils down to a trade-off between relative risk and user convenience/expectation. But there are some caveats that inform this tradeoff:
- "hidden" is hard to define and detect. There's hidden via markup, CSS, simply off-screen or otherwise obscured from view; skipping filling of hidden fields would be inconsistent as a result.
*In some cases filling hidden fields is actually wanted. Many login forms are split across a couple of pages or similar navigation, and we rely on being able to fill the hidden fields. Similarly, some forms provide fields for the user to type in, but stash the actual username/password values in hidden fields and those are what gets submitted. - To steal credentials from an autofilled form, the script would need to be running in the host page, under the same origin. This would allow stealing of user-filled data as well. So the concern is if autofilling presents some unique risk: there are scenarios in which the user might not realize they have sensitive data in that page and perhaps not exercise the caution they would otherwise. That's the trade-off we currently make, to reduce the clicks and friction for common actions on the web, for most people, most of the time.
Yes hidden is hard to determine, but there could probably be a better way e.g only autofilling the password field on user click / selection. Such ensures that the user already knows there's an existing password field requesting to be filled. In this example, requesting for email and getting both email and password filled simultaneously poses a risk.
Another remedy could be making slight changes in the password manager to inform the users (in written form) that they are about to enter their passwords. Just showing a key icon to represent passwords / credentials may not be enough for unsuspecting internet users.
Comment 4•4 years ago
•
|
||
I believe this issue is related to, but not necessarily a duplicate, of Bug 1121119 - Breakdown: Consider ignoring the formSubmitURL for passwords....could also be related to Bug 610997 - Username + Password Autofill allows Forced Login via Clickjacking.
I'm having troubling finding the "one source of truth" regarding this autofill issue, but I seem to recall that we have this conversation at a regular interval so I'll keep looking around.
On second search, I think we could dupe this against Bug 359675 - provide an option to manually fill forms and login, or Bug 360493 - Cross-Site Forms + Password Manager = Security Failure, or Bug 408531 - password manager + XSS = disaster.
For additional context, the attack that :levitnudi describes appears to be the same described in freedom to tinker article which is not a new attack.
Not sure what we what the resolution of this ticket to be, but providing information as appropriate.
Also take note of the fact that the browser does automatically autofill email and password fields without user clicks / input. This happens immediately on page load. It further supports the risk of exposing user information.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•5 months ago
|
Description
•