讓我們一起來消滅CSRF跨站請求偽造（上）

寫在前面的話

現在已經是2017年了，想必大家一定知道什麼是CSRF（跨站請求偽造）了，因為之前關於這個話題的討論已經有很多了。這種漏洞已經存在了很多年，社區中也有非常詳細的文檔以及對應的解決方案，目前很多熱門的網站開發框架基本上或多或少都實現了相應的緩解方案。

那我們在本系列文章中要討論什麼呢？請大家先思考以下幾個因素：

1） 遺留應用缺少CSRF保護；

2） 某些框架的內置CSRF防護機制存在缺陷；

3） 應用程序沒有使用已證明安全的框架保護機制；

4） 新的應用程序沒有使用提供了CSRF保護功能的現代框架；

因此，對於目前的Web應用程序來說，CSRF仍然是一個相對普遍存在的安全漏洞。

在這篇文章中，我們首先會跟大家深入分析CSRF的工作機制，以及現代應用程序可以採用的安全措施。接下來，我們會給大家提供一份安全解決方案，同學們可以將其用於自己所開發的應用程序之中（不需要對源代碼進行任何修改）。最後，我們會給大家測試一種針對cookie的新型擴展，如果它能夠成為一種通用標準的話，它將能夠消除絕大多數場景下的跨站腳本漏洞。除此之外，我們在GitHub庫中提供了本系列文章中所要使用到的代碼以及測試樣例，有需要的同學可以自行下載。

了解攻擊機制

簡而言之，CSRF這種漏洞將允許攻擊者強迫目標用戶代表攻擊者發送HTTP請求。這種攻擊主要發生在客戶端（例如Web瀏覽器），而在這種場景下目標用戶所發送的應用程序信息是完全可信的，因此攻擊者就可以成功實現攻擊了。對於這種類型的攻擊，我們需要關注以下三個因素：使用不安全的HTTP verb ，Web瀏覽器對cookie的處理、以及跨站腳本漏洞（XSS）。

HTTP標準將verb主要分成了安全的以及不安全的兩大類。安全的verb（GET、HEAD以及OPTIONS）主要用於只讀操作，使用了這些verb的請求用於返回與被請求資源有關的信息，並且不會對伺服器端產生影響。不安全的verb（POST、PUT、PATCH和DELETE）主要用於對資源進行修改、創建和刪除操作。但不幸的是，一個HTTP verb本身所要進行的操作是可以被忽略或者被篡改的。

導致HTTP verb使用不當的主要原因在於瀏覽器對HTTP標準的支持存在缺陷，這是一種歷史遺留問題。在XML HTTP Request(XHR)流行起來之前，我們幾乎得依靠特定框架和代碼庫來使用HTTP verb（除了GET和POST之外）。這種限制導致HTTP verb之間的區別界限變得十分模糊，雖然僅憑這一點並不能創建出CSRF的攻擊場景，但這也讓針對CSRF的保護變得更加難以實現了。對CSRF漏洞「幫助」最大的一個因素，就是瀏覽器處理cookie的方式了。

在設計之初，HTTP本身是一種無狀態協議，即一個請求對應一個響應，請求之間不攜帶/交換任何的狀態信息。為了支持複雜的Web應用程序，cookie就成為了一個維持相關HTTP請求之間狀態的解決方案。瀏覽器的全局Cookie可以跨實例、窗口和標籤進行共享，用戶需要依賴於Web瀏覽器來自動化地給每一個請求發送cookie。由於cookie是可以在瀏覽器中進行訪問或修改的，並且缺乏反篡改保護，因此請求狀態的保存任務就轉移到了伺服器管理會話的身上。在這種模型下，伺服器端需要生成一個唯一標識符並將其存儲到cookie中。每一個瀏覽器在發送cookie時都需要發送這個唯一標識符，而伺服器端就可以根據這種標識符來判斷會話的有效性了。當會話終止之後，伺服器端會丟棄這個標識符，之後使用該標識符的請求都將會被視為無效請求。

現在的主要問題是，瀏覽器如何去管理cookie。cookie主要由一系列屬性組成，但其中最重要的是Domain屬性。Domain屬性的功能是將cookie限定到某個匹配domain屬性的特定主機範圍內，這是一種用於防止敏感信息（例如會話識別符）被惡意網站竊取（會話固定攻擊）的安全機制。這裡存在的漏洞是domain屬性並不用遵循同源策略（SOP），它只會對cookie以及請求中伺服器的domain值進行簡單的對比。這也就意味著，任何不同源的請求只需要帶有該主機的cookie，就可以向其發送請求了。在這種場景下，只有安全的以及不安全的HTTP verb能夠得到正確使用，才能確保這種行為是安全的。關於同源策略的更多詳細內容，請參考這篇文檔。

最後一個需要關心的因素，就是跨站腳本（XSS）漏洞。XSS指的是攻擊者控制JavaScript或HTML來給目標用戶呈現DOM內容的能力。如果某個應用程序中存在XSS漏洞的話，那這個應用此時幾乎就無法再抵禦CSRF攻擊了。如果XSS漏洞存在的話，本文所要介紹的以及目前絕大多數應用程序所依賴的應對措施就完全沒有用了。

執行攻擊

既然我們已經了解到了攻擊成功所涉及到的相關因素，我們就可以繼續深入了解CSRF的工作機制了。如果你還沒有搭建好測試環境的話，請現在趕緊按照之前提供的GitHub庫中的方法（參考README文檔）來搭建環境並運行樣本。

我們所要討論的主要有以下三種CSRF：

1.資源包含（Resource inclusion）

2.Form-based

3.XMLHttpRequest

在絕大多數關於CSRF的演示樣例或者基礎課程之中，資源包含是這種類型是最常見的。這種類型的CSRF允許攻擊者控制一個HTML標籤中包含的資源，例如圖片、視頻、音頻、對象、以及腳本等等。如果攻擊者能夠影響頁面所載入的URL，則任何包含了遠程資源的標籤都將可以被攻擊者所利用。正如之前所說的，由於缺乏同源檢測，這種攻擊並不需要XSS，而且任何能夠控制目標網站的攻擊者都能夠實現攻擊。這種類型的漏洞僅限適用於GET請求，因為這種請求是瀏覽器專門用來請求資源URL的，而且這種漏洞的限制就在於它要求不當使用安全的HTTP verb。

第二種類型是基於表單（form-based）的CSRF，一般出現在安全verb使用正確的情況下。在這種攻擊場景中，攻擊者要自行創建一個表單並欺騙用戶提交該表單。表單中包含一段能夠強迫瀏覽器提交該表單的JavaScript代碼段，它不僅全部由隱藏元素組成，而且提交速度非常快，所以目標用戶幾乎無法察覺到。由於瀏覽器處理cookie的方式存在問題，因此這種表單可以託管在任何一個網站上，只要用戶用有效的cookie完成了登錄，攻擊就能成功。第二種漏洞配合釣魚攻擊是比較好的。

我們所要討論的最後一種類型即XMLHttpRequest（XHR），而這種情況是比較少見的，因為利用這種漏洞時所要滿足的條件太多了。由於很多現代Web應用程序都依賴於XHR，因此我們需要花很多事件來構建並實現這種特定的應對措施。由於同源策略的存在，基於XHR的CSRF一般都是通過XSS Payload的形式來利用的。如果沒有跨域資源共享（CORS），XHR將只能被限制於向特定源發送請求，這樣也就限制了攻擊者託管自己Payload的途徑。這種漏洞的攻擊Payload其實是一種標準XHR，攻擊者可以想辦法將其注入到目標用戶瀏覽器的頁面DOM中。

總結

在接下來的系列文章中，我們將會給大家介紹如何在真實的開發環境之中部署最有效的CSRF解決方案，感興趣的同學可以及時關注安全客的最新文章。