User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041223 Firefox/1.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041223 Firefox/1.0 (I need to upload a testcase first - I have one but I want to test it here on bugzilla) Reproducible: Always

OK it does. This is a really big bug, which is caused by having firefox fill in passwords on every form on a subdomain. The testcase will get your bugzilla password if it was remembered (and it might simply hide the form and submit it to a webpage, too!) because its also on bugzilla.mozilla.org. Imagine someone uploading an attachment like this on some forum, or maybe with some webmail providers!

note that the bugzilla team is already aware of this problem. given that you filed this bug about firefox and that as is, it did not affect my seamonkey browser, i'm not going to cc any bugzilla devs.

Timeless: it definitely works against the Suite, too. *** This bug has been marked as a duplicate of 38862 ***

What is the status of bug #38862?

arg. well, it would seem it doesn't work if you don't have mozilla set to remember your password :) reporter: were you complaining about firefox or bugzilla? the bug dveditz picked is a bug about bugzilla and its status is that it's open. if you were trying to file a bug against the bugzilla product, then you really failed to file it in the right product.

It is a bug against the Firefox product, the testcase relates to bugzilla as it only works on the same domain as where the password was remembered for. Again: what was the status of bug #38862? I do not have enough permissions to view it.

reopening. the reporter clearly is filing this bug against firefox. the bug in question is a bug against bugzilla.

As I stated before, this bug can work for theoretically every site, especially sites everyone can upload files to (forums, bugzilla, webmail services). One could create an attachment for phpbb (which uses username/password as names for the respective form input fields) to simply postback the password to their own site. Javascript can automate this, but this isn't needed: for example they could create an image button with a small image and tell the user to click it to enlarge the image (but in fact it will post back the password which was autofilled in some hidden boxes).

Short of turning off the password manager entirely (which the user can do), or the user not saving passwords for sites that display user-entered content, do you have any suggestions? The only thing that comes to mind is replaying the password only for the specific URL from which it was captured. Or perhaps if the path doesn't match then treat it as the multiple login case and make the user choose first.

A few suggestions: * Save the password per-page and not for the whole domain. The password can only be captured by hacking the original page then, but that's not an issue. * Ask for user interaction to fill in a password (confirmation, clicking a button, filling in the first letter of the username.

Of course a temporary workaround is disabling the password manager.

Another method to exploit this is using the 'write contents of the string on the site' method, like http://www.somesite.com/error.php?error=<h1>404</h1>. By then putting a simple javascript in the querystring, the password of a user can be retrieved.

Making password manager per-URL rather than per-(protocol,host,port) would not prevent XSS holes such as the ones mentioned in comment 2 and comment 13 from being used to steal passwords stored with password manager. The attacker would just have to open the URL of the login form in a frame and then get the password from the frame. Wontfix, dup of bug 38862, or dup of bug 263387. But it should probably stay security-sensitive until bug 38862 is fixed.

Hmm true. Then the only solution to treat all forms like multi-username forms or having the user click a button/confirmation.

> As I stated before, this bug can work for theoretically every site, especially > sites everyone can upload files to (forums, bugzilla, webmail services). Most webmail services avoid having this kind of hole by keeping attachments at a different hostname or by scrubbing HTML attachments. > Another method to exploit this is using the 'write contents of the string on the > site' method, like http://www.somesite.com/error.php?error=<h1>404</h1>. It is true that many sites have holes like this, but I don't think a change to password manager (like in bug 263387) is the correct solution. There are several other ideas for solutions in this bug, which could turn into new bugs blocking bug 301375. I'd prefer for that discussion to not take place in this bug, because this bug discusses a security hole in Bugzilla that is still hidden.