本文直接從防御方式開始討論，防御CSRF有4種方法：
使用POST替代GET
檢驗HTTP Referer
驗證碼
Token
一些程序員在開發(fā)的時候都是用GET、POST通用的函數(shù)來接收客戶端的數(shù)據(jù)，這樣也是某些接口有CSRF的原因之一，但是將全部接口都改成只允許POST方式訪問，就能防范CSRF了嗎？答案是：不能。只能說提高了一些成本。
原本是GET方式訪問的接口，攻擊者只需要構(gòu)造接口的URL參數(shù)讓受害者點擊即可?，F(xiàn)在改成使用POST方式訪問，攻擊者只需要利用其他站點，在站點上布置一個POST請求，讓用戶點擊。
HTTP Referer真是一個用于安全的字段，除了能防范CSRF，還能防JSONP劫持、盜鏈、站外提交等安全問題。但是HTTP Referer就一點問題都沒有了嗎？答案是：否定的，HTTP Referer只能檢查點擊的鏈接來源是來自站內(nèi)還是站外，如果是GET方式的CSRF，那鏈接本身就是站內(nèi)的，也就意味著檢驗HTTP Referer是無效的。
上面說的兩種防御CSRF的方式，都有一定缺陷。但是使用驗證碼是完全可以做到防止CSRF的，因為驗證碼是用戶在提交表單的時候，必須輸入圖片驗證碼，保證了服務(wù)器收到的是來自預(yù)期的請求。這里我補充一下，驗證碼功能必須沒有缺陷才行，我之前測試過很多WEB站點，驗證碼或多或少有問題，這樣不但不能防止CSRF，甚至?xí)l(fā)出其他漏洞被利用。
下面我用前端抓包的方式來觀察百度的發(fā)送圖片驗證碼的流程：
（假設(shè)我這里操作一個修改密碼操作）我請求了一次修改密碼接口后，該接口就會返回圖片驗證碼資源回到瀏覽器并展示出來，發(fā)送修改密碼表單時需要用戶填寫圖片驗證碼，然后將修改的一起發(fā)送到服務(wù)器去校驗。
這樣就保證了攻擊者無法預(yù)知與偽造請求中的veritycode參數(shù)。
那么驗證碼有什么缺點嗎？在用戶體驗上，如果一個網(wǎng)站很多功能都需要輸入驗證碼才能發(fā)送，那么無疑非常影響用戶體驗。
Token和驗證碼的原理非常相似，只不過在使用上，驗證碼是非常需要用戶交互的，但是Token基本是無感知的。
根據(jù)Token加入請求的方式，又可以分為三種類型：
Cookie Token
HTTP頭自定義屬性Token
表單Token
類似圖片驗證碼一樣，每次請求的功能接口時，都通過響應(yīng)頭的Set-Cookie，將token存儲到本地cookie中。
Set-Cookie: RePassToken=0123456789 expires=Thu, 04-Apr-2019 15:11:32 GMT; path=/; domain=passport.baidu.com; httponly
先申明前端要在請求頭里面添加自定義參數(shù)，必須后臺允許，否則請求會報錯。
這里以vue-resource請求為例，前端的方法，全局配置請求頭，在main.js里面設(shè)置：
Vue.http.interceptors.push((request, next) => {
request.headers.set('HTTP_Token', '1234567890'); // 在請求里面添加了token
next((response) => { return response })
})這里以PHP舉例，服務(wù)器端將http頭數(shù)據(jù)都放在全局數(shù)據(jù)_SERVER里，參數(shù)都以HTTP開頭，例如：
# 客戶端在http頭里添加了HTTP_Token參數(shù)， 服務(wù)器端可這樣讀取
if(array_key_exists('HTTP_Token', $_SERVER)) {
$token = $_SERVER['HTTP_Token'];
}我直接講這個方式的缺點，使用HTTP頭定義屬性的方式來修復(fù)CSRF還是比較少的，因為現(xiàn)在的前端和后端的開發(fā)基本都是兩個獨立的團隊，安全部門為了修復(fù)一個低位漏洞CSRF就要溝通兩個部門，還是修改前端和后端兩處地方，顯然不是一個最優(yōu)解。畢竟還是有很多其他低成本的方式可以使用。
這個表單可以是GET、POST，每個表單，請求都得包含一個token，才能使用功能。下面觀察一下百度的個人中心的token使用流程。
如果修改了token發(fā) 請求，那么將不能得到正常的響應(yīng)文了。
以上說的幾種防護方式各有利弊，需要注意的是，如果網(wǎng)站還存在著其他安全漏洞，比如XSS，那么攻擊者還是能夠通過JS取到Token進行攻擊的。
