408531 - password manager + XSS = disaster

Status: RESOLVED DUPLICATE of bug 359675

(Toolkit :: Password Manager, defect)

Description

[georgi - hopefully not receiving bugspam]

Attachment: passwd2.html - reading saved passwords and usernames from b.m.o

if password manager remembers a password for a site and if there is a xss hole in site, username & password can easily be stolen.

b.m.o is nice example, because it servers arbitrary html, so it is possible to steal saved b.m.o passwords.

just make a form with the same fields as the original one and read it with js.

this may be a bugzilla bug, so change product if needed.

testcase reading saved b.m.o passwords attached.

Comment 1

[Justin Dolske [:Dolske]]

I'm fairly certain there's a bug about this as a general Bugzilla problem, but I don't think I have access to it.

Bug 360493 made this a little more difficult (by checking the action URL), but if you can inject arbitrary JS into the page it's basically already game over, password manager or not... The script could just poll the user/pass fields for value changes, or install an onsubmit handler. Even if the user types their password manually, you'd have it.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

The bugzilla bug is bug 38862. Justin's right - once you've succeeded in finding an XSS vulnerability, whether or not the password manager is involved doesn't make much of a difference.

Comment 3

[georgi - hopefully not receiving bugspam]

(In reply to comment #2)
> whether or not the password manager is involved
> doesn't make much of a difference.
> 

it makes a difference.
with autofilled password, the password is stolen silently without user interaction. and the password is more valuable than a simple cookie.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

As Justin pointed out in comment 1, there are ways to steal passwords silently without the password manager being involved.

Comment 5

[georgi - hopefully not receiving bugspam]

if the password is typed - yes. otherwise how do you steal the password without being typed and without password manager?

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #5)
> if the password is typed - yes. otherwise how do you steal the password without
> being typed and without password manager?

If the password manager doesn't auto-fill, and the password isn't typed in, what's left? Some people have proposed the "wand" UI, like in Opera, or a notification bar button, in the bug this one's duped to. Those still wouldn't help much - as soon as the password is entered the script running on the page can see it, no matter how many hoops the user's had to jump through to get it there.

Comment 7

[Daniel Veditz [:dveditz]]

The argument from comment 3 onward is pointless. Yes, XSS is a problem in its own right, and yes, password autofill makes it worse. This has already been duped to a bug that makes that case.

[Gavin: you're missing the point in comment 6. The user never knowingly has to visit the site to have their password stolen with an XSS hole. If they visit a malicious or compromised site it can use the CSS-history trick to scope out likely victims and then steal the password of the target site in a hidden frame. A "wand"-using user, or even a "click to fill-in" one, would be safe from this kind of attack.]

Comment 8

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #7)
> [Gavin: you're missing the point in comment 6. The user never knowingly has to
> visit the site to have their password stolen with an XSS hole. If they visit a
> malicious or compromised site it can use the CSS-history trick to scope out
> likely victims and then steal the password of the target site in a hidden
> frame. A "wand"-using user, or even a "click to fill-in" one, would be safe
> from this kind of attack.]

I'm not missing the point - I don't think that the difference in likelihood of password-stealing success between "hidden iframe that pwmgr autofills" and "visible rewritten log-in page where user enters password (using a wand or otherwise)" is great enough to merit the potential usability hit of fixing only the former.

Comment 9

[Daniel Veditz [:dveditz]]

From the standpoint of "I want to steal your GMail account" it might only be a little harder to essentially phish the user into entering the password on a visible form. In contrast the hidden frame attack enables wholesale theft of every interesting password you have at once given the presence of known XSS holes on those sites, and the current belief is that somewhere around 80% of all significant sites have an XSS hole.

I guess this argument belongs in the other bug...

Comment 10

[georgi - hopefully not receiving bugspam]

completely agree with comment 9

Comment 11

[georgi - hopefully not receiving bugspam]

Bug 412437 basically means that if there is a saved doctor.mozilla.org password then defacement of m.o may be possible

Comment 13

[Bartłomiej Brzozowiec (BartZilla)]

(In reply to comment #11)
> Bug 412437 basically means that if there is a saved doctor.mozilla.org password (...)
 
Is there any reason why is this bug (RESOLVED FIXED) still inaccessible?

Comment 14

[Reed Loden [:reed]]

(In reply to comment #13)
> Is there any reason why is this bug (RESOLVED FIXED) still inaccessible?

No reason. I've just unhidden it, as the issue it discusses has been mitigated.

Comment 15

[RH]

(In reply to comment #1)
> I'm fairly certain there's a bug about this as a general Bugzilla problem, but
> I don't think I have access to it.
> 
> Bug 360493 made this a little more difficult (by checking the action URL), but
> if you can inject arbitrary JS into the page it's basically already game over,
> password manager or not... The script could just poll the user/pass fields for
> value changes, or install an onsubmit handler. Even if the user types their
> password manually, you'd have it.

I just wanted to add something. If you want to read out a password with such an onchange or onsubmit handler you also need a XSS hole on the login page of course, which doesn't apply for most pages.

For example there is a widespread board software which allows an attacker to use javascript in a html posting. On the login screen you can't see the content of postings - only the names of the board sections which can't get infected by javascript like that. The old "document.cookie" trick doesn't work as well btw.
All sensitive functions that would allow to add XSS into the descriptions of the board section or into the language package (which would execute javascript on the login page) are only accessable via a separated admin control panel which is secured.

The attacker would have very limited possibilities with his javascript in that posting now, but he can be happy that not everybody is using the IE and that Firefox automatically inserts saved passwords on default into every password field. He waits for a BoardAdmin to visit his XSS infected posting and reads out the password with implementing a own hidden password field into his posting.
Then he uses the password to login into the admin control panel and injects the next javascripts into the language package which gets executed on the login page as well. Now we arrived at the "game over" (with the help of firefox).

There are tons of other examples. The automatical insertion of passwords is dangerous and a big risk.

Do it like the IE and simply wait for a click of the user to insert the password.