This has been used in the wild in XSS payloads for years now.
For eg. check this presentation from Stratsec at EUSecWest '09[0] specifically slide 35 which talks about exploiting password managers.
see 'Abusing Password Managers with XSS' from Neohapsis[1]
also the Beef project has a module called Get Stored Credentials[2]
The reason it was only one slide in the presentation and so little else has been written about it? First, because it is obvious - when learning XSS after cookies and sessions the next thing most devs go at is the password manager.
And second, it just isn't as interesting when you have so much more you can do with XSS, and tampering with password managers is a narrow vector.
Auto-complete is completely irrelevant - you can listen in on the form submit action and you can steal session cookies without having auto-complete so there is little benefit.
However, there is another attack involving auto-complete that is less well known and more concerning. You can hide text input fields with CSS with names such as "address", "phonenumber", etc, and when a user goes to auto-complete their email address - it fills in all of their private info that they might not want that website to have.
I think the point is that using saved passwords means you don't have to catch the user when logging in, you can grab the password at any time. (Assuming an XSS attack exists of course.)
Same goes for session cookies and the 'good thing' about session cookies is that an XSS attack should work anywhere on the domain, rather than just the login page (assuming it's not a website with a login form on each page).
I don't see how this is a security hole, unless the website gets hacked in another way. Every time you sign up for an account the website could save your password in plaintext which they could view later. Same thing for signing in, a website could just save the submitted password.
If for some reason my logic is flawed, then a lot of information would have to be denied, essentially and operation on a password input. You'd have to disable and .type, .val, and probably a couple of others on password fields.
Most websites include a host of javascript from other sites, like Google Analytics, Like-Buttons, Ads, and so on. If they all can get to the password it seems like an issue to me.
Personally I am surprised by this. Afaik you can not copy+paste the password from a password form field, so I just somehow assumed you couldn't get to it via JavaScript, either.
If a script wants to gain access to the prefilled stuff it has to come from the website creator unless the website is hacked with sql injection or something like that, which still has the same problem- if they really want your password, on signin the website can just get the password value of the form and save it somewhere,.
The suggestion that you should forbid access to the prefilled password from JavaScript just doesn't work and will break many websites. If the form is submitted in the regular way, it will typically work, but any sort of background logging in or AJAX form submission will then fail.
And what's so special about what you've saved? XSS is a security hole and so once a script is injected it doesn't really matter whether it's the prefilled password or a password that gets typed in - it's just perhaps slightly more likely to be there. (But then, I wouldn't think people are in the habit of leaving a filled in login form as it is - I at least would be likely to compulsively submit it and log in.)
It doesn't really matter. Once hacker was able to put his JS on your page, one way or another it will be possible to pull password from password field, auto-completed, or human-entered.
I alos use Opera. I'd wondered why its password management was designed differently from the stuff in other browsers, and I guess this might be why.
But the approach depends on the browser software to figure out which button on the page is the login button, rather than relying on the user to figure it out. I've run into one or two websites where Opera got that wrong, meaning the password manager couldn't work.
Basically Opera doesn't auto-complete unless you click a specific button once the page loads. Then Opera will not only auto complete the password form, but submit it as well.
Yes, and I've actually used that to extract my own password that I've forgotten. Opera's implementation coincidentally stops this specific attack, but it's not in any way a security mechanism.
An attacker could already simply redirect the form or post silently via XHR to gather the password, even if you didn't save your password before. This is not very useful.
The way is the same: getting rogue JS to run on your page. If the attacker gets that, it doesn't really matter how many ways they have to copy the password.
This has nothing to do with pre-filled passwords. Type any text in and click the link in the demo (without POSTing or having the browser save) and it pulls the text out. XSS works on what the field is populated with, whether typed by the user or pre-filled by the browser.
I think you need to update your post with the clarification that you don't have to add XSS directly to the login page - you can steal user's password from whatever page the user are currently in, even if they are already logged in.
Too glib. In security, you want defense in depth, because what you thought was your perfect perimeter never is. It is fair to discuss whether or not there is anything a browser can do to mitigate this, even in the face of a security violation. Hence things like domain policies on AJAX use... in theory they are never necessary because everybody's perfectly secure, right?
I suspect that other's analysis that the proposed solution is impossible is correct, and JS needs access to the prefilled in password for a lot of auth to work. But it's a valid discussion, and is not rendered moot by simply observing that another security violation has already occurred.
What I think might be interesting hack against it - to have browser to fill incorrect information. This way it might prevent script from grabbing correct login/password, unless hacker do it right and send password on each onkeyup event :)
I tried to get the saved values of the input type=text tags without xss. It's a pretty messy method and doesn't work very well. http://j.mp/YbLvuK Any ideas?
I am happy I don't store any passwords anymore in the browser or even in my computer. All of them (200+) was moved to LastPass. One of the best decisions I have ever made.
>His suggested fix will break work for sites that use AJAX on the login forms.
I forgot about AJAX, I was wrong.
>It is however an interesting vector as it will steal the password without any user interaction or knowledge.
I am trying to say it here.
one of the main reasons, that someone could find XSS on your website.
Afterwards, he needs just to open an iframe and you may get your password in a plan-text.
For eg. check this presentation from Stratsec at EUSecWest '09[0] specifically slide 35 which talks about exploiting password managers.
see 'Abusing Password Managers with XSS' from Neohapsis[1]
also the Beef project has a module called Get Stored Credentials[2]
The reason it was only one slide in the presentation and so little else has been written about it? First, because it is obvious - when learning XSS after cookies and sessions the next thing most devs go at is the password manager.
And second, it just isn't as interesting when you have so much more you can do with XSS, and tampering with password managers is a narrow vector.
[0] http://www.stratsec.net/getattachment/09ce9a5a-07d2-41ca-843...
[1] http://labs.neohapsis.com/2012/04/25/abusing-password-manage...
[2] http://beefproject.com/