[Please do not remove the security flag]

The testcase requires that the browser is configured to enter Bugzilla username and password automatically w/o user interaction. The onload piece doesn't work (autocomplete kicks in later than I thought). The [Click to steal] button works though.

gerv, do you think we should post news like this on mozillanews.org?

"The best way to avoid password theft is to disable log-in automcomplete on Bugzilla." This is easily defeatable. First, if we're saving passwords already, adding autocomplete="off" to the login box won't do anything. Once a password is saved, autocomplete is ineffective. It only prevents PWM from prompting to save, it does not prevent a form from being filled in. Second, there is a bookmarklet to disable autocomplete, which allows PWM to prompt to save a password, like on Yahoo.com's logins. We should further investigate this before we publish anything anywhere. As I think back, I think this is most likely a dupe of an almost ancient method to steal passwords...

This is bug 38862 (dupe). This is preventable in Bugzilla through technical means on the server side. Bug 38862 is the bug to make Bugzilla do that prevention. *** This bug has been marked as a duplicate of 38862 ***

Indeed. Daniel: please don't post news of this on MozillaZine/News or anywhere else. There's no point telling the world about it until there's something we can do to fix it for them. Yes, this has taken a long time, and that's not ideal, but it's still best to keep quiet. Gerv

> There's no point telling the world about it until there's something we can > do to fix it for them. I already know this bug is a dupe. I only filed this bug just to ask if we should issue a warning to Bugzilla users. This vulnerability is so easy to find it's almost a dead give-away, and I think many QAs deserve to know how to prevent this as they have to deal with attached testcases all the time.

But as jesus_x points out, there's no way to prevent this. We can't clear the browser's autocomplete cache. And, even if we could, people can still steal your authentication information from your cookies. In addition, many testers may want to put up with the risk, in order to have the convenience of not having to enter their password all the time. After all, if all you've got is canconfirm and editbugs, who would want to take over your account? Gerv

btw, disabling the following via CAP provides some security: HTMLInputElement.click HTMLInputElement.value.get HTMLFormElement.submit HTMLFormElement.action.set TextAreaElement.value.get HTMLDocument.cookie this doesn't prevent good social engineering, though. (and btw, I'm still foolish enough to have autocomplete on, lol)

removing the "do not remove" from the whiteboard doesn't yet mean it can be removed, just fixing the summary so I can tell which bug this goes with so I remember to unsecure it when I unsecure the bug it's duped to.

This bug is being removed from the security group because the bug that it is a duplicate of is now public, since it has been fixed and a Security Advisory has been sent about it. See bug 468249 for the Security Advisory.