怎么利用CSS注入竊取CSRF令牌

這篇文章主要講解了“怎么利用CSS注入竊取CSRF令牌”，文中的講解內容簡(jiǎn)單清晰，易于學(xué)習與理解，下面請大家跟著(zhù)小編的思路慢慢深入，一起來(lái)研究和學(xué)習“怎么利用CSS注入竊取CSRF令牌”吧！

CSS相信大家不會(huì )陌生，在百度百科中它的解釋是一種用來(lái)表現HTML（標準通用標記語(yǔ)言的一個(gè)應用）或XML（標準通用標記語(yǔ)言的一個(gè)子集）等文件樣式的計算機語(yǔ)言。那么，它僅僅只是一種用來(lái)表示樣式的語(yǔ)言嗎？當然不是！其實(shí)早在幾年前，CSS就已被安全研究人員運用于滲透測試當中。這里有一篇文章就為我們詳細介紹了一種，使用屬性選擇器和iFrame，并通過(guò)CSS注入來(lái)竊取敏感數據的方法。但由于該方法需要iFrame，而大多數主流站點(diǎn)都不允許該操作，因此這種攻擊方法并不實(shí)用。

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

一旦用戶(hù)的CSRF token被竊取，由于受害者已經(jīng)在攻擊者的網(wǎng)站上，因此攻擊者可以繼續攻擊并完成對用戶(hù)的CSRF攻擊操作。

背景

正如原文所描述的那樣，CSS屬性選擇器開(kāi)發(fā)者可以根據屬性標簽的值匹配子字符串來(lái)選擇元素。 這些屬性值選擇器可以做以下操作：

• 如果字符串以子字符串開(kāi)頭，則匹配

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

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

屬性選擇器能讓開(kāi)發(fā)人員查詢(xún)單個(gè)屬性的頁(yè)面HTML標記，并且匹配它們的值。一個(gè)實(shí)際的用例是將以“https://example.com”開(kāi)頭的所有href屬性變?yōu)槟撤N特定的顏色。

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

這使得我們可以將CSS選擇器與表單中的屬性進(jìn)行匹配，并根據表單是否與起始字符串匹配，加載一個(gè)外部資源，例如背景圖片，來(lái)嘗試猜測屬性的起始字母。

通過(guò)這種方式，攻擊者可以進(jìn)行逐字猜解并最終獲取到完整的敏感數值。

想要解決這個(gè)問(wèn)題受害者可以在其實(shí)施內容安全策略（CSP），防止攻擊者從外部加載CSS代碼。

無(wú)iFrames

要做到無(wú)iFrame，我將使用一種類(lèi)似于之前我討論過(guò)的方法：我將創(chuàng )建一個(gè)彈窗，然后在設置計時(shí)器后更改彈出窗口的位置。

使用這種方法，我仍然可以加載受害者的CSS，但我不再依賴(lài)于受害者是否允許iFrame。因為最初的彈出是通過(guò)用戶(hù)事件觸發(fā)的，所以我并沒(méi)有被瀏覽器阻止。

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

var win2 = window.open('https://security.love/anything', 'f', "top=100000,left=100000,menubar=1,resizable=1,width=1,height=1")
var win2 = window.open(`https://security.love/cssInjection/victim.html?injection=${css}`, 'f', "top=100000,left=100000,menubar=1,resizable=1,width=1,height=1")

沒(méi)有后端服務(wù)器

在CureSec的文章中描述了將數據傳輸到后端服務(wù)器，但由于CSRF是針對客戶(hù)端的攻擊，因此如果我們能想出一種不需要服務(wù)器的方法，那么就可以為我們節省大量的開(kāi)銷(xiāo)和簡(jiǎn)化我們的操作。

為了接收受害者客戶(hù)端加載資源，我們可以利用Service Workers來(lái)攔截和讀取請求數據。Service Workers目前只適用于同源請求，在我的演示中受害者和攻擊者頁(yè)面已處于同一源上。

不過(guò)不久后，chrome很可能會(huì )合并這個(gè)實(shí)驗性的功能，允許Service Workers攔截跨域請求。

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

Demo

如上所述，因為我并不想運行一個(gè)web服務(wù)器，所以我使用service workers攔截和模擬服務(wù)器端組件。目前，該演示只適用于Chrome瀏覽器。

首先，我創(chuàng )建了一個(gè)易受攻擊的目標，它存在一個(gè)基于DOM的CSS注入漏洞，并在頁(yè)面放置了一個(gè)敏感token。我還對腳本標簽添加了一些保護措施，對左尖括號和右尖括號進(jìn)行了編碼。

<form action="https://security.love" id="sensitiveForm"><input type="hidden" id="secret" name="secret" value="dJ7cwON4BMyQi3Nrq26i">
</form>
<script src="mockingTheBackend.js"></script>
<script>var fragment = decodeURIComponent(window.location.href.split("?injection=")[1]);
    var htmlEncode = fragment.replace(/</g,"&amplt;").replace(/>/g,"&ampgt;");
    document.write("<style>" + htmlEncode + "</style>");
</script>

接下來(lái)，我們將強制加載受害者的CSS，并且使用上述方法，可一次竊?。ú陆猓┮粋€(gè)敏感字符。

在接收端，我已經(jīng)定義了一個(gè)攔截請求的service worker，并通過(guò)post-message將它們發(fā)送回域，然后我們將token存儲在本地存儲中以供后續使用。你也可以想象一個(gè)后端Web服務(wù)器，通過(guò)Web套接字或輪詢(xún)將CSRF token回發(fā)給攻擊者域。

目前該測試僅支持CHROME：

demo

如果你的瀏覽器支持的話(huà)，只需點(diǎn)擊打開(kāi)頁(yè)面任意位置，你將看到CSRF token將逐一被猜解出來(lái)。

結語(yǔ)

有趣的是，反射型CSS注入實(shí)際上比存儲型CSS注入更致命，因為存儲型CSS注入需要一個(gè)服務(wù)器在受害者渲染之前來(lái)更新CSS。

一段時(shí)間以來(lái)，CSS注入在嚴重程度上來(lái)回變化。過(guò)去IE瀏覽器是允許用戶(hù)在CSS中執行Javascript代碼的。這個(gè)演示也從某種程度上表明了CSS注入，以及在你的域上渲染不受信任的CSS仍會(huì )導致嚴重的安全問(wèn)題。