鍍金池/ 問(wèn)答/Java  HTML/ jwt 怎么防止 csrf

jwt 怎么防止 csrf

小弟我最近看了 jwt 的使用,在自己寫(xiě)的小項(xiàng)目里也用了 jwt 作為單點(diǎn)登錄驗(yàn)證等,后端是 nodejs。我想到了 csrf,csrf 和 jwt 的原理我也知道的差不多了,但是我的疑惑是采用 JWT 的形式可以防止 CSRF 嗎? 我現(xiàn)在用 postman 去請(qǐng)求我的接口,如果 postman 的 header 里面不放我的 token(這個(gè) token 是我現(xiàn)在開(kāi)發(fā)的頁(yè)面正常登陸上去后端返回到前端的 token) 的話確實(shí)顯示的是 token 不存在不返回?cái)?shù)據(jù)。 但我在瀏覽器的 localStorage 里面把我存的 token 拷出來(lái)放在 postman header 里面去請(qǐng)求,就成功了。那豈不是 jwt 防不了 CSRF 嗎,存在前端的 token 誰(shuí)都可以拿呀,拿了之后帶著請(qǐng)求豈不是就ok 了?

這個(gè)問(wèn)題真的很困擾我,請(qǐng)各位大哥不吝賜教~

回答
編輯回答
不舍棄

你是不是對(duì)CSRF和JWT有什么誤解。

JWT只是一個(gè)身份驗(yàn)證的憑證,和你用去防范CSRF并不矛盾,你完全可以在JWT之上加上防范CSRF的措施,比如檢查Referer字段和添加校驗(yàn)token(即CSRF Token)。

檢查Referer字段

HTTP頭中有一個(gè)Referer字段,這個(gè)字段用以標(biāo)明請(qǐng)求來(lái)源于哪個(gè)地址。在處理敏感數(shù)據(jù)請(qǐng)求時(shí),通常來(lái)說(shuō),Referer字段應(yīng)和請(qǐng)求的地址位于同一域名下。以上文銀行操作為例,Referer字段地址通常應(yīng)該是轉(zhuǎn)賬按鈕所在的網(wǎng)頁(yè)地址,應(yīng)該也位于www.examplebank.com之下。而如果是CSRF攻擊傳來(lái)的請(qǐng)求,Referer字段會(huì)是包含惡意網(wǎng)址的地址,不會(huì)位于www.examplebank.com之下,這時(shí)候服務(wù)器就能識(shí)別出惡意的訪問(wèn)。

這種辦法簡(jiǎn)單易行,工作量低,僅需要在關(guān)鍵訪問(wèn)處增加一步校驗(yàn)。但這種辦法也有其局限性,因其完全依賴(lài)瀏覽器發(fā)送正確的Referer字段。雖然http協(xié)議對(duì)此字段的內(nèi)容有明確的規(guī)定,但并無(wú)法保證來(lái)訪的瀏覽器的具體實(shí)現(xiàn),亦無(wú)法保證瀏覽器沒(méi)有安全漏洞影響到此字段。并且也存在攻擊者攻擊某些瀏覽器,篡改其Referer字段的可能。

添加校驗(yàn)token

由于CSRF的本質(zhì)在于攻擊者欺騙用戶(hù)去訪問(wèn)自己設(shè)置的地址,所以如果要求在訪問(wèn)敏感數(shù)據(jù)請(qǐng)求時(shí),要求用戶(hù)瀏覽器提供不保存在cookie中,并且攻擊者無(wú)法偽造的數(shù)據(jù)作為校驗(yàn),那么攻擊者就無(wú)法再執(zhí)行CSRF攻擊。這種數(shù)據(jù)通常是表單中的一個(gè)數(shù)據(jù)項(xiàng)。服務(wù)器將其生成并附加在表單中,其內(nèi)容是一個(gè)偽亂數(shù)。當(dāng)客戶(hù)端通過(guò)表單提交請(qǐng)求時(shí),這個(gè)偽亂數(shù)也一并提交上去以供校驗(yàn)。正常的訪問(wèn)時(shí),客戶(hù)端瀏覽器能夠正確得到并傳回這個(gè)偽亂數(shù),而通過(guò)CSRF傳來(lái)的欺騙性攻擊中,攻擊者無(wú)從事先得知這個(gè)偽亂數(shù)的值,服務(wù)器端就會(huì)因?yàn)樾r?yàn)token的值為空或者錯(cuò)誤,拒絕這個(gè)可疑請(qǐng)求。
2017年5月6日 03:57