一、CSRF概述

我們首先來了解一下什麼是跨站請求偽造（CSRF）？跨站請求偽造是一種挾制終端使用者在當前已登入的Web應用程式上執行非本意的操作的攻擊方法。攻擊者只要藉助少許的社會工程詭計，例如通過電子郵件或者是聊天軟體傳送的連結，攻擊者就能迫使一個Web應用程式的使用者去執行攻擊者選擇的操作。例如，如果使用者登入網路銀行去檢視其存款餘額，他沒有退出網路銀行系統就去了自己喜歡的論壇去灌水，如果攻擊者在論壇中精心構造了一個惡意的連結並誘使該使用者點選了該連結，那麼該使用者在網路銀行帳戶中的資金就有可能被轉移到攻擊者指定的帳戶中。
當CSRF針對普通使用者發動攻擊時，將對終端使用者的資料和操作指令構成嚴重的威脅；當受攻擊的終端使用者具有管理員帳戶的時候，CSRF攻擊將危及整個Web應用程式。

二、造成CSRF的原因

跨站請求偽造能否得逞，與以下幾個方面密不可分，分別是瀏覽器對會話的處理，攻擊者對Web應用有關URL的瞭解，應用程式賴以管理會話的資訊對瀏覽器的透明性以及各種能夠引發資源請求HTML標籤等。下面分別加以解釋。

首先，我們來了解一些Web瀏覽器對於Cookie和HTTP身份驗證資訊之類的會話資訊的處理方式。目前，瀏覽器會自動地傳送標識使用者對話的資訊，而無需使用者干預，換句話說，當瀏覽器傳送這些身份資訊的時候，使用者根本感覺不到。假設站點A上有一個Web應用程式，並且受害者正好已經在該站點上通過了身份認證，這時，站點會向受害者傳送一個cookie作為響應，這個cookie的作用是什麼呢？主要是被站點作為使用者會話的標誌，即如果站點收到了帶有受害者的cookie的請求，那麼它就會把這個請求看作是已登入的受害者發來的。一般情況下，瀏覽器收到站點設定的cookie之後，每當向該站點發送請求的時候，瀏覽器都會“自動地”連同該cookie一起發出。

然後，我們再來討論一下攻擊者對Web應用程式URL的瞭解。如果應用程式沒有在URL中使用跟會話有關的資訊的話，那麼通過程式碼分析或者通過訪問該應用程式並檢視嵌入HTML/JavaScript中的URL以及表單來了解應用程式有關的URL、引數和容許值。

接下來，我們討論一下應用程式賴以管理會話的資訊對瀏覽器的透明性問題。我們知道，為了提高Web應用的便利性，用來管理會話的資訊，例如Cookie或者基於HTTP的身份驗證（例如HTTP基本認證、非基於表單的認證）等敏感資訊，都是由瀏覽器來存放的，並在每當向需要身份驗證的應用程式傳送請求時自動捎帶上這些資訊。也就是說，瀏覽器可以訪問會話管理資訊，如果Web應用程式完全依賴於這類資訊來識別一個使用者會話，這就為跨站請求偽造創造了條件。

上面所說的三個因素，是跨站請求偽造攻擊的必要的條件，而下面所說的，是一個“錦上添花”的因素，即沒有它也能發動跨站請求偽造攻擊，但是有了它能使該攻擊更加容易。這就是存在多種HTML標籤，如果頁面內出現這些標籤，會立刻引起瀏覽器對http[s]資源的訪問，例如影象標籤img便是其中之一。

為簡單起見，我們這裡討論GET方式的URL（不過這裡討論的內容同樣適用於POST請求）。如果受害者已經通過身份驗證，那麼當他提交其它請求時，該cookie也會自動地隨之傳送（如圖，這裡使用者正在訪問www.example.com上的一個應用程式 ）。

圖1  瀏覽器傳送請求的同時還自動傳送cookie

那麼，什麼情況下會引起傳送這個GET請求呢？這可就有多種可能了，首先當用戶正常使用該Web應用程式的過程中有可能引發這個GET請求；其次，當用戶直接在瀏覽器位址列中鍵入該URL時也會引發該GET請求；再者，使用者單擊了指向該URL的連結，即使該連結位於該應用程式外部，也會引發該GET請求。

對於應用程式來說，它是無法區分上面的這些差別的。特別是第三種可能是非常危險的。有許多技術（和漏洞）可以隱藏一個連結的真實屬性。連結可以嵌入電子郵件訊息中，也可以出現在存心不良的Web站點，然後引誘使用者瀏覽該站點，例如連結出現在位於其他主機上（其它Web 站點、HTML格式的電子郵件訊息，等等）的內容中，並且指向應用程式的資源。如果使用者單擊了該連結，由於他已經通過了站點上Web 應用程式的認證，所以瀏覽器就會發出一個GET請求給該Web 應用程式，同時將驗證資訊（包含會話id的cookie）一併發過去。這樣會導致在Web 應用程式上執行一個有效操作——該操作可能不是該使用者所想要的，例如一個引起在網路銀行上進行轉帳惡意的連結，等等。

如前所述，通過使用諸如img之類的標籤，甚至不需要使用者點選具體的連結就能發動攻勢。假設攻擊者向用戶傳送了一封電子郵件，誘騙使用者訪問一個URL，而該URL則指向一個包含下列HTML內容（注意，內容已作精簡）的頁面：

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

用時將[]換成<>

當瀏覽器顯示該頁面時，它也將設法顯示這個指定寬度為0的影象，即該影象是不可見的——這會導致自動向站點中的Web 應用程式傳送一個請求。要緊的是，瀏覽器不管該影象URL實際是否指向一個圖片，只要src欄位中規定了URL，就會按照該地址觸發一個請求。當然，這裡有一個前提，那就是瀏覽器沒有禁止下載影象——實際上瀏覽器都配置成允許下載影象，因為禁用影象後大多數Web應用程式的可用性就會大打折扣。與跨站請求偽造有關的HTML標籤問題是總結如下：

頁面中有許多標籤會導致自動發出HTTP請求（img標籤便是其中之一）；

瀏覽器無法斷定img標籤所引用的資源到底是不是影象以及是否是有害的；

當載入影象時，根本就不考慮所涉及的影象所在的位置，即表單和影象不必位於同一個主機上，甚至可以不再同一個域內。雖然這是一個非常便利的特性，但是卻給應用程式的隔離製造的障礙。正是由於與Web 應用程式無關的HTML內容可以引用應用程式中的各種元件，以及瀏覽器可以自動為該應用程式構造一個有效的請求這兩個事實才導致了這種攻擊的出現。這意味著，正確的URL必須包含使用者會話有關的資訊，而攻擊者卻無法得知這些資訊，因此不可能識別這樣的URL。

對於集成了郵件/瀏覽器功能的工作平臺，跨站請求偽造問題可能更為嚴重，因為，僅僅顯示一封包含該影象的電子郵件就會導致請求及有關瀏覽器cookie一起向Web應用程式發去。

另外，攻擊者還可以對這些東西進行偽裝，例如引用貌似合法的影象URLs，例如

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

用時將()換成<>

這裡，[attacker]是攻擊者控制下的站點，並通過重定向機制將http://[attacker ]/picture. gif轉向http://[thirdparty ]/action。
如果Web應用程式的會話資訊完全靠瀏覽器來提供的話，那麼這樣的Web應用程式也都易於受到攻擊，其中包括那些僅依賴於HTTP身份驗證機制的那些應用程式，因為瀏覽器知道這些驗證資訊，並會在傳送每個請求的時候自動附帶這些驗證資訊。當然，這不包括基於表單的認證，它只發出一次，並且生成了有關會話資訊的表單——當然，如果這樣的資訊就像cookie那樣進行簡單的傳遞的話，這就有回到了之前的情形。

三、跨站請求偽造情景分析

假如受害者已經登入到一個防火牆的Web管理應用程式上。我們知道，當用戶登入時，Web應用會進行身份驗證，通常是要求使用者提供其使用者名稱和密碼，如果使用者名稱和密碼正確則會通過身份認證；隨後，Web應用會在客戶端存放一個小文字檔案，即cookie來存放會話資訊。

假設防火牆有一個基於Web的管理介面，我們稱之為防火牆Web管理程式，其中具有一個這樣功能或者說一個頁面，即允許認證的使用者通過規則編號刪除指定的規則，或者通過輸入“*”刪除全部已配置的規則——這的確是一個非常危險的功能。該刪除頁面顯示如下。假如該表單（我們已經對其進行了簡化）引起一個GET請求，那麼該請求將如下所示

該範例是故意十分天真的，這是為了便於說明CSRF的危險性。刪除防火牆規則的頁面如下所示：

 
圖2  防火牆管理頁面

因此，如果我們鍵入值“*”，並按下刪除按鈕，就會提交下列GET請求：

其結果當然是刪除所有防火牆規則了，呵呵，後果很嚴重呀！如下圖所示：

 
圖3  刪除所有防火牆規則

實際上，這並非唯一可能的情形。使用者也可以手動提交URLhttps://[target ]/fwmgt /delete ?Rule =*來達到相同的效果。或者通過單擊一個直接指向以上URL的連結或通過重定向到達以上URL的連結。或者同樣也可訪問一個嵌入了指向相同的URL的img標籤的HTML頁面。在這些情況下，如果使用者當前已經登入到防火牆管理程式，那麼該請求將得逞並會修改防火牆的配置。

此外，我們還可以設想攻擊是針對敏感的應用程式、進行自動的拍賣投標、轉帳、訂貨、改變關鍵軟體元件的配置等等。

更有趣的是，這些漏洞都可以在防火牆之後進行利用，即只要被攻擊的連結是受害者所能訪問的即可，而不必非得攻擊者能夠直接訪問才行。

尤其是，它可以是任何內部網Web伺服器，例如，之前提到的防火牆管理工作站，它大不可能暴露於國際網際網路。對於那些既可以用作攻擊向量，有是攻擊目標的應用程式（例如web郵件應用程式），情況就更糟了：如果這樣的應用程式是易受攻擊的，那麼使用者閱讀包含CSRF攻擊的信件時很明顯已經登入到程式了，它會以web郵件應用程式為目標，並讓郵件應用程式執行刪除信件、傳送訊息等動作，而這些動作看起來將像是使用者本身所做的。

四、黑盒子測試

為了進行黑盒測試，需要知道受限制的(認證的)區域的URL。如果您具有有效證書，那麼就可以扮演攻擊者和受害者這兩種角色了。在這種情況下，僅僅通過瀏覽應用程式您能獲悉受測試的有關URLs。否則，如果沒有有效的證書可用的話，必須組織一個實際的攻擊，以引誘一個合法的已登入的使用者來點選某個適當的連結，這可以通過社會工程來進行。

不管怎樣，測試案例可以如下構造：

把u改成受測的URL，例如u=http://www.example.com/action

構造一個HTML頁面，讓它包含引用url u（規定全部相關引數；使用GET方式的時候很簡單，如果使用的是POST請求，則需要訴諸於一些JavaScript程式碼）的HTTP請求；

確保合法的使用者已經登入該應用程式；

引誘他點選一個連結，而該連結指向受測試的URL（如果你無法冒充使用者的話，則需要藉助於社會工程）；

觀察結果，如檢測Web伺服器是否執行了該請求。

五、灰盒子測試

對應用程式進行安全評估的時候，要調查其會話管理是否是易受攻擊的。如果會話管理完全依賴於客戶端的值（即對於瀏覽器來說也是可用的），那麼該應用程式是易受攻擊的。通過這些客戶端的值，我們就弄明白了Cookie和HTTP認證證書（基本認證及其他形式的HTTP認證；不是基於表單的認證，即應用程式級別的認證）。對於沒有此弱點的應用程式來說，它在URL中必須包括跟會話session有關資訊，並且要採取一種令使用者無法辨認或者不可預見的形式([3]使用術語secret來表示這種資訊單元)。

可以經由HTTP的GET請求訪問的資源很容易受弱點的影響，但是POST請求可以通過JavaScript實行自動化，並且也易於受到攻擊；因此，單獨使用POST不足以防止CSRF漏洞的發生。

六、跨站請求偽造對策

跨站請求偽造的危害非常之大，所以無論是使用者還是開發人員都應該引起足夠的重視，下面是給Web應用程式終端使用者和Web應用程式開發人員的一些有用的建議。

使用者

因為CSRF漏洞有流行之趨勢，所以建議使用者遵循最佳實踐來降低風險，可以降低風險的習慣包括：

使用Web應用程式之後立即登出

不要讓瀏覽器儲存使用者名稱/口令，也不要讓站點“記住”您不要使用同一個瀏覽器同時訪問敏感的應用程式和隨意衝浪；如果必須同時做多件事情的話，最好單獨使用不同的瀏覽器。

對於支援HTM格式郵件/瀏覽器整合是式軟體以及集成了新聞閱讀程式/瀏覽器的軟體都會帶來額外的風險，因為只要檢視郵件或者新聞就有可能被迫執行一次攻擊，所以使用這類軟體時格外小心。

開發人員

開發人員應當向URL新增跟會話有關資訊。該攻擊型別之所以得逞，是因為會話是由cookie唯一標識的，並且該cookie是由瀏覽器自動傳送的。

如果我們在URL級別為會話生成其它相關資訊，那麼就會給攻擊者為發動攻擊而瞭解URL的結構造成更多的障礙。

至於其它的對策，雖然也無法解決該問題，但是能夠使得利用該漏洞更加困難，例如使用POST而不是GET。雖然POST請求可以通過JavaScript進行模仿，但是它提高了發動這種攻擊的難度。使用中間確認頁也能帶來相同的效果，比如“您確信要這樣做嗎？”之類的頁面。雖然攻擊者可以繞過這些措施，但是這些措施提供了實施攻擊的難度。因此，不能完全依賴這些手段來保護您的應用程式。自動登出機制也能減輕這種攻擊帶來的危害，但這最終依賴於具體情況（一個整天跟有這種漏洞的網路銀行程式打交道的使用者所面臨的風險要遠遠大於臨時使用同一網路銀行的使用者所面臨的風險）。

七、小結

跨站請求偽造，即CSRF，是一種非常危險的Web安全威脅，它被Web安全界稱為“沉睡的巨人”，其威脅程度由此“美譽”便可見一斑。本文不僅對跨站請求偽造本身進行了簡單介紹，還詳細說明造成這種漏洞的原因所在，以及針對該漏洞的黑盒測試與灰盒子測試具體方法和示例，最後提提了一些防範該攻擊的建議，希望本文對讀者的安全測試能夠有所啟發。