讓我們一起來消滅CSRF跨站請求偽造（上）
寫在前面的話
現在已經是2017年了，想必大家一定知道什么是CSRF(跨站請求偽造)了，因為之前關于這個話題的討論已經有很多了。這種漏洞已經存在了很多年，社區中也有非常詳細的文檔以及對應的解決方案，目前很多熱門的網站開發框架基本上或多或少都實現了相應的緩解方案。
那我們在本系列文章中要討論什么呢?請大家先思考以下幾個因素：
- 遺留應用缺少CSRF保護;
- 某些框架的內置CSRF防護機制存在缺陷;
- 應用程序沒有使用已證明安全的框架保護機制;
- 新的應用程序沒有使用提供了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：
- 資源包含(Resource inclusion)
- Form-based
- 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解決方案.
