【翻譯】XS-Leaks攻擊簡介

今天在讀SP的一篇文章Cross-Origin State Inference (COSI) Attacks:Leaking Web Site States through XS-Leaks的時候，發現對作者使用的XS-Leaks攻擊不理解，而且國內博客資料也很少，因此我去Google了一下。在這裏，把我的查閱的資料翻譯一下，並寫下我的理解。後面，我會附上SP那篇論文的論文筆記。

歷史¹

在10年前，Chris Evans描述了一種針對Yahoo!Mail攻擊。這是一個基於network timing的攻擊，攻擊者讓受害者進行一次查詢詢問，通過訪問返回時間的長短，來判斷用戶是否在攻擊者預設的列表中。
六年後，Nethanel Gelernter和Amir Herzberg對這一攻擊進行了深入的研究，並設計了XSSearch攻擊。攻擊不斷改進，這次攻擊不在僅僅限於時間，瀏覽器的“錯誤特性”和漏洞使得攻擊更加穩定，這使得攻擊達到近乎完美的程度。

攻擊的核心是檢測一個查詢詢問是否有結果。 XS-Leaks利用了對HTTP緩存進行查詢的機制。

舉例¹

1. Delete the cache for a specific resource (or list of resources).
   首次，使用POST請求或者提取API與緩存一起使用：``重新加載’’（reload），以一種在服務器上返回錯誤的方式（例如，通過設置一個超長的HTTP引薦來源網址） ，這將導致瀏覽器不緩存響應，並使先前緩存的響應無效。
2. Force the browser to render a website (navigation, or prerender).
   強制受害者瀏覽器訪問一個網站。這個網站是攻擊者設計的網站，訪問該網站會使得受害者訪問要檢查的網頁。在一定情況下，攻擊者會緩存要檢查的網頁的資源。
3. Check if the browser cached the resource deleted at (1).
   再次強制受害者瀏覽器訪問攻擊者實際的網站，但URL非常長，服務器是無法返回有效的資源的。不過在其中嵌入的圖片會因爲已經被緩存在客戶端，所以可以訪問。由此可以判別，用戶是否緩存該資源。
   

應用場景²

看了上面的攻擊過程，感覺沒啥用處，因爲爲什麼要知道是否受害者緩存過什麼資源呢？
下面這個應用場景給了我們答案。

• 攻擊者目標：獲取受害者社交網站的用戶名，以確定受害者在社交網站中的身份。（因爲在現實生活中，人們在社交網站上使用虛假的名字，我們無法定位到這個人是誰。）
• 攻擊過程
  0. 清空HTTP緩存資源。
  1. 使攻擊者訪問惡意頁面。其中惡意頁面需要加載受害者在某社交媒體平臺的照片。該照片會保存在HTTP緩存中，並以受害者用戶名命名。
  2. 使攻擊者訪問惡意頁面，然後需要加載/tim.png的照片出來，但是由於本地緩存沒有，因此無法加載；然後需要加載/alice.png的照片，由因爲剛好是Alice，因此加載成功。
  3. 看到加載成功的結果，攻擊者可以斷定，受害人是Alice。
     

防禦¹

重要的是，希望不同域應該訪問不同域的緩存。

1. 禁用HTTP緩存
2. 在所有的內容上加上CSRF tokens
3. 可以使用Same Site=strict cookie對用戶進行身份驗證。
   等等

---

1. HTTP Cache Cross-Site Leaks: ↩︎ ↩︎ ↩︎

2. Web tracking via HTTP cache cross-site leaks ↩︎