前言
有安全意識的人肯定不會為所有的網站設置同樣的密碼。為了提高一站一密碼的安全系數，你可能會使用到密碼管理器。不過剛開始使用時可能會有一絲不安，畢竟它將所有的密碼都放在了同一個地方，而且很多密碼管理器都會同步到所有設備和云上。在這篇文章中，作者說明了很多密碼管理器中都包含一個主要漏洞，而且這個漏洞如被利用可自動填充密碼字段!由于作者寫作本文是在2014年，因此可能所述的攻擊向量已被關閉(如果你知道相關的更新報告，請在評論區留言)，不過我認為這些攻擊的變種仍然還在。
一言以蔽之：不要使用自動填充功能。
邪惡的咖啡店攻擊者
攻擊者應該能夠實施主動的中間人攻擊。但是要竊取網站的憑證，也沒有硬性要求用戶必須直接明確地訪問或者登錄到某個網站。咖啡店(舉個例子)的一個惡意wifi路由器就夠了：連接到這個路由器，你的密碼就不翼而飛了。
我們將這種攻擊者稱為“邪惡的咖啡店攻擊者”。這些攻擊只需要對網絡路由器擁有臨時控制，而且實施起來更容易，因此很可能在現實生活中發生。在我們所講述的很多攻擊中，用戶都無需跟受害者網站交互，而且用戶不會意識到密碼已被提取。
掃描攻擊
基本的掃描(sweep)攻擊會攻陷所有支持自動填充密碼字段的密碼管理器，因為目標用戶連接到了由攻擊者控制的WiFi熱點。
當用戶啟動瀏覽器時，瀏覽器會被重定向到一個標準的熱點登錄頁面，該頁面要求獲取用戶關于標準使用條款的同意。這種行為常見于公共熱點。然而，用戶沒有意識到的是，登錄頁面包含著實施攻擊的不可見元素。
換句話說，等到你查看完整加載的登錄頁面時，你的多數憑證可能已經不見了。在測試中，每秒可被提取的密碼數量是10個左右。
大體來講，攻擊者有三種使用登錄頁面的方法來掃描密碼：
1. 在iFrame掃描攻擊中，登錄頁面包含指向多個目標站點任意頁面的不可見內嵌框架。當瀏覽器加載這些框架時，攻擊者會向它們注入一個登錄表單和javascript(詳細方法看下文)。自動填充密碼管理器會將用戶密碼填入相應的字段。
2. 攻擊者不會使用內嵌框架，而是使用多個窗口。通過要求在用戶能夠獲取訪問wifi網絡之前打開窗口，用戶會禁用任何彈出阻攔。雖然多個窗口要比不可見的內嵌框架更惹人注意，但是注入的javascript能夠將它們最小化或將它們移動到屏幕邊緣。密碼被盜后，窗口就會馬上被關閉。
3. 第三種方法是使用重定向鏈。當用戶請求某個頁面時，攻擊者就會以某個站點的重定向作為響應，攻擊者正是憑此來獲悉密碼。被注入的javascript增加一個登錄表單并隱藏頁面詳情。一旦密碼管理器自動填充了密碼且密碼被提取，瀏覽器就會被重定向至下一個目標站點，以此循環往復，最終加載到用戶原來請求的頁面。而用戶看到的不過是一個緩慢的wifi連接。
下列表格展示了截止2014年被測試的密碼管理器，它們均易受掃描攻擊。
注：上表是掃描攻擊的漏洞。“+”表示漏洞沒有限制。HTTPS表示漏洞僅存在于HTTPS頁面。Single代表每個高級頁面加載中有一個站點易受攻擊。SO表示當包含內嵌框架的頁面跟內嵌框架中的目標頁面是同源時的漏洞。
注入
掃描攻擊依靠的是攻擊者通過篡改網絡流量而修改受害者網站頁面的能力。當易受攻擊的頁面就是登錄頁面本身時，攻擊最容易實施。然而，只要有任何跟登錄頁面同源的頁面就足夠了，因為所有關聯的密碼管理器都通過域名保存密碼而忽視登錄頁面的路徑。
實施攻擊的一個簡單方法就是在HTTP協議下提供登錄表單的站點(不良實踐)，而且僅在提交時使用HTTPS。截止2013年10月份，在Alex排名前500的站點中，有17%的站點都是這么做的。目前情況應該好點了，但由于沒有數據，也無法下定論。
任何一個通過HTTP獲取動態內容的HTTPS網頁都易受攻擊(不過多數瀏覽器會實施攔截)。受害者網站任意網頁上的任何XSS漏洞也會起作用(即便登錄頁面用的是HTTPS協議)。實際上網站上任何位置的XSS漏洞即使在不需要惡意WiFi的情況下都能觸發攻擊——只要網絡攻擊者能夠誘騙用戶訪問受攻擊者控制的網站即可。
損壞的HTTPS鏈接(例如損壞的證書)也會導致漏洞的出現，因為攻擊者能夠使用一個自簽名證書作為修改后的登錄頁面。瀏覽器會發出告警，但用戶通常都會選擇忽視告警信息(尤其是當告警出現在登錄WiFi網絡時，或者至少用戶是這么認為的)。
嵌入式設備更是如此。嵌入式設備會通過HTTP提供登錄頁面，它們一般是在受WiFi加密保護的私有網絡上或者是通過HTTPS提供登錄頁面但使用自簽名證書的家庭路由器。
密碼提取
一旦攻擊者頁面的javascript獲得目標密碼，提取就容易多了。其中一種方法是加載一個不可見的內嵌框架并將憑證作為參數通過;另一種方法是修改登錄表單的動作使其提交到受攻擊者控制的站點。
如果密碼管理器不支持自動填充呢?
到現在為止，我們提到的攻擊都是當用戶沒有跟登錄表單交互時，使用密碼管理器的自動填充功能起作用。然而，我們提到的密碼提取技術跟登錄表單如何填充并沒有關系。如果用戶的密碼管理器要求用戶輸入密碼，那么攻擊者就能夠誘騙用戶在無意識的情況下跟登錄表單交互，一旦表單填充完畢，可使用相同的提取技術竊取密碼。
作者描述了一種能夠在這種場景下起作用的點擊劫持，盡管我們現在只限于一次只竊取一個密碼的方式。
密碼管理器中的支持弱點
密碼管理器除了自動填充功能外，還有其它一些行為也能幫助攻擊者，這些行為的目的是嘗試變得更加強大以應對站點實現詳情中的變化。下表是一個簡短總結。
注：密碼管理器的自動填充行為(自動化自動填充、手動自動填充或未填充)取決于協議 (http/https)、自動完成屬性、跟協議相關的用于當前頁面的表單動作和保存密碼時使用的表單動作。Manual autofilling(手動自動填充)是指完成某些用戶交互后自動填充密碼如點擊或觸摸其中的一個表單字段。No fill(未填充)是指沒有自動填充密碼。倒數第二列是指當密碼字段的自動完成屬性被設置為off時的自動填充行為。最后一列是指不良HTTPS連接狀態下針對加載的一個登錄頁面后的自動填充行為。
防御
主要的防御手段是要求安全填充，只需要一個被修改的瀏覽器就足夠了(以及需要一個被修改的密碼管理器與之相對應)。
如果一個登錄頁面是通過HTTP加載的但卻通過HTTPS提交，那么一旦登錄表單填上了用戶的密碼，那么瀏覽器或密碼管理器實現就無法提供安全性，因為JavaScript能夠直接從表單讀取密碼或者更改表單動作，以便提交到由攻擊者托管的密碼竊取頁面。安全填充的目標是即使攻擊者將惡意JavaScript注入登錄頁面，密碼管理器自動填充的密碼還是安全的，前提條件是表單是通過HTTPS提交的。
安全填充要求：
1. 從當用戶名和密碼首次被保存開始起，密碼管理器要存儲在登錄表單中顯示的行為。
2. 當登錄表單由密碼管理器自動填充時，JavaScript無法讀取該表單(因此要有被修改的瀏覽器)。
3. 如果在自動填充正在進行過程中，用戶名或密碼字段被(用戶或JavaScript)修改，自動填充會中止從密碼字段中清除密碼并再次讓字段變為可讀。
4. 一旦被自動填充的表單提交，而且JavaScript運行之后，瀏覽器就會檢查表單的行為是否跟存儲的一致，只有在一致的情況下才會提交表單。
需要注意的是，這也意味著，比如，我們需要處理起始注冊頁面，尤其是當它們經常會包含客戶端對密碼長度進行校驗(要求js權限)時。
我們將研究結果披露給了密碼管理器廠商，并提出對自動填充策略的一些改變。從我們的研究來看，LastPass不會在內嵌框架中自動填充密碼，而iPassword也不再為HTPP頁面提供從HTTPS頁面填充密碼的服務。
從此處可了解關于為何iPassword為何不提供自動填充功能的內容以及關于掃描攻擊的討論。
京公網安備 11010502049343號