利用CSS注入（無iFrames）竊取CSRF令牌

CSS相信大家不會陌生，在百度百科中它的解釋是一種用來表現HTML（標準通用標記語言的一個應用）或XML（標準通用標記語言的一個子集）等文件樣式的計算機語言。

那麼，它僅僅只是一種用來表示樣式的語言嗎？當然不是！其實早在幾年前，CSS就已被安全研究人員運用於滲透測試當中。這裡有一篇文章就為我們詳細介紹了一種，使用屬性選擇器和iFrame，並通過CSS注入來竊取敏感數據的方法。但由於該方法需要iFrame，而大多數主流站點都不允許該操作，因此這種攻擊方法並不實用。

這裡我將為大家詳細介紹一種不需要iframe且只需10秒，就能為我們有效地竊取CSRF token的方法

一旦用戶的CSRF token被竊取，由於受害者已經在攻擊者的網站上，因此攻擊者可以繼續攻擊並完成對用戶的CSRF攻擊操作。

背景

正如原文所描述的那樣，CSS屬性選擇器開發者可以根據屬性標籤的值匹配子字元串來選擇元素。 這些屬性值選擇器可以做以下操作：

• 
  

  如果字元串以子字元串開頭，則匹配



• 
  

  如果字元串以子字元串結尾，則匹配



• 
  

  如果字元串在任何地方包含子字元串，則匹配

屬性選擇器能讓開發人員查詢單個屬性的頁面HTML標記，並且匹配它們的值。一個實際的用例是將以「https://example.com」開頭的所有href屬性變為某種特定的顏色。

而在實際環境中，一些敏感信息會被存放在HTML標籤內。在大多數情況下CSRF token都是以這種方式被存儲的：即隱藏表單的屬性值中。

這使得我們可以將CSS選擇器與表單中的屬性進行匹配，並根據表單是否與起始字元串匹配，載入一個外部資源，例如背景圖片，來嘗試猜測屬性的起始字母。

通過這種方式，攻擊者可以進行逐字猜解並最終獲取到完整的敏感數值。

想要解決這個問題受害者可以在其伺服器實施內容安全策略（CSP），防止攻擊者從外部載入CSS代碼。

無 iFrames

要做到無iFrame，我將使用一種類似於之前我討論過的方法：我將創建一個彈窗，然後在設置計時器後更改彈出窗口的位置。

使用這種方法，我仍然可以載入受害者的CSS，但我不再依賴於受害者是否允許iFrame。因為最初的彈出是通過用戶事件觸發的，所以我並沒有被瀏覽器阻止。

為了強制重載，我在CSS注入間彈出一個虛擬窗口，如下：

在CureSec的文章中描述了將數據傳輸到後端伺服器，但由於CSRF是針對客戶端的攻擊，因此如果我們能想出一種不需要伺服器的方法，那麼就可以為我們節省大量的開銷和簡化我們的操作。

為了接收受害者客戶端載入資源，我們可以利用Service Workers來攔截和讀取請求數據。Service Workers目前只適用於同源請求，在我的演示中受害者和攻擊者頁面已處於同一源上。

不過不久後，chrome很可能會合併這個實驗性的功能，允許Service Workers攔截跨域請求。

這樣，就可以確保我們在客戶端的攻擊100%的執行，並強制用戶在10秒內點擊鏈接執行CSRF攻擊，演示如下：

Demo

如上所述，因為我並不想運行一個web伺服器，所以我使用service workers攔截和模擬伺服器端組件。目前，該演示只適用於Chrome瀏覽器。

首先，我創建了一個易受攻擊的目標，它存在一個基於DOM的CSS注入漏洞，並在頁面放置了一個敏感token。我還對腳本標籤添加了一些保護措施，對左尖括弧和右尖括弧進行了編碼。

接下來，我們將強制載入受害者的CSS，並且使用上述方法，可一次竊取（猜解）一個敏感字元。

在接收端，我已經定義了一個攔截請求的service worker，並通過post-message將它們發送回域，然後我們將token存儲在本地存儲中以供後續使用。你也可以想像一個後端Web伺服器，通過Web套接字或輪詢將CSRF token回發給攻擊者域。

目前該測試僅支持CHROME：【閱讀原文】

如果你的瀏覽器支持的話，只需點擊打開頁面任意位置，你將看到CSRF token將逐一被猜解出來。

結語

有趣的是，反射型CSS注入實際上比存儲型CSS注入更致命，因為存儲型CSS注入需要一個伺服器在受害者渲染之前來更新CSS。

一段時間以來，CSS注入在嚴重程度上來回變化。過去IE瀏覽器是允許用戶在CSS中執行Javascript代碼的。這個演示也從某種程度上表明了CSS注入，以及在你的域上渲染不受信任的CSS仍會導致嚴重的安全問題。

*參考來源：github

，FB小編 secist 編譯，轉載請註明來自FreeBuf.COM

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！