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