建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
背景
1、什么是CSRF攻擊?
這里不再介紹CSRF，已經(jīng)了解CSRF原理的同學(xué)可以直接跳到：“3、前后端分離下有何不同?”。
不太了解的同學(xué)可以看這兩篇對(duì)CSRF介紹比較詳細(xì)的參考文章：
- CSRF 攻擊的應(yīng)對(duì)之道
- 淺談CSRF攻擊方式
如果來(lái)不及了解CSRF的原理，可以這么理解：有一個(gè)人發(fā)給你一個(gè)搞(mei)笑(nv)圖片鏈接，你打開(kāi)這個(gè)鏈接之后，便立刻收到了短信：你的銀行里的錢(qián)已經(jīng)轉(zhuǎn)移到這個(gè)人的帳戶(hù)了。
2、有哪些防御方案?
上面這個(gè)例子當(dāng)然有點(diǎn)危言聳聽(tīng)，當(dāng)然可以確定的是確實(shí)會(huì)有這樣的漏洞：你打開(kāi)了一個(gè)未知域名的鏈接，然后你就自動(dòng)發(fā)了條廣告帖子、你的Gmail的郵件內(nèi)容就泄露了、你的百度登錄狀態(tài)就沒(méi)了……
防御方案在上面的兩篇文章里也有提到，總結(jié)下，無(wú)外乎三種：
- 用戶(hù)操作限制，比如驗(yàn)證碼;
- 請(qǐng)求來(lái)源限制，比如限制HTTP Referer才能完成操作;
- token驗(yàn)證機(jī)制，比如請(qǐng)求數(shù)據(jù)字段中添加一個(gè)token，響應(yīng)請(qǐng)求時(shí)校驗(yàn)其有效性;
第一種方案明顯嚴(yán)重影響了用戶(hù)體驗(yàn)，而且還有額外的開(kāi)發(fā)成本;第二種方案成本最低，但是并不能保證100%安全，而且很有可能會(huì)埋坑;第三種方案，可取!
token驗(yàn)證的CSRF防御機(jī)制是公認(rèn)最合適的方案，也是本文討論的重點(diǎn)。
3、前后端分離下有何不同?
《CSRF 攻擊的應(yīng)對(duì)之道》這篇文章里有提到：
要把所有請(qǐng)求都改為 XMLHttpRequest 請(qǐng)求，這樣幾乎是要重寫(xiě)整個(gè)網(wǎng)站，這代價(jià)無(wú)疑是不能接受的
我們前端架構(gòu)早已經(jīng)告別了服務(wù)端語(yǔ)言(PHP/JAVA等)綁定路由、攜帶數(shù)據(jù)渲染模板引擎的方式(畢竟是2011年的文章了，我們笑而不語(yǔ))。
當(dāng)然， 前端不要高興的太早：前后端分離之后，Nodejs不具備完善的服務(wù)端SESSION、數(shù)據(jù)庫(kù)等功能。
總結(jié)一下，在“更先進(jìn)”的前端架構(gòu)下，與以往的架構(gòu)會(huì)有一些區(qū)別：
- Nodejs層不處理SESSION，無(wú)法直接實(shí)現(xiàn)會(huì)話(huà)狀態(tài)數(shù)據(jù)保存;
- 所有的數(shù)據(jù)通過(guò)Ajax異步獲取，可以靈活實(shí)現(xiàn)token方案;
實(shí)現(xiàn)思路
如上文提到，這里僅僅討論在“更先進(jìn)”的前端后端架構(gòu)背景下的token防御方案的實(shí)現(xiàn)。
1、可行性方案
token防御的整體思路是：
- 第一步：后端隨機(jī)產(chǎn)生一個(gè)token，把這個(gè)token保存在SESSION狀態(tài)中;同時(shí)，后端把這個(gè)token交給前端頁(yè)面;
- 第二步：下次前端需要發(fā)起請(qǐng)求(比如發(fā)帖)的時(shí)候把這個(gè)token加入到請(qǐng)求數(shù)據(jù)或者頭信息中，一起傳給后端;
- 第三步：后端校驗(yàn)前端請(qǐng)求帶過(guò)來(lái)的token和SESSION里的token是否一致;
上文提到過(guò)，前后端分離狀態(tài)下，Nodejs是不具備SESSION功能的。那這種token防御機(jī)制是不是就無(wú)法實(shí)現(xiàn)了呢?
肯定不是。我們可以借助cookie把這個(gè)流程升級(jí)下：
- 第一步：后端隨機(jī)產(chǎn)生一個(gè)token，基于這個(gè)token通過(guò)SHA-56等散列算法生成一個(gè)密文;
- 第二步：后端將這個(gè)token和生成的密文都設(shè)置為cookie，返回給前端;
- 第三步：前端需要發(fā)起請(qǐng)求的時(shí)候，從cookie中獲取token，把這個(gè)token加入到請(qǐng)求數(shù)據(jù)或者頭信息中，一起傳給后端;
- 第四步：后端校驗(yàn)cookie中的密文，以及前端請(qǐng)求帶過(guò)來(lái)的token，進(jìn)行正向散列驗(yàn)證;
當(dāng)然這樣實(shí)現(xiàn)也有需要注意的：
- 散列算法都是需要計(jì)算的，這里會(huì)有性能風(fēng)險(xiǎn);
- token參數(shù)必須由前端處理之后交給后端，而不能直接通過(guò)cookie;
- cookie更臃腫，會(huì)不可避免地讓頭信息更重;
現(xiàn)在方案確定了，具體該如何實(shí)現(xiàn)呢?
2、具體實(shí)現(xiàn)
我們的技術(shù)棧是 koa(服務(wù)端) + Vue.js(前端) 。有興趣可以看這些資料：
- 趣店前端團(tuán)隊(duì)基于koajs的前后端分離實(shí)踐
- koa-grace——基于koa的標(biāo)準(zhǔn)前后端分離框架
- grace-vue-webpack-boilerplate
在服務(wù)端，實(shí)現(xiàn)了一個(gè)token生成的中間件，koa-grace-csrf：
- // 注意：代碼有做精簡(jiǎn)
- const tokens = require('./lib/tokens');
- return function* csrf(next) {
- let curSecret = this.cookies.get('密文的cookie');
- // 其他如果要獲取參數(shù)，則為配置參數(shù)值
- let curToken = '請(qǐng)求http頭信息中的token';
- // token不存在
- if (!curToken || !curSecret) {
- return this.throw('CSRF Token Not Found!',403)
- }
- // token校驗(yàn)失敗
- if (!tokens.verify(curSecret, curToken)) {
- return this.throw('CSRF token Invalid!',403)
- }
- yield next;
- // 無(wú)論何種情況都種兩個(gè)cookie
- // cookie_key: 當(dāng)前token的cookie_key,httpOnly
- let secret = tokens.secretSync();
- this.cookies.set(options.cookie_key, secret);
- // cookie_token: 當(dāng)前token的的content，不需要httpOnly
- let newToken = tokens.create(secret);
- this.cookies.set(options.cookie_token, newToken)
- }
在前端代碼中，對(duì)發(fā)送ajax請(qǐng)求的封裝稍作優(yōu)化：
- this.$http.post(url, data, {
- headers: {
- 'http請(qǐng)求頭信息字段名': 'cookie中的token'
- }
- }).then((res) => {})
總結(jié)一下：
- Nodejs生成一個(gè)隨機(jī)數(shù)，通過(guò)隨機(jī)數(shù)生成散列密文;并將隨機(jī)數(shù)和密文存到cookie;
- 客戶(hù)端JS獲取cookie中的隨機(jī)數(shù)，通過(guò)http頭信息交給Nodejs;
- Nodejs響應(yīng)請(qǐng)求，校驗(yàn)cookie中的密文和頭信息中的隨機(jī)數(shù)是否匹配;
這里依舊有個(gè)細(xì)節(jié)值得提一下：Nodejs的上層一般是nginx，而nginx默認(rèn)會(huì)過(guò)濾頭信息中不合法的字段(比如頭信息字段名包含“_”的)，這里在寫(xiě)頭信息的時(shí)候需要注意。
上文也提到，通過(guò)cookie及http頭信息傳遞加密token會(huì)有很多弊端;有沒(méi)有更優(yōu)雅的實(shí)現(xiàn)方案呢?
3、更優(yōu)雅的架構(gòu)
首先，我們明確前后端分離的一些基本原則：
后端(Java / PHP )職責(zé)：
- 服務(wù)層顆?；涌?，以便前端Nodejs層異步并發(fā)調(diào)用;
- 用戶(hù)狀態(tài)保存，實(shí)現(xiàn)用戶(hù)權(quán)限等各種功能;
前端(Nodejs + Javascript)職責(zé)：
- Nodejs層完成路由托管及模板引擎渲染功能
- Nodejs層不負(fù)責(zé)實(shí)現(xiàn)任何SESSION和數(shù)據(jù)庫(kù)功能
我們提到，前端Nodejs層不負(fù)責(zé)實(shí)現(xiàn)任何SESSION和數(shù)據(jù)庫(kù)功能，但有沒(méi)有可能把后端緩存系統(tǒng)做成公共服務(wù)提供給Nodejs層使用呢?想想感覺(jué)前端整條路都亮了有木有?!這里先挖一個(gè)坑，后續(xù)慢慢填。
4、延伸
這里再順便提一下，新架構(gòu)下的XSS防御。
猶記得，在狼廠(chǎng)使用PHP的年代，經(jīng)常被安全部門(mén)曝出各類(lèi)XSS漏洞，然后就在smaty里添加各種escape濾鏡，但是添加之后發(fā)現(xiàn)竟然把原始數(shù)據(jù)也給轉(zhuǎn)義了。
當(dāng)然，現(xiàn)在更多要?dú)w功于各種MVVM單頁(yè)面應(yīng)用：使得前端完全不需要通過(guò)讀取URL中的參數(shù)來(lái)控制VIEW。
不過(guò)，還有一點(diǎn)值得一提：前后端分離框架下，路由由Nodejs控制;我自己要獲取的后端參數(shù)和需要用在業(yè)務(wù)邏輯的參數(shù)，在主觀(guān)上前端同學(xué)更好把握一些。
所以， 在koa(服務(wù)端) + Vue.js(前端)架構(gòu)下基本不用顧慮XSS問(wèn)題(至少不會(huì)被全安組追著問(wèn)XSS漏洞啥時(shí)候修復(fù))。
總結(jié)
要不學(xué)PHP、看Java、玩Python做全棧好了?
網(wǎng)頁(yè)標(biāo)題：前后端分離架構(gòu)下CSRF防御機(jī)制
URL鏈接：http://www.5511xx.com/article/coishop.html
