跨站請(qǐng)求偽造（即CSRF）被Web安全界稱為諸多漏洞中“沉睡的巨人”，其威脅程度由此“美譽(yù)”便可見(jiàn)一斑。本文將簡(jiǎn)單介紹該漏洞，并詳細(xì)說(shuō)明造成這種漏洞的原因所在，以及針對(duì)該漏洞的黑盒測(cè)試與灰盒子測(cè)試具體方法和示例，最后提提了一些防范該攻擊的建議，希望本文對(duì)讀者的安全測(cè)試能夠有所啟發(fā)。

一、CSRF概述

我們首先來(lái)了解一下什么是跨站請(qǐng)求偽造（CSRF）？跨站請(qǐng)求偽造是一種挾制終端用戶在當(dāng)前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。攻擊者只要借助少許的社會(huì)工程詭計(jì)，例如通過(guò)電子郵件或者是聊天軟件發(fā)送的鏈接，攻擊者就能迫使一個(gè)Web應(yīng)用程序的用戶去執(zhí)行攻擊者選擇的操作。例如，如果用戶登錄網(wǎng)絡(luò)銀行去查看其存款余額，他沒(méi)有退出網(wǎng)絡(luò)銀行系統(tǒng)就去了自己喜歡的論壇去灌水，如果攻擊者在論壇中精心構(gòu)造了一個(gè)惡意的鏈接并誘使該用戶點(diǎn)擊了該鏈接，那么該用戶在網(wǎng)絡(luò)銀行帳戶中的資金就有可能被轉(zhuǎn)移到攻擊者指定的帳戶中。
當(dāng)CSRF針對(duì)普通用戶發(fā)動(dòng)攻擊時(shí)，將對(duì)終端用戶的數(shù)據(jù)和操作指令構(gòu)成嚴(yán)重的威脅；當(dāng)受攻擊的終端用戶具有管理員帳戶的時(shí)候，CSRF攻擊將危及整個(gè)Web應(yīng)用程序。

二、造成CSRF的原因

跨站請(qǐng)求偽造能否得逞，與以下幾個(gè)方面密不可分，分別是瀏覽器對(duì)會(huì)話的處理，攻擊者對(duì)Web應(yīng)用有關(guān)URL的了解，應(yīng)用程序賴以管理會(huì)話的信息對(duì)瀏覽器的透明性以及各種能夠引發(fā)資源請(qǐng)求HTML標(biāo)簽等。下面分別加以解釋。

首先，我們來(lái)了解一些Web瀏覽器對(duì)于Cookie和HTTP身份驗(yàn)證信息之類的會(huì)話信息的處理方式。目前，瀏覽器會(huì)自動(dòng)地發(fā)送標(biāo)識(shí)用戶對(duì)話的信息，而無(wú)需用戶干預(yù)，換句話說(shuō)，當(dāng)瀏覽器發(fā)送這些身份信息的時(shí)候，用戶根本感覺(jué)不到。假設(shè)站點(diǎn)A上有一個(gè)Web應(yīng)用程序，并且受害者正好已經(jīng)在該站點(diǎn)上通過(guò)了身份認(rèn)證，這時(shí)，站點(diǎn)會(huì)向受害者發(fā)送一個(gè)cookie作為響應(yīng)，這個(gè)cookie的作用是什么呢？主要是被站點(diǎn)作為用戶會(huì)話的標(biāo)志，即如果站點(diǎn)收到了帶有受害者的cookie的請(qǐng)求，那么它就會(huì)把這個(gè)請(qǐng)求看作是已登錄的受害者發(fā)來(lái)的。一般情況下，瀏覽器收到站點(diǎn)設(shè)置的cookie之后，每當(dāng)向該站點(diǎn)發(fā)送請(qǐng)求的時(shí)候，瀏覽器都會(huì)“自動(dòng)地”連同該cookie一起發(fā)出。

然后，我們?cè)賮?lái)討論一下攻擊者對(duì)Web應(yīng)用程序URL的了解。如果應(yīng)用程序沒(méi)有在URL中使用跟會(huì)話有關(guān)的信息的話，那么通過(guò)代碼分析或者通過(guò)訪問(wèn)該應(yīng)用程序并查看嵌入HTML/JavaScript中的URL以及表單來(lái)了解應(yīng)用程序有關(guān)的URL、參數(shù)和容許值。

接下來(lái)，我們討論一下應(yīng)用程序賴以管理會(huì)話的信息對(duì)瀏覽器的透明性問(wèn)題。我們知道，為了提高Web應(yīng)用的便利性，用來(lái)管理會(huì)話的信息，例如Cookie或者基于HTTP的身份驗(yàn)證（例如HTTP基本認(rèn)證、非基于表單的認(rèn)證）等敏感信息，都是由瀏覽器來(lái)存放的，并在每當(dāng)向需要身份驗(yàn)證的應(yīng)用程序發(fā)送請(qǐng)求時(shí)自動(dòng)捎帶上這些信息。也就是說(shuō)，瀏覽器可以訪問(wèn)會(huì)話管理信息，如果Web應(yīng)用程序完全依賴于這類信息來(lái)識(shí)別一個(gè)用戶會(huì)話，這就為跨站請(qǐng)求偽造創(chuàng)造了條件。

上面所說(shuō)的三個(gè)因素，是跨站請(qǐng)求偽造攻擊的必要的條件，而下面所說(shuō)的，是一個(gè)“錦上添花”的因素，即沒(méi)有它也能發(fā)動(dòng)跨站請(qǐng)求偽造攻擊，但是有了它能使該攻擊更加容易。這就是存在多種HTML標(biāo)簽，如果頁(yè)面內(nèi)出現(xiàn)這些標(biāo)簽，會(huì)立刻引起瀏覽器對(duì)http[s]資源的訪問(wèn)，例如圖像標(biāo)簽img便是其中之一。

為簡(jiǎn)單起見(jiàn)，我們這里討論GET方式的URL（不過(guò)這里討論的內(nèi)容同樣適用于POST請(qǐng)求）。如果受害者已經(jīng)通過(guò)身份驗(yàn)證，那么當(dāng)他提交其它請(qǐng)求時(shí)，該cookie也會(huì)自動(dòng)地隨之發(fā)送（如圖，這里用戶正在訪問(wèn)www.example.com上的一個(gè)應(yīng)用程序 ）。

圖1  瀏覽器發(fā)送請(qǐng)求的同時(shí)還自動(dòng)發(fā)送cookie

那么，什么情況下會(huì)引起發(fā)送這個(gè)GET請(qǐng)求呢？這可就有多種可能了，首先當(dāng)用戶正常使用該Web應(yīng)用程序的過(guò)程中有可能引發(fā)這個(gè)GET請(qǐng)求；其次，當(dāng)用戶直接在瀏覽器地址欄中鍵入該URL時(shí)也會(huì)引發(fā)該GET請(qǐng)求；再者，用戶單擊了指向該URL的鏈接，即使該鏈接位于該應(yīng)用程序外部，也會(huì)引發(fā)該GET請(qǐng)求。

對(duì)于應(yīng)用程序來(lái)說(shuō)，它是無(wú)法區(qū)分上面的這些差別的。特別是第三種可能是非常危險(xiǎn)的。有許多技術(shù)（和漏洞）可以隱藏一個(gè)鏈接的真實(shí)屬性。鏈接可以嵌入電子郵件消息中，也可以出現(xiàn)在存心不良的Web站點(diǎn)，然后引誘用戶瀏覽該站點(diǎn)，例如鏈接出現(xiàn)在位于其他主機(jī)上（其它Web 站點(diǎn)、HTML格式的電子郵件消息，等等）的內(nèi)容中，并且指向應(yīng)用程序的資源。如果用戶單擊了該鏈接，由于他已經(jīng)通過(guò)了站點(diǎn)上Web 應(yīng)用程序的認(rèn)證，所以瀏覽器就會(huì)發(fā)出一個(gè)GET請(qǐng)求給該Web 應(yīng)用程序，同時(shí)將驗(yàn)證信息（包含會(huì)話id的cookie）一并發(fā)過(guò)去。這樣會(huì)導(dǎo)致在Web 應(yīng)用程序上執(zhí)行一個(gè)有效操作——該操作可能不是該用戶所想要的，例如一個(gè)引起在網(wǎng)絡(luò)銀行上進(jìn)行轉(zhuǎn)帳惡意的鏈接，等等。

如前所述，通過(guò)使用諸如img之類的標(biāo)簽，甚至不需要用戶點(diǎn)擊具體的鏈接就能發(fā)動(dòng)攻勢(shì)。假設(shè)攻擊者向用戶發(fā)送了一封電子郵件，誘騙用戶訪問(wèn)一個(gè)URL，而該URL則指向一個(gè)包含下列HTML內(nèi)容（注意，內(nèi)容已作精簡(jiǎn)）的頁(yè)面：

 [html][body]
...
(img src=”https://www.company.example/action” width=”0” height=”0”)
...
[/body][/html]

用時(shí)將[]換成<>

當(dāng)瀏覽器顯示該頁(yè)面時(shí)，它也將設(shè)法顯示這個(gè)指定寬度為0的圖像，即該圖像是不可見(jiàn)的——這會(huì)導(dǎo)致自動(dòng)向站點(diǎn)中的Web 應(yīng)用程序發(fā)送一個(gè)請(qǐng)求。要緊的是，瀏覽器不管該圖像URL實(shí)際是否指向一個(gè)圖片，只要src字段中規(guī)定了URL，就會(huì)按照該地址觸發(fā)一個(gè)請(qǐng)求。當(dāng)然，這里有一個(gè)前提，那就是瀏覽器沒(méi)有禁止下載圖像——實(shí)際上瀏覽器都配置成允許下載圖像，因?yàn)榻脠D像后大多數(shù)Web應(yīng)用程序的可用性就會(huì)大打折扣。與跨站請(qǐng)求偽造有關(guān)的HTML標(biāo)簽問(wèn)題是總結(jié)如下：

頁(yè)面中有許多標(biāo)簽會(huì)導(dǎo)致自動(dòng)發(fā)出HTTP請(qǐng)求（img標(biāo)簽便是其中之一）；

瀏覽器無(wú)法斷定img標(biāo)簽所引用的資源到底是不是圖像以及是否是有害的；

當(dāng)加載圖像時(shí)，根本就不考慮所涉及的圖像所在的位置，即表單和圖像不必位于同一個(gè)主機(jī)上，甚至可以不再同一個(gè)域內(nèi)。雖然這是一個(gè)非常便利的特性，但是卻給應(yīng)用程序的隔離制造的障礙。正是由于與Web 應(yīng)用程序無(wú)關(guān)的HTML內(nèi)容可以引用應(yīng)用程序中的各種組件，以及瀏覽器可以自動(dòng)為該應(yīng)用程序構(gòu)造一個(gè)有效的請(qǐng)求這兩個(gè)事實(shí)才導(dǎo)致了這種攻擊的出現(xiàn)。這意味著，正確的URL必須包含用戶會(huì)話有關(guān)的信息，而攻擊者卻無(wú)法得知這些信息，因此不可能識(shí)別這樣的URL。

對(duì)于集成了郵件/瀏覽器功能的工作平臺(tái)，跨站請(qǐng)求偽造問(wèn)題可能更為嚴(yán)重，因?yàn)椋瑑H僅顯示一封包含該圖像的電子郵件就會(huì)導(dǎo)致請(qǐng)求及有關(guān)瀏覽器cookie一起向Web應(yīng)用程序發(fā)去。

另外，攻擊者還可以對(duì)這些東西進(jìn)行偽裝，例如引用貌似合法的圖像URLs，例如

(img src=”https://[attacker]/picture.gif” width=”0” height=”0”)

用時(shí)將()換成<>

這里，[attacker]是攻擊者控制下的站點(diǎn)，并通過(guò)重定向機(jī)制將http://[attacker ]/picture. gif轉(zhuǎn)向http://[thirdparty ]/action。
如果Web應(yīng)用程序的會(huì)話信息完全靠瀏覽器來(lái)提供的話，那么這樣的Web應(yīng)用程序也都易于受到攻擊，其中包括那些僅依賴于HTTP身份驗(yàn)證機(jī)制的那些應(yīng)用程序，因?yàn)闉g覽器知道這些驗(yàn)證信息，并會(huì)在發(fā)送每個(gè)請(qǐng)求的時(shí)候自動(dòng)附帶這些驗(yàn)證信息。當(dāng)然，這不包括基于表單的認(rèn)證，它只發(fā)出一次，并且生成了有關(guān)會(huì)話信息的表單——當(dāng)然，如果這樣的信息就像cookie那樣進(jìn)行簡(jiǎn)單的傳遞的話，這就有回到了之前的情形。