User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20110323 Firefox/4.0 Build Identifier: Magic ponies! Auto-filled password fields should not have their values available to javascript. Rational with an example: So on Honest Achmed CA website there is a login page and I saved my username('admin') with my password('abc123') - when firefox autofills in my details, the value for my password should not be available to javascript. Assuming the login page is vulnerable to an xss attack, that attack could steal my password - even if I close the page after noticing a dodgy url in my address bar! Reproducible: Always

This could be considered a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=359675.

(In reply to comment #1) > This could be considered a duplicate of > https://bugzilla.mozilla.org/show_bug.cgi?id=359675. Sort of... That was about making it possible to fill a form in via an API (by an extension or something). From what you described you don't want the values that are autofilled to be available to the webpage, which just isn't how the web works. Once it's in the form, the page can see it. Autocomplete handlers aren't visible to the page though, so if you'd like to remember passwords and have them available via the autocomplete UI, then you can set signon.autofillForms to false. That preference predates bug 359675.

@Paul ah... no that isn't what I meant. Like we have httponly cookies, it would be nice to have password type fields, which if pre-filled their values would not be available to *javascript* .

Actual in-the-wild case of this privacy leak described here: http://www.pamgriffith.net/blog/privacy-and-autocompleted-usernames . Proposal for fix: for passwords stored in the password manager, allow JS to read back only dummy values until the onsubmit event fires. This would require careful study to make sure it doesn't break sites, even those that do batshit things like copy all the form values from the visible form to an invisible second form (yes, I have seen *that*)... but the password manager already doesn't work on sites that are sufficiently batshit, so I think the compat hit is likely to be acceptable.

(In reply to Zack Weinberg (:zwol) from comment #6) > Actual in-the-wild case of this privacy leak described here: > http://www.pamgriffith.net/blog/privacy-and-autocompleted-usernames . > > Proposal for fix: for passwords stored in the password manager, allow JS to > read back only dummy values until the onsubmit event fires. This would > require careful study to make sure it doesn't break sites, even those that > do batshit things like copy all the form values from the visible form to an > invisible second form (yes, I have seen *that*)... but the password manager > already doesn't work on sites that are sufficiently batshit, so I think the > compat hit is likely to be acceptable. This sounds pretty reasonable to me (isn't IE doing something like this?), though we have to be careful to do the actual fill-in after all the content onsubmit handlers are triggered.

The injected script can just post the form to a hidden iframe to steal the password, no?

How would fixing this bug impact Web sites that actually use JavaScript for their logins (e.g., Slashdot at <http://slashdot.org/>)?

> Proposal for fix: for passwords stored in the password manager, allow JS to read back only dummy values until the onsubmit event fires. Some sites don't use a <form> element for logins. Check out http://www.hulu.com/ > This would require careful study to make sure it doesn't break sites, even those that do batshit things like copy all the form values from the visible form to an invisible second form (yes, I have seen *that*)... but the password manager already doesn't work on sites that are sufficiently batshit, so I think the compat hit is likely to be acceptable. We should be making the password manager work with more sites, not fewer.

(In reply to Chris Karlof [:ckarlof] from comment #10) > > Proposal for fix: for passwords stored in the password manager, allow JS to read back > > only dummy values until the onsubmit event fires. > > Some sites don't use a <form> element for logins. Check out > http://www.hulu.com/ That's pretty darn batshit IMNSHO, but heuristics along the lines of the pop-up blocker should be possible. The principle to enforce is that *once the user takes a positive action to log in*, the site is entitled to know their user credentials -- but as long as they haven't, it isn't. So we ought to be able to partition the set of all event handlers into "gets to see the real username and password" vs. "doesn't get to see the real username and password" by analyzing what user actions can trigger them (in the abstract, not for specific pages) and whether those actions qualify as "taking a positive action to log in". > We should be making the password manager work with more sites, not fewer. I don't disagree with that, but I think we shouldn't just give up on not-logged-in privacy leaks because of it.

Some Web site (e.g., Slashdot at <http://slashdot.org/?nobeta=1>) use JavaScript to handle their logins.

(In reply to David E. Ross from comment #12) > Some Web site (e.g., Slashdot at <http://slashdot.org/?nobeta=1>) use > JavaScript to handle their logins. Yes, that's why (contra comment #7) we make sure to make the real data available to 'onsubmit' and related event handlers.

I would like to bring this bug back into the foreground, since it is labelled as "new", and this browser exploit was used to steal numerous user passwords from www.facepunch.com (which was breached via an unrelated exploit). I will also be hunting down Google's preferred method of bug reporting (whatever that is), since Chrome was also affected by this exploit. I'm not certain precisely how close to "fixed" this browser exploit is, but it's still marked as "new" so I'm going to request action be taken ASAP.

(In reply to Nicholas O'Connor from comment #14) > I would like to bring this bug back into the foreground, since it is > labelled as "new", and this browser exploit was used to steal numerous user > passwords from www.facepunch.com (which was breached via an unrelated > exploit). Can you provide more details on this attack, or perhaps a link to an article.

(In reply to Tanvi Vyas [:tanvi] from comment #15) > (In reply to Nicholas O'Connor from comment #14) > > I would like to bring this bug back into the foreground, since it is > > labelled as "new", and this browser exploit was used to steal numerous user > > passwords from www.facepunch.com (which was breached via an unrelated > > exploit). > > Can you provide more details on this attack, or perhaps a link to an article. (Sorry I'm late) Some of the finer details have escaped me due to my own poor memory, but here's the gist: 1. A moderator's account was compromised due to an unrelated attack. 2. This attacker exploited an XSS vulnerability in the site, executing unwanted JavaScript on all its users. 3. *(The part that's relevant to the browser begins here)* The JavaScript embedded a login page into the site in a way that's hidden to the user, but visible to autofill (I believe an iframe was used, but again, not certain). 4. Once autofill kicked in, the attacker reads the username and password from the autofilled login fields, and sends them to Gods-know-where. In practice, I believe Firefox users might have been safer in this one particular attack, since the login form on the site has incorrectly configured placeholder values that confuse autofill (Username: "Password" Password: "actual_password_here"), but we, for obvious reasons, shouldn't count on that being a factor next time :V If more detail is needed, I might be able to go ask a moderator to come over and fill in my many, many blanks, but I think that's enough to identify the issue: this attack was possible because browsers (which I believe may include Firefox) allow JavaScript to read the autofilled values. I've since disabled the password manager functionality, and will be recommending others do the same for the time being until this is fixed (or it becomes apparent to me that this kind of attack is incredibly infrequent, whichever comes first)

Thanks for these details Nicholas! (In reply to Nicholas O'Connor from comment #16) > In practice, I believe Firefox users might have been safer in this one > particular attack, since the login form on the site has incorrectly > configured placeholder values that confuse autofill (Username: "Password" > Password: "actual_password_here"), but we, for obvious reasons, shouldn't > count on that being a factor next time :V > What do you mean by this? The attack probably didn't work for Firefox users? Couldn't the attacker just inject the right number and type of fields to get Firefox' password manager to work? (i.e. one regular input field followed by another input type=password?) Or do you mean that Firefox' password manager doesn't save passwords for facepunch.com because it doesn't support their login form? I tried testing this and it doesn't look like Password Manager autofill works on facepunch.com. You can autocomplete the password field after selecting the username, but that requires user interaction.