4.4　抵御CSRF攻擊

你可以通過多種方式修補CSRF漏洞。一種最為流行的抵御CSRF攻擊的方式就是采用CSRF令牌。當受保護的站點接收到瀏覽器提交的有可能修改數據（例如POST請求）的請求時，需要驗證CSRF令牌。在這種情況下，Web應用（就如Bob的網銀）將會產生一個由兩部分組成的令牌：一部分由Bob接收，而另一部分由應用保留。當Bob試著發起轉賬請求時，他將會提交他的那部分令牌，網銀將把該部分令牌與它保存的那部分令牌合在一起進行令牌有效性驗證。這種基于令牌的設計使得令牌很難被猜測，并且只有被分配了令牌的特定用戶（例如，Bob）才有權限訪問。另外，這些令牌不總是顯式命名的，但有一些潛在的命名例子，例如X-CSRF-TOKEN、lia-token、rt、form-id等。令牌可以存放在HTTP請求頭、HTTP POST體或者隱藏域中，如下例所示：

在本例中，網站可以通過cookie、嵌入網站中的一段腳本或者網站中傳輸的部分內容來獲取CSRF令牌。不管網站如何獲取令牌，僅有授權的目標瀏覽器能夠知道和讀取令牌的內容。因為攻擊者不能提交令牌，所以他們不能成功地提交POST請求，也就不能執行CSRF攻擊。然而，在尋找可以利用漏洞的過程中，并不會因為網站使用了CSRF令牌，就使整個過程進入一個死胡同。黑客可能會嘗試刪除令牌、修改令牌的值等以確保服務器認為令牌已經被正確實現。

另外一種抵御CSRF攻擊的方式是采用CORS，然而，這并不是萬無一失的，因為它依賴于瀏覽器的安全性，并確保已經進行了正確的CORS配置來限定第三方站點何時可以訪問響應信息。攻擊者有時可以通過修改內容類型application/json為application/x-www-form-urlencoded，或者因為服務器端存在誤配置而使用GET請求而不是POST請求來繞過CORS。這種繞過行為能夠發生，是因為當內容類型是application/json時，瀏覽器會自動發送一個OPTIONS HTTP請求，而如果請求是GET請求或者內容類型是application/x-www-form-urlencoded時，瀏覽器不會自動發起OPTIONS HTTP請求。

最后，還有兩種很少用到的CSRF防御策略。第一種，網站會檢查提交的HTTP請求中Origin或者Referer頭中是否包含期望的特定值。例如，在有些情況下，Twitter會檢查Origin頭信息，如果該頭信息不存在，就會檢查Referer頭信息。這能夠產生防御效果主要是因為瀏覽器控制這些頭部信息，但攻擊者不能遠程設置或修改這些信息（顯然，我們不考慮黑客利用瀏覽器或者瀏覽器插件中的漏洞，從而修改以上兩個頭部信息的情況）。第二種，瀏覽器現在正開始實現對一種新的cookie屬性samesite的支持。這一屬性可以被設置為strict或lax。當設置為strict時，對于不是源自被保護網站的任何HTTP請求，瀏覽器都不會發送cookie，這包括最簡單的HTTP GET請求的情況。例如，如果你登錄了亞馬遜（Amazon）網站，并且該網站使用了strict samesite cookie，那么當你通過來自另一個網站的鏈接訪問亞馬遜網站時，瀏覽器并不會提交你的cookie。而且，亞馬遜也不會認為你已經登錄了，除非你再訪問另一個亞馬遜的Web網頁時，cookie才再次被提交。相反，設置samesite屬性為lax表示要求瀏覽器發送cookie時要帶上初始的GET請求信息。這種設計原則基于GET請求永遠不會修改服務器端的數據。在這種情形下，如果你已經登錄了亞馬遜，并使用了lax samesite cookie，當你從別的網站重定向到亞馬遜網站時，瀏覽器將會提交你的cookie，并且亞馬遜也會認為你已經登錄過了。