作為一個會每天訪問Freebuf網(wǎng)站的人，或者說是一個對信息安全感興趣的人，肯定會知道一位用戶所有的網(wǎng)絡(luò)賬號不應(yīng)該都使用相同的密碼，這也是一個最基本的安全常識。可是那然后呢？

　　前言

那么為了讓每一個賬號都能擁有一個健壯的密碼，你可能就需要用到密碼管理器了。也許當(dāng)你第一次使用密碼管理器的時候，你心里會有些忐忑不安，畢竟你將所有的密碼都放在了這一個地方，而你又可以跨設(shè)備跨平臺地通過云端來同步自己的密碼，這種便捷性肯定會讓每一個用戶對密碼管理器的安全產(chǎn)生質(zhì)疑。

悲劇的是，你的質(zhì)疑是對的。在這篇標題為《密碼管理器：攻擊與防御》【點我下載】的論文中，作者David Silver告訴了我們很多密碼管理器中都存在嚴重的安全漏洞，而這些漏洞與密碼自動填寫有著密切的聯(lián)系。雖然這是一篇發(fā)表于2014年的論文，其中描述的很多攻擊向量可能已經(jīng)失效了，但是本文是我研讀完這篇論文之后所得到的啟發(fā)，也許我的這些觀點和看法可以給大家?guī)砗芏囔`感，而且我認為這些攻擊方法的變種版本目前仍然是有效的。

簡而言之，請各位不要再使用表單自動填寫功能了！了！了！重要的事情說三遍…

坐在咖啡店角落里的黑客

這種攻擊者可以主動發(fā)動中間人攻擊，即攔截并修改目標網(wǎng)絡(luò)中通信雙方的任意網(wǎng)絡(luò)流量數(shù)據(jù)。但是在這種攻擊場景中，用戶并不需要明確地訪問或登錄任何一個頁面，攻擊者仍然可以竊取用戶的登錄憑證。

比如說，攻擊者只需要在某家咖啡店建立一個偽造的WiFi熱點，當(dāng)你連接至該熱點之后，你的密碼就全部到攻擊者的手中了。這種攻擊方法非常簡單，攻擊者只需要一個臨時的網(wǎng)絡(luò)路由器就可以發(fā)動攻擊，而且這種情況在現(xiàn)實場景中也會經(jīng)常發(fā)生。在大多數(shù)情況下，用戶根本無需與釣魚網(wǎng)站進行任何交互，攻擊者可以在用戶毫不知情的情況下竊取所有的密碼。

Sweep攻擊

基本上，任何支持密碼表單自動填寫的密碼管理器都無法抵御Sweep攻擊。當(dāng)目標用戶連接到了一個由攻擊者控制的流氓WiFi熱點之后，攻擊就悄悄發(fā)生了…

當(dāng)用戶啟動瀏覽器之后，瀏覽器會被重定向至一個標準的熱點登錄頁面，并詢問用戶是否同意WiFi使用條款。對于公共WiFi熱點來說，這種情況很常見，而且絕大多數(shù)用戶都會選擇同意。但是用戶可能壓根就不知道這個頁面中存在不可見的HTML元素，而這個隱藏元素已經(jīng)完成了所有的攻擊。

換句話說，當(dāng)你正在閱讀這個已經(jīng)加載完成了的WiFi登錄頁面時，你絕大多數(shù)的登錄憑證早就已經(jīng)“不翼而飛”了。在測試環(huán)境下，我們每秒鐘大約可以從目標設(shè)備中提取出十個密碼。

以下是三種Sweep攻擊者在登錄頁面中最常用的密碼竊取技術(shù)：

1. 在頁面中嵌入一個不可見的iFrame，然后再讓這個iFrame指向任意站點的任意頁面。當(dāng)瀏覽器加載完所有的frame之后，攻擊者就可以在每一個frame中注入一個登錄表單和JavaScript腳本。此時，一個擁有密碼表單自動填寫功能的密碼管理器就會毫不猶豫地將相應(yīng)的密碼填寫進去。比如說，攻擊者想要竊取目標用戶的QQ號和微博賬號，那么他就可以在這個隱藏的iFrame元素中嵌入兩個frame，然后分別讓每一個frame指向包含QQ登錄表單和微博登錄表單的頁面，如果此時用戶的密碼管理器中保存了QQ密碼和微博密碼的話，攻擊也就成功了。

2. 除了iFrame之外，攻擊者還可以使用多重窗口來實現(xiàn)攻擊。攻擊者可以在用戶獲得WiFi網(wǎng)絡(luò)使用權(quán)之前強制彈出一個窗口，然后提醒用戶允許所有的彈窗。雖然相比iFrame來說，彈窗的形式可能比較容易吸引注意，但我們可以通過注入惡意JS代碼或?qū)⒋翱诜胖闷聊贿吘墎肀M量增加它的隱蔽性。當(dāng)攻擊者成功獲得密碼之后，可以立刻關(guān)閉這些窗口。

3. 第三種方法就是使用一系列的重定向鏈接。當(dāng)用戶請求某個頁面時，攻擊者可以將用戶請求重定向至另一個網(wǎng)站（例如攻擊者希望竊取的密碼所屬站點），然后通過注入惡意JS代碼向頁面添加一個登錄表單，并隱藏頁面的其他內(nèi)容。當(dāng)密碼管理器自動填寫了密碼之后，密碼就會被自動提取出來，然后瀏覽器又會被重定向至下一個目標站點，然后以此類推，不斷地往下，最后才會加載用戶當(dāng)初所要訪問的那個頁面。然而，這一切對于用戶來說，他們只會感覺這個WiFi網(wǎng)絡(luò)速度很慢…

在2014年的時候，也就是這篇論文發(fā)表的時候，研究人員對下圖所示的密碼管理器進行了測試，結(jié)果如下：

　　注入

Sweep攻擊要求攻擊者具備發(fā)動中間人攻擊和修改目標站點的能力，當(dāng)用戶訪問的目標頁面正好是登錄頁面的時候，攻擊就會非常簡單了。實際上，只要是目標頁面與登錄頁面是同源的，就已經(jīng)足夠了，因為所有的密碼管理器都會自動將保存的密碼與域名進行綁定，并且會忽略掉登錄頁面的實際路徑。

另外一種網(wǎng)站比較容易受攻擊的情況就是，使用HTTP來加載登錄表單，然后使用HTTPS來提交表單內(nèi)容，這是一種非常不好的實踐方式。根據(jù)2013年10月份的一項調(diào)查數(shù)據(jù)，AlexaTop 500的網(wǎng)站中有17%的網(wǎng)站其登錄表單是存在這種問題的。雖然現(xiàn)在已經(jīng)是2017年了，但我認為這種現(xiàn)象依舊存在。

任何一個HTTPS頁面如果通過HTTP來獲取動態(tài)內(nèi)容的話，那么這個頁面就是不安全的，而目前大多數(shù)瀏覽器都會屏蔽這些頁面。在這種情況下，即便登錄頁面使用的是HTTPS，該網(wǎng)站任何頁面中的XSS漏洞都將有可能被正常觸發(fā)。實際上，攻擊者只需要利用一個XSS漏洞就能完成攻擊，而且完全不需要搭建流氓WiFi熱點，攻擊者只需要欺騙用戶去訪問他們所控制的惡意頁面即可。

由錯誤的證書所導(dǎo)致的HTTPS通信異常也有可能允許攻擊者利用一個修改后的登錄頁面（使用自簽名證書）來發(fā)動攻擊。瀏覽器會檢測到這種異常，但用戶往往會直接忽略警告。

密碼提取

當(dāng)偽造頁面中的JS腳本獲取到了用戶密碼之后，提取密碼的過程就非常簡單了。一種方法是加載一個不可見的iFrame，然后將用戶憑證通過參數(shù)來傳遞。另一種方法是修改登錄表單的action參數(shù)，然后將用戶憑證通過表單提交至攻擊者控制的站點。

如果密碼管理器沒有自動填寫密碼的話，該怎么辦呢？

目前為止，本文所描述的全部攻擊方法可以正常工作的前提就是：用戶無需直接與登錄表單進行交互，密碼管理器的密碼自動填寫功能可以正常工作并自動填寫密碼。但是，論文中介紹的密碼提取技術(shù)與登錄表單是如何填寫的沒有多大關(guān)系。簡而言之，只要表單中填寫了密碼，我們就可以獲取到，無論這個密碼是用戶手動輸入的還是系統(tǒng)自動填寫的。

論文作者介紹的是一種點擊劫持攻擊，該技術(shù)在本文的這種攻擊場景下能夠正常工作，但唯一不足之處就是一次只能提取出一個賬戶密碼。關(guān)于該技術(shù)的詳細內(nèi)容請參閱論文原文【傳送門】。

應(yīng)對措施

最有效的防御措施就是采用Secure Filling（安全填寫），如果你想體驗Secure Filling，那么你將需要一個修改版的瀏覽器以及一個可以與之協(xié)同工作的修改版密碼管理器。

如果登錄頁面是通過HTTP加載，并使用HTTPS提交，那么當(dāng)這個登錄表單填寫完成之后，就沒有任何一款瀏覽器或密碼管理器能夠保證用戶密碼的安全了。因為JavaScript腳本不僅可以直接從表單中讀取出密碼，還可以修改表單的action屬性，并將密碼發(fā)送給攻擊者。Secure Filling技術(shù)的作用就在于，如果攻擊者向登錄頁面注入了惡意JS代碼的話，只要表單是通過HTTPS提交的，那么用戶密碼就是安全的。

　　Secure Filling技術(shù)要求：

1. 當(dāng)密碼管理器首次保存用戶名和密碼時，需要保存此時登錄表單中的action參數(shù)值。

2. 當(dāng)密碼管理器自動填寫完登錄表單之后，禁止JS代碼訪問該表單（因此需要一個修改版的瀏覽器）。

3. 在密碼自動填寫的過程中，如果用戶名或密碼文本域被修改了，那么密碼管理器會放棄填寫，并清除已填寫的內(nèi)容。

4. 當(dāng)填寫完成的表單提交，并且該運行的JS代碼全部運行完成之后，瀏覽器需要檢測當(dāng)前表單的action參數(shù)值是否與一開始保存的表單action相同，只有在參數(shù)值相同的時候瀏覽器才會真正提交表單數(shù)據(jù)。

結(jié)束語

這些問題已經(jīng)上報給了相關(guān)的密碼管理器服務(wù)商，并且廠商也修改了各自密碼管理器的自動填寫策略。由于本論文所發(fā)現(xiàn)的問題，LastPass將不再對iFrame中的密碼文本域進行自動填寫，1Password也不再自動填寫HTTP頁面中的密碼表單了。

關(guān)于1Password和Sweep攻擊的更多內(nèi)容可以參閱這篇文章【傳送門】。

* 參考來源：acolyer， FB小編Alpha_h4ck編譯，轉(zhuǎn)載請注明來自FreeBuf.COM