XSS (Cross Site Scripting) would be viewed by most web developers as the stealing of users session cookies by injecting JavaScript into a web page through URL. You do not associate it with stealing passwords, but worse then stealing session cookies, it can steal a users username and password directly from the browser.
Many users choose to have the browser remember their login credentials. So when ever they visit a login form, their username and password fields are pre-populated by the browser. Now if there is an XSS vulnerability on that login page, then a remote attacker can successfully retrieve the users username and password.
Hello World in XSS
You have a page that has an XSS vulnerability. Let say a website has a PHP page, mypage.php with the code:
<?php // the variable is returned raw to the browser echo $_GET['name']; ?>Because the variable
$_GET['name'] is not encoded into HTML entities, or stripped of HTML, it has an XSS vulnerability. Now all an attacker has to do is create a URL that a victim will click, that exploits the vulnerability.
mypage.php?name=%3Cscript%3Ealert(document.cookie);%3C/script%3EThis basically will make PHP write
<script>alert(document.cookie);</script> onto the page, which displays a modal dialog with the value of the saved cookies for that domain.
How Does stealing passwords with XSS work?
The example above displays the cookies on the domain the webpage is on. Now imagine the same page has a login form, and the user chose to have their passwords remembered by the browser. Lets say the PHP page looks like this:
<?php // the variable is returned raw to the browser echo $_GET['name']; ?> <form action="login.php"> <input type="text" name="username" /> <input type="password" name="password" /> <input type="submit" value="Login" /> </form>Now an attacker just needs to craft a URL that retrieves the username and password. Here is an example that retrieves the password:
mypage.php?name=%3Cscript%3Ewindow.onload=function(){alert(document.forms[0].password);}%3C/script%3E
As you can see, it is just a normal XSS exploit, except it is applied to the username and password populated by the browser after the window.onload event.
Password stealing XSS vs Session Cookie stealing XSS
Well, they are both suck from a developers perspective. According to Wikipedia, 70% or so of websites are vulnerable to XSS attacks.
As a developer, I've always thought of XSS as an exploit on a users session, just as CSRF/XSRF (Cross Site Request Forgery), which requires an active session. Now, as you can see, XSS of the type described does NOT require an active session. The user does not have to be logged into the site. They could have logged out 10 years ago, but as long as the browser remembers their login credentials, the XSS exploit can steal those login credentials.
Due to its ability to be executed without having the user logged into a website, this exploit should be regarded worse then session based XSS.
Proof of Concept
Fill in the form below with dummy values and click the "Login" button.
Now return to the same page, to simulate logging out. Now click the Exploit. This will simulate an XSS exploit on this page, and alert the saved password.
I've set up a proof of concept based on an actual XSS exploit here: http://xss-password.appjet.net/.
Preventing Stealing Passwords via XSS
The only way I can think of right now is to give your username and password fields unique names so that the browser does not remember their values. In PHP you can do this with the time() function. eg:
<input type="password" name="pass[<?php echo sha1(time().rand().'secret'); ?>]" />The unique names prevents the browser from remembering the password field. This should work universally in all browsers.
