讓我們一起來消滅CSRF跨站請求偽造（上）
寫在前面的話
現(xiàn)在已經(jīng)是2017年了，想必大家一定知道什么是CSRF(跨站請求偽造)了，因為之前關(guān)于這個話題的討論已經(jīng)有很多了。這種漏洞已經(jīng)存在了很多年，社區(qū)中也有非常詳細(xì)的文檔以及對應(yīng)的解決方案，目前很多熱門的網(wǎng)站開發(fā)框架基本上或多或少都實現(xiàn)了相應(yīng)的緩解方案。
那我們在本系列文章中要討論什么呢?請大家先思考以下幾個因素：
- 遺留應(yīng)用缺少CSRF保護(hù);
- 某些框架的內(nèi)置CSRF防護(hù)機制存在缺陷;
- 應(yīng)用程序沒有使用已證明安全的框架保護(hù)機制;
- 新的應(yīng)用程序沒有使用提供了CSRF保護(hù)功能的現(xiàn)代框架;
因此，對于目前的Web應(yīng)用程序來說，CSRF仍然是一個相對普遍存在的安全漏洞。
在這篇文章中，我們首先會跟大家深入分析CSRF的工作機制，以及現(xiàn)代應(yīng)用程序可以采用的安全措施。接下來，我們會給大家提供一份安全解決方案，同學(xué)們可以將其用于自己所開發(fā)的應(yīng)用程序之中(不需要對源代碼進(jìn)行任何修改)。最后，我們會給大家測試一種針對cookie的新型擴展，如果它能夠成為一種通用標(biāo)準(zhǔn)的話，它將能夠消除絕大多數(shù)場景下的跨站腳本漏洞。除此之外，我們在GitHub庫中提供了本系列文章中所要使用到的代碼以及測試樣例，有需要的同學(xué)可以自行下載。
了解攻擊機制
簡而言之，CSRF這種漏洞將允許攻擊者強迫目標(biāo)用戶代表攻擊者發(fā)送HTTP請求。這種攻擊主要發(fā)生在客戶端(例如Web瀏覽器)，而在這種場景下目標(biāo)用戶所發(fā)送的應(yīng)用程序信息是完全可信的，因此攻擊者就可以成功實現(xiàn)攻擊了。對于這種類型的攻擊，我們需要關(guān)注以下三個因素：使用不安全的HTTP verb ，Web瀏覽器對cookie的處理、以及跨站腳本漏洞(XSS)。
HTTP標(biāo)準(zhǔn)將verb主要分成了安全的以及不安全的兩大類。安全的verb(GET、HEAD以及OPTIONS)主要用于只讀操作，使用了這些verb的請求用于返回與被請求資源有關(guān)的信息，并且不會對服務(wù)器端產(chǎn)生影響。不安全的verb(POST、PUT、PATCH和DELETE)主要用于對資源進(jìn)行修改、創(chuàng)建和刪除操作。但不幸的是，一個HTTP verb本身所要進(jìn)行的操作是可以被忽略或者被篡改的。
導(dǎo)致HTTP verb使用不當(dāng)?shù)闹饕蛟谟跒g覽器對HTTP標(biāo)準(zhǔn)的支持存在缺陷，這是一種歷史遺留問題。在XML HTTP Request(XHR)流行起來之前，我們幾乎得依靠特定框架和代碼庫來使用HTTP verb(除了GET和POST之外)。這種限制導(dǎo)致HTTP verb之間的區(qū)別界限變得十分模糊，雖然僅憑這一點并不能創(chuàng)建出CSRF的攻擊場景，但這也讓針對CSRF的保護(hù)變得更加難以實現(xiàn)了。對CSRF漏洞“幫助”最大的一個因素，就是瀏覽器處理cookie的方式了。
在設(shè)計之初，HTTP本身是一種無狀態(tài)協(xié)議，即一個請求對應(yīng)一個響應(yīng)，請求之間不攜帶/交換任何的狀態(tài)信息。為了支持復(fù)雜的Web應(yīng)用程序，cookie就成為了一個維持相關(guān)HTTP請求之間狀態(tài)的解決方案。瀏覽器的全局Cookie可以跨實例、窗口和標(biāo)簽進(jìn)行共享，用戶需要依賴于Web瀏覽器來自動化地給每一個請求發(fā)送cookie。由于cookie是可以在瀏覽器中進(jìn)行訪問或修改的，并且缺乏反篡改保護(hù)，因此請求狀態(tài)的保存任務(wù)就轉(zhuǎn)移到了服務(wù)器管理會話的身上。在這種模型下，服務(wù)器端需要生成一個唯一標(biāo)識符并將其存儲到cookie中。每一個瀏覽器在發(fā)送cookie時都需要發(fā)送這個唯一標(biāo)識符，而服務(wù)器端就可以根據(jù)這種標(biāo)識符來判斷會話的有效性了。當(dāng)會話終止之后，服務(wù)器端會丟棄這個標(biāo)識符，之后使用該標(biāo)識符的請求都將會被視為無效請求。
現(xiàn)在的主要問題是，瀏覽器如何去管理cookie。cookie主要由一系列屬性組成，但其中最重要的是Domain屬性。Domain屬性的功能是將cookie限定到某個匹配domain屬性的特定主機范圍內(nèi)，這是一種用于防止敏感信息(例如會話識別符)被惡意網(wǎng)站竊取(會話固定攻擊)的安全機制。這里存在的漏洞是domain屬性并不用遵循同源策略(SOP)，它只會對cookie以及請求中服務(wù)器的domain值進(jìn)行簡單的對比。這也就意味著，任何不同源的請求只需要帶有該主機的cookie，就可以向其發(fā)送請求了。在這種場景下，只有安全的以及不安全的HTTP verb能夠得到正確使用，才能確保這種行為是安全的。關(guān)于同源策略的更多詳細(xì)內(nèi)容，請參考這篇文檔。
最后一個需要關(guān)心的因素，就是跨站腳本(XSS)漏洞。XSS指的是攻擊者控制JavaScript或HTML來給目標(biāo)用戶呈現(xiàn)DOM內(nèi)容的能力。如果某個應(yīng)用程序中存在XSS漏洞的話，那這個應(yīng)用此時幾乎就無法再抵御CSRF攻擊了。如果XSS漏洞存在的話，本文所要介紹的以及目前絕大多數(shù)應(yīng)用程序所依賴的應(yīng)對措施就完全沒有用了。
執(zhí)行攻擊
既然我們已經(jīng)了解到了攻擊成功所涉及到的相關(guān)因素，我們就可以繼續(xù)深入了解CSRF的工作機制了。如果你還沒有搭建好測試環(huán)境的話，請現(xiàn)在趕緊按照之前提供的GitHub庫中的方法(參考README文檔)來搭建環(huán)境并運行樣本。
我們所要討論的主要有以下三種CSRF：
- 資源包含(Resource inclusion)
- Form-based
- XMLHttpRequest
在絕大多數(shù)關(guān)于CSRF的演示樣例或者基礎(chǔ)課程之中，資源包含是這種類型是最常見的。這種類型的CSRF允許攻擊者控制一個HTML標(biāo)簽中包含的資源，例如圖片、視頻、音頻、對象、以及腳本等等。如果攻擊者能夠影響頁面所加載的URL，則任何包含了遠(yuǎn)程資源的標(biāo)簽都將可以被攻擊者所利用。正如之前所說的，由于缺乏同源檢測，這種攻擊并不需要XSS，而且任何能夠控制目標(biāo)網(wǎng)站的攻擊者都能夠?qū)崿F(xiàn)攻擊。這種類型的漏洞僅限適用于GET請求，因為這種請求是瀏覽器專門用來請求資源URL的，而且這種漏洞的限制就在于它要求不當(dāng)使用安全的HTTP verb。
第二種類型是基于表單(form-based)的CSRF，一般出現(xiàn)在安全verb使用正確的情況下。在這種攻擊場景中，攻擊者要自行創(chuàng)建一個表單并欺騙用戶提交該表單。表單中包含一段能夠強迫瀏覽器提交該表單的JavaScript代碼段，它不僅全部由隱藏元素組成，而且提交速度非常快，所以目標(biāo)用戶幾乎無法察覺到。由于瀏覽器處理cookie的方式存在問題，因此這種表單可以托管在任何一個網(wǎng)站上，只要用戶用有效的cookie完成了登錄，攻擊就能成功。第二種漏洞配合釣魚攻擊是比較好的。
我們所要討論的最后一種類型即XMLHttpRequest(XHR)，而這種情況是比較少見的，因為利用這種漏洞時所要滿足的條件太多了。由于很多現(xiàn)代Web應(yīng)用程序都依賴于XHR，因此我們需要花很多事件來構(gòu)建并實現(xiàn)這種特定的應(yīng)對措施。由于同源策略的存在，基于XHR的CSRF一般都是通過XSS Payload的形式來利用的。如果沒有跨域資源共享(CORS)，XHR將只能被限制于向特定源發(fā)送請求，這樣也就限制了攻擊者托管自己Payload的途徑。這種漏洞的攻擊Payload其實是一種標(biāo)準(zhǔn)XHR，攻擊者可以想辦法將其注入到目標(biāo)用戶瀏覽器的頁面DOM中。
總結(jié)
在接下來的系列文章中，我們將會給大家介紹如何在真實的開發(fā)環(huán)境之中部署最有效的CSRF解決方案.
