<span id="7ztzv"></span>
<sub id="7ztzv"></sub>


<span id="7ztzv"></span><form id="7ztzv"></form>


<span id="7ztzv"></span>
    

      

        <address id="7ztzv"></address>
            

            XSS Hack：獲取瀏覽器記住的明文密碼
            

            
余弦（@evilcos）
evilcos@gmail.com
[AT]knownsec team
[AT]xeye team


0x01. XSS獲取明文密碼的多種方式

我已經感受到Web潮流帶來的巨大革新，尤其是最近HTML5越來越火。瀏覽器們在客戶端瓜分
著這個Web OS，只要是對用戶體驗好的功能，瀏覽器之間就會互相學習，然后去實現，但是
實現總是存在一些差異，有些差異是用戶體驗上的，有些則可能帶來安全問題。
這篇文章是想深入描述下瀏覽器記住用戶密碼這種機制帶來的安全問題與實現上的一些差異
性。黑客們如何通過技巧獲取到瀏覽器保存的密碼，明文。

先回到XSS本身上，XSS獲取明文密碼的方式有哪些？
1.	通過DHTML釣魚方式
比如document.write出一個登陸頁面，或一個登錄框。也就是目標網站的登錄方式是怎樣
的，就通過DOM模擬出怎樣的。用戶很難區分同域內的釣魚，如果再次輸入密碼登錄時就悲劇
了。
2.	通過JavaScript hook住密碼框
滿足某個事件（如onsubmit/onblur/onchange等）就記錄之。
3.	通過JavaScript實現鍵盤記錄器的功能
監聽用戶在表單里的擊鍵事件，記錄擊鍵的值，有時候這個效果會非常不錯。

上面這三個方法都是大家在用的，效果各有千秋，這次我要提一種新的方式：通過利用瀏覽
器保存密碼這個機制來達到獲取明文密碼的目的，效果顯得更加直接。

0x02. 瀏覽器記住密碼的機制

	現在回到瀏覽器的這個機制上，最早是哪個瀏覽器實現的，我懶得去考證了，可能是
IE。在用戶登錄的時候，瀏覽器會提示保存密碼，可以在下面這個地址在線查看我測試的8個
瀏覽器截圖：
http://evilcos.me/lab/xss_pwd/
	注：這也是本文的demo地址，測試的瀏覽器有：
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)
	
保存密碼是為了提高用戶體驗，省去了每次登錄需要輸密碼的麻煩，在這個機制之前經常是
通過身份認證的本地Cookie來實現的，也許是因為并不是所有網站都采用持久化Cookie，瀏
覽器才開始選擇了這樣的方式。而且現代瀏覽器大多有一個機制：云同步，除了書簽、個人
偏好外，還可以同步瀏覽器記住的密碼，使得用戶在任意地方都可以同步自己的“習慣”。
有的身份認證Cookie是綁定IP的，這樣的話同步Cookie就不好使了。簡而言之吧，密碼這東
西就是方便，可也太濫用了，濫用有風險，而且還來了個云同步，黑客興奮了。
	在瀏覽器記住密碼機制之前大家應該都知道還有一個很火熱的機制：表單自動填充！曾
經出現的安全風險是：由于這個自動填充的值是跨域共享的，攻擊者可以在自己的域放一個
頁面，用戶的瀏覽器訪問后，會自動填充這個頁面的表單（比如Email、家庭地址、手機號等
等，如果用戶的瀏覽器記住過這些值的話），然后這個頁面的JavaScript就可以獲取到這些
值了。這些值還好，攻擊者并不一定很喜歡，可是明文密碼就不一樣了。

記住密碼機制需要遵循同源策略，但是如果有XSS就可以忽略這個同源策略，注入
JavaScript去得到這個明文密碼:P	
下面我以Chrome為例深入說明說明，攻擊者通過這個機制是如何得到你的明文密碼的。
Opera與IE的機制相對來說是最安全的，而搜狗瀏覽器在這方面的安全性最差。

0x03. 獲得Chrome記住的密碼

先來看Chrome，demo地址：http://evilcos.me/lab/xss_pwd/。可以輸入admin/1234567，然
后LOGIN試試。瀏覽器彈出保存密碼提示時，選擇保存。重新載入這個demo地址，可以看到瀏
覽器已經自動填充了密碼。點擊按鈕“see ur pwd”會彈出你輸入的密碼明文。
實際上你查看頁面源代碼是看不到密碼的，這個密碼是瀏覽器判斷頁面加載后，發現表單中
有密碼項，就自動填充最近一次記錄的用戶名與密碼，就像（或者說就是）一次DOM操作，動
態填充。既然是DOM操作，那么在這之后我們控制JavaScript也來一次DOM操作，這次是讀，
將密碼項里的value值讀出來，是不是就得到了明文密碼？對……是這樣！
知道這個過程后，邪惡的想法誕生了……
這個機制遵循同源策略，那么如果在一個域內，任意頁面存在XSS，就應該可以通過DOM動態
創建一個包含一模一樣的用戶名與密碼表單項的表單出來，然后等待瀏覽器自動填充密碼
后，再通過DOM操縱得到密碼項里的值。
開始實驗！
這個頁面http://evilcos.me/lab/xss_pwd/的表單是這樣：
<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>
瀏覽器是如何記住這個表單的，以確保唯一性？有幾個關鍵值（不同瀏覽器有差異，不過影
響不大）：
1.	為了遵循同源策略，需要域名：evilcos.me
2.	需要一個<form>標簽
3.	需要id或name為username的用戶名<input>表單項
4.	需要id或name為password的密碼<input>表單項
如果是這樣，攻擊者發現同域內XSS后，就要開始構造一段payload，這個payload用于自動創
建出這樣的表單，這個表單瀏覽器要能夠認識（認為是之前記住密碼的那個表單:P），并且
必須在瀏覽器開始自動填充密碼之前出來（否則得不到填充值），最后必須在瀏覽器填充完
密碼后開始獲取表單項的值（否則獲取到的值是空的）。
	條件好像很苛刻，哪個步驟時間把握不好，攻擊就失敗了。針對這個場景我構造了一個
payload，如下：
function create_form(user) { /*獲取明文密碼*/
	var f = document.createElement("form");
	document.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); // 時間競爭
}

create_form('');

也可以查看http://evilcos.me/lab/xss_pwd/xssme.html的代碼，create_form函數的執行優
先于整個document文檔的完全解析，這時會自動創建一個登錄表單（和之前記住密碼的表單
關鍵部分是一樣的，這就足夠了），然后等待3000毫秒，待整個document文檔解析結束（此
時瀏覽器已經完成了密碼填充），最后獲取密碼表單項里的值，成功！
3000毫秒不靠譜就來個for循環直到獲取到密碼值才退出。

0x04. 插一個題外點：時間競爭

這個話題很大，就是誰先誰后的問題，不僅和瀏覽器解析處理整個DOM樹的順序有關系，也和
我們要達到的目的有關，比如瀏覽器解析順序的一個經典例子：
<script src='http://remote/x.js'></script>
<body></body>
是先解析完遠程的js腳本，還是先解析<body>標簽？
如果這樣呢？
<script id='rfi'></script>
<script>
document.getElementById('rfi').src = 'http://remote/x.js';
</script>
<body></body>
我們最好對“時間競爭”心里有數，搞清楚瀏覽器解析的機制，這樣我們的payload才能達到
我們的目的。

0x05. 各瀏覽器的差異

我已經習慣差異了，而且喜歡差異，因為這樣很可能會帶來一些安全問題，不過前端工程師
們就不喜歡了:&，下面我只講關鍵的差異，那些小的，大家自己試驗，自己發現。

1.	Safari瀏覽器
只有Safari默認是關閉這個機制的。如果開啟后，效果和chrome一樣，非常好用！
2.	Opera瀏覽器
Opera好像很安全，記住密碼后，瀏覽器并不會自動填充密碼，而是要用戶自己點擊地址欄左
邊的鑰匙圖標，才會開始填充并登錄。
3.	IE8/9瀏覽器
IE8/9及部分這個內核的瀏覽器（比如遨游的IE模式）很聰明，將每個登錄表單綁定到所在的
頁面上（下面簡稱這個頁面為綁定頁面），由于綁定頁面地址是唯一的，同域內其他頁面就
無法通過生成一個一模一樣的表單來獲取密碼了。
如果就這樣還是不安全:P，因為XSS可以動態iframe進這個綁定頁面，然后注入JS進行任意
DOM操作，同樣非常容易獲取到密碼表單項的值，IE估計是考慮到了這個，通過iframe調用綁
定頁面也無效。而且IE的機制還遠沒這樣簡單，即使在綁定頁面內我也沒成功得到密碼，因
為IE默認并不填充密碼，只有輸入正確用戶名后，并觸發類似onblur事件，這個密碼表單項
才會填充進對應用戶名的密碼。這個過程我本想通過DOM來模擬進行的，但是沒有成功。感興
趣的同學可以試試。
4.	其他瀏覽器
其他瀏覽器（除了搜狗瀏覽器）都和Chrome差不多了，大多是因為webkit內核。下面單獨說
說搜狗瀏覽器吧。

0x06. 搜狗瀏覽器“記住密碼機制”的安全缺陷

搜狗瀏覽器在實現這個機制估計是下了一些苦工了，雙核模式下都很好兼容，不過安全方面
的實現存在一些問題，并沒嚴格遵循同源策略。在我的測試中發現，搜狗沒區分好不同端口
及不同子域的同源問題。
比如在www.foo.com域下記住的密碼，在a.foo.com與www.foo.com:8080域中都可以讀取到。
還有一個有意思的，我們的payload甚至僅創建一個password表單項（<form>都可以不需要）
就可以得到明文密碼。看來搜狗瀏覽器在實現這個機制有偷工減料的嫌疑啊，用戶體驗雖然
不錯。

0x07. 如何防御

	從三個方面進行：瀏覽器、網站、用戶。
1.	瀏覽器防御
IE的機制相對來說很不錯了，其他瀏覽器可以借鑒，雖然這樣會影響一些用戶體驗，我想為
了更安全也值得了吧，需要特別注意的，IE這個機制有好幾個關鍵點，不要到時候依葫蘆畫
瓢，學不好讓人笑了:P
2.	網站防御
通常給表單的<form>標簽設置autocomplete="off"即可，不過不是所有瀏覽器都兼容，我發
現搜狗與遨游瀏覽器不買這個帳。或者不要<form>標簽了，通過JS自提交登錄。新浪微博采
用了這兩種方式，其他網站可以學學。
3.	用戶防御
意識為先吧，瀏覽器記住你的密碼需謹慎，沒必要的就不用記了。

0x08. 總結

	到這還沒結束，大家可以試試給表單多增加一個項或者少一個項，不同瀏覽器還是存在
很多差異，這個大家自己找吧。
	這個安全問題我很早就發現，也公開過，不過沒引起足夠重視:P，如果一個SNS類的網站
中傳播XSS蠕蟲，帶上這樣的payload，不知道能獲取多少明文密碼……或者在定點滲透過程
中，如郵箱XSS滲透，帶上這樣的payload，一定概率說不定可以拿到明文密碼。怎么個危
害，就看怎么個場景，怎么個利用。
最后，這篇文章的各種知識點也都會出現在我的書中（定位Web前端攻防），還沒寫完，還在
繼續，這里算是打個小廣告了。也希望大家關注xeye即將上線的網站，更多分享會繼續！祝
各位新春快樂了:D

-EOF-

            



            <span id="7ztzv"></span>
            <sub id="7ztzv"></sub>
            

            <span id="7ztzv"></span><form id="7ztzv"></form>
            

            <span id="7ztzv"></span>
              

                

                  <address id="7ztzv"></address>
                      

亚洲欧美在线