XSLeaks 攻擊分析 —— HTTP快取跨站點洩漏
hello~ 我是Mss,今天分享一個很多開發人員和安全人員都很難想到的攻擊方式- XSLeaks 。
0x1 XSSearch的前世今生
這種攻擊方式最早可以追述到10年前(即2009年),一個名為Chris Evans的安全人員描述了一次對雅虎的攻擊:Chris利用惡意網站去搜索該網站訪問者的電子郵件收件箱裡的內容,他通過構造不同的關鍵詞的方式在使用者的收件箱中搜索,根據返回的時間進行判斷該關鍵詞是否存在,比如:搜尋“Alice”,如果對方收件箱裡有有關Alice的詞,則很久才能得到反饋;如果沒有,則在很短的時間就能得到反饋。這樣,經過多次查詢,很快就能蒐集大量的資訊。你也許覺得這沒什麼用處,但是如果用來檢索密碼或者一些商業來往郵件呢? 但是這種方法有一種弊端,他是基於響應時間來對結果進行判斷,而影響相應時間的因素很多。於是在六年後,Nethanel Gelernter和Amir Herzberg更深入地研究了這次攻擊,並將其命名為 XSSearch ,並使用統計學使其結果更加可靠。在接下來的幾年中,XSSearch的 攻擊方式不斷改進 ,不在是拘泥於時間,而是利用瀏覽器的快取機制,就這樣,XSSearch的 攻擊方法 越來越多,攻擊方式越來越穩定。
0x2 快取洩露的危害
我們都知道,瀏覽器會快取訪問過網站的網頁,當再次訪問這個URL地址的時候,如果網頁沒有更新,就不會再次下載網頁,而是直接使用本地快取的網頁。只有當網站明確標識資源已經更新,瀏覽器才會再次下載網頁。這樣不但保證了使用者的體驗,而且減少了網路頻寬消耗和伺服器的壓力,何樂而不為呢?但是,如果惡意人員有某種技術能看到我們瀏覽器的快取,或者說判斷我們的瀏覽器裡是否有哪些快取的話,會發生什麼呢? 他們可能會看到我們的瀏覽歷史,有些人覺得無所謂;但是你們可能不知道,許多網站根據使用者的地理位置定製他們的服務,如果這些網站將位置敏感內容留在瀏覽器快取中,那麼,惡意人員可以通過測量瀏覽器快取查詢的時間以跟蹤受害者的國家,城市和社群,此外,現有的防禦措施無法有效防止此類攻擊,並且需要額外的支援才能實現更好的防禦部署。只有這些嗎?通過對快取內容的查詢對方甚至可以知道你有哪些社交賬號,利用你的帳戶名稱進行涉及濫用個人資訊,線上欺詐等的各種型別的攻擊…… 也許你覺的這麼危險那麼很多網站應該已經在防範這種攻擊了,但在作者看來,大部分的網站還是容易受到攻擊的。至於如何防禦,將在本文的最後講到。
0x3 利用步驟
這種攻擊很有意思,實施起來分為三個步驟
- 刪除目標瀏覽器中特定的快取
- 開啟目標的瀏覽器查詢相關內容
- 檢查瀏覽器是否快取了相關的內容
舉個例子,假設你是www.xxx.com的使用者,當惡意使用者清空你的瀏覽器裡所有有關xxx.com的快取後,對方利用你的瀏覽器去訪問xxx.com高階會員才能看的內容,如果你是高階會員,那麼你的瀏覽器裡就會快取這部分的內容,反之亦然,惡意使用者只需判斷你的是否快取了這部分的內容就可以知道你的身份。 在那篇文章中,作者提出一種實現這種攻擊的技巧:
- 刪除特定的資源快取
- 查詢快取是否存在以判斷瀏覽器是否快取了它
我們一步步來:
首先是清空目標的快取。 可以通過向目標網站傳送一個post請求來清空目標內容,有些人可能覺得不可思議,但這是真的,具體可以參考 這篇部落格 ;或者設計一個 過長的url ,這樣就能使目標伺服器報錯,並且清空之前的快取。
其次是訪問想要查詢的內容。 比如使用 link rel = prerender 或者直接開啟一個新的視窗去訪問你要查詢的內容,檢查資源是否被訪問;或者,也可以使用一個過長的url來判斷,可能這裡很多人不明白,前文說通過構造一個過長的url使瀏覽器不載入快取,這裡問什麼可以用來驗證快取是否存在呢?
很簡單,首先這裡的“過長的url”只是一種技術,並不是指的同一個url;可以這麼理解:假設快取的是一個圖片檔案,名字為a.jpg,然後你去通過一個過長的url去訪問,因為這樣會讓瀏覽器不去載入新的圖片,那麼瀏覽器則顯示之前的快取,即a.jpg。 terjanq 提過了一個很好的 例子 ,各位在看的時候請注意url欄的變化。
0x4 關於防禦
在文章中,作者也針對這種攻擊對市面上的幾款瀏覽器進行分析(前文說了,現在大多是根據瀏覽器的快取機制進行判斷),作者認為,這種攻擊很難影響使用Safari瀏覽器的使用者,因為Safari瀏覽器有一個稱為“ 已驗證的分割槽快取(Split Disk Cache) ”的東西,這是一種阻止使用者跟蹤的技術,同樣也能阻止這種攻擊,但是作者認為仍然可以利用這種攻擊,只不過相當複雜;chrome瀏覽器正在試驗一種稱為“ 均分磁碟快取(Split Disk Cache) ”的技術來解決這個問題,如果想要啟用這個技術,需要在chrome瀏覽器的url欄中輸入chrome://flags/,設定enable-features = SplitCacheByTopFrameOrigin,但是尷尬的是我在我的chrome(版本 73.0.3683.86-正式版-64位)裡沒有找到這個;而Firefox採用更進一步的方式“ 第一方隔離(First Party Isolation) ”來解決這個問題,使用者可以下載 外掛 或在位址列中輸入about:config找到privacy.firstparty.isolate將其設定為true啟用這個功能。 對於開發者,作者也提出一些建議。比如禁用HTTP快取,使用CSRFToken,但是這兩種方法都會給使用者的體驗感帶來影響;作者認為可以通過設定 SameSite-cookies 來對使用者進行設定,但是現在也有些已知的繞過;或者是參考Firefox瀏覽器採用的 COOP ;亦或者是參考Facebook嘗試做的;當然,也可以參考 這裡的想法 。
0x5 結言
在文章的最後,作者提到HTTP快取並不是唯一的資訊洩露來源,還有 很多 !感興趣的朋友可以去看看!我是 掌控安全實驗室 的Mss,歡迎關注我們的從CVE分析學漏洞專欄,以及新型漏洞跟進分析專題。
附可供拓展研究的參考資料:
https://www.youtube.com/watch?v=vzp7JdezZRU
https://cloud.google.com/storage/docs/access-control/signing-urls-manually
https://www.youtube.com/watch?v=KcOQfYlyIqw&pbjreload=10
https://zh.wikipedia.org/wiki/%E6%97%81%E8%B7%AF%E6%94%BB%E5%87%BB
https://www.cnblogs.com/slly/p/6732749.html
http://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html?m=1