成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

淺談對(duì)CSRF的認(rèn)識(shí)，以及一些應(yīng)對(duì)措施

isaced / 3441人閱讀

摘要：了解了攻擊者利用的一些原理，就對(duì)應(yīng)的可以找到一些對(duì)應(yīng)措施在服務(wù)端驗(yàn)證的字段。因此，從某些方面來說，是相對(duì)安全的。個(gè)人覺得相對(duì)安全的做法就是既驗(yàn)證，同時(shí)也校驗(yàn)。整個(gè)過程雖然比較難，但這讓自己對(duì)于有了更深刻的認(rèn)識(shí)。

CSRF

CSRF（Cross Site Request Forgery, 跨站域請(qǐng)求偽造）的定義，相信大家都不陌生。它是指攻擊者通過誘導(dǎo)用戶，打開已精心設(shè)計(jì)好的頁面后，發(fā)送請(qǐng)求到某個(gè)網(wǎng)站執(zhí)行某個(gè)操作(修改數(shù)據(jù))的過程。這里有以下三個(gè)前提：

1、用戶已登錄某可信網(wǎng)站(A站，以下所提到的A站都指這里的某可信網(wǎng)站)

2、A站存在某個(gè)請(qǐng)求，可以修改或保存信息(例如：/saveinfo)

3、用戶在A站Session過期前打開攻擊者設(shè)計(jì)好的的頁面，并自動(dòng)或觸發(fā)發(fā)送請(qǐng)求(/saveinfo)

看起來要求聽苛刻的，但的確存在這種情況?！凹幢闶谴竺ΧΦ?Gmail, 在 2007 年底也存在著 CSRF 漏洞，從而被黑客攻擊而使 Gmail 的用戶造成巨大的損失?！?/p>

想要了解怎么應(yīng)對(duì)CSRF，先來看看攻擊者干些什么。

攻擊者能干什么

因?yàn)槭芡床呗韵拗疲粽卟⒉荒苣玫紸站的任何信息（Cookies）和響應(yīng)信息，他只能利用發(fā)送請(qǐng)求時(shí)，會(huì)帶上cookies去校驗(yàn)登錄信息或權(quán)限的特性，去修改用戶的數(shù)據(jù)，來達(dá)到攻擊目的。因此，一般用于獲取信息而不涉及到修改信息的請(qǐng)求(Get)就不用擔(dān)心會(huì)有CSRF危險(xiǎn)了，重要的是能修改信息的請(qǐng)求。當(dāng)然，如果你用Get去修改信息，那就需要考慮防范CSRF了。but這樣做本身就違背了HTTP method設(shè)定的初衷，同時(shí)Get的攻擊方式更為簡(jiǎn)單，一個(gè)Img標(biāo)簽加上JavaScript就能觸發(fā)。所以不建議這么做

CRSF預(yù)防措施

正所謂兵來將擋，水來土掩。了解了攻擊者利用的一些原理，就對(duì)應(yīng)的可以找到一些對(duì)應(yīng)措施

1、在服務(wù)端驗(yàn)證HTTP的Referer字段。

此方法成本較小，只需要在服務(wù)端攔截請(qǐng)求，判斷Referer是否來自于同一域名，如果不是或者不存在CSRF的話，則認(rèn)為有可能是CSRF攻擊，直接過濾。但這種方法也有弊端，那就是當(dāng)有些人會(huì)擔(dān)心Referer會(huì)泄露個(gè)人信息時(shí)（畢竟像服務(wù)器發(fā)送了自己的來源地址）。這些人會(huì)嘗試去關(guān)閉Referer。這樣當(dāng)這些用戶發(fā)起請(qǐng)求時(shí)就不會(huì)帶上Referer，這個(gè)請(qǐng)求就會(huì)被判成有可能的CSRF攻擊，因?yàn)榘凑丈鲜鲞^濾規(guī)則，請(qǐng)求頭中無Referer的有可能會(huì)是CSRF攻擊。

2、在請(qǐng)求地址中添加 token 并驗(yàn)證

此方法的核心思想就是，構(gòu)造成什么樣的信息，來辨別請(qǐng)求是從用戶手中發(fā)出，還是被攻擊者利用而發(fā)出的，很顯然Cookie不能做到，因?yàn)橛脩艉凸粽叨寄軐⑼瑯拥腃ookie帶到服務(wù)器上。

答案就是token(令牌)，它由服務(wù)端通過一定算法生成，每當(dāng)用戶請(qǐng)求頁面的時(shí)候，則向用戶返回的頁面中帶上一個(gè)全新的token。下次用戶在發(fā)送請(qǐng)求的時(shí)候，就帶上該token與服務(wù)器的token進(jìn)行對(duì)比。但這token要放在哪里呢？

三種情況：
1 對(duì)于Get請(qǐng)求，在Url后面動(dòng)態(tài)加上token。 此方法也有一定約束，頁面有很多鏈接，一個(gè)一個(gè)加太麻煩，就需要在document加載完以后，通過js來輔助完成了。但這個(gè)方法對(duì)于動(dòng)態(tài)生成的內(nèi)容，就無能為力了。

2 Post請(qǐng)求 在form表帶中加上

< input type=”hidden” name=token value=”tokenvalue”/>

（查看PC淘寶的個(gè)人中心，其修改資料就是用的此方法）由于同源策略，攻擊者是拿不到表單里的數(shù)據(jù)的。此方法也跟Get請(qǐng)求有同樣的問題，那就是對(duì)于多鏈接和動(dòng)態(tài)生成的內(nèi)容，js批量加上token的辦法就不行了，只能手動(dòng)添加。

3、對(duì)于Ajax請(qǐng)求，如果跨域，則默認(rèn)不會(huì)帶上A站的cookie。因此，從某些方面來說，是相對(duì)安全的。但是根據(jù)w3c對(duì)Ajax的一個(gè)屬性的描述

4.6.4 The withCredentials attribute



client . withCredentials


True when user credentials are to be included in a cross-origin request. False when they are to be excluded in a cross-origin request and when cookies are to be ignored in its response. Initially false.


大概說的意思是，如果withCredentials為true，則存在跨域請(qǐng)求的時(shí)候，用戶的credentials(包括cookie，我是這么理解的，如有錯(cuò)歡迎指正)會(huì)被帶上。

如果將withCredentials設(shè)為true，這樣也會(huì)存在上述的安全問題，因?yàn)镃ookies在發(fā)送請(qǐng)求的同時(shí)也被戴上了。

總結(jié)

1、攻擊者是利用用戶登錄過信任網(wǎng)站后，在會(huì)話未過期之前誘導(dǎo)用戶打開有問題的網(wǎng)站而達(dá)到攻擊目的的

2、常見的防御措施有校驗(yàn)請(qǐng)求頭的referer，以及新增攻擊者無法獲取的隨機(jī)數(shù)token(令牌)來達(dá)到防御目的的。

3、token存放的地方有多種，對(duì)于POST請(qǐng)求，則構(gòu)造hideen的input標(biāo)簽；對(duì)于Get則在鏈接后添加token；對(duì)于ajax，則在cookie中添加token。

4、個(gè)人覺得相對(duì)安全的做法就是既驗(yàn)證referer，同時(shí)也校驗(yàn)token。如涉及到更隱秘的操作，則需要通過驗(yàn)證碼或者手動(dòng)輸入密碼來做防范了。

參考文章：
https://www.w3.org/TR/2014/WD...
https://www.ibm.com/developer...
https://en.wikipedia.org/wiki...

第一次寫Post，過程如此之多，小到markdown語法；大到發(fā)現(xiàn)問題、探索分析問題、查閱資料并自測(cè)驗(yàn)證。最后通篇檢查，是否存在有問題的地方。整個(gè)過程雖然比較難，但這讓自己對(duì)于CRSF有了更深刻的認(rèn)識(shí)。在團(tuán)隊(duì)完成分享后不遺余力整理的一篇，相信以后會(huì)更好。

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/11291.html

相關(guān)文章

  • 淺談對(duì)JavaScript閉包的理解

    摘要：關(guān)于循環(huán)和閉包當(dāng)循環(huán)和閉包結(jié)合在一起時(shí)，經(jīng)常會(huì)產(chǎn)生讓初學(xué)者覺得匪夷所思的問題。閉包是一把雙刃劍是比較難以理解和掌握的部分，它十分強(qiáng)大，卻也有很大的缺陷，如何使用它完全取決于你自己。 在談閉包之前，我們首先要了解幾個(gè)概念： 什么是函數(shù)表達(dá)式？ 與函數(shù)聲明有何不同？ JavaScript查找標(biāo)識(shí)符的機(jī)制 JavaScript的作用域是詞法作用域 JavaScript的垃圾回收機(jī)制 先來...

    missonce 評(píng)論0 收藏0

  • 淺談js跨域問題

    摘要：使用的方法假設(shè)要在和頁面之間傳遞數(shù)據(jù)頁面頁面參考鏈接下面談一下跨域訪問的一些安全性問題，主要是和攻擊問題。在跨域訪問中，注入主要是參數(shù)注入，如防止措施是對(duì)參數(shù)進(jìn)行校驗(yàn)過濾。 所謂跨域，或者異源，是指主機(jī)名（域名）、協(xié)議、端口號(hào)只要有其一不同，就為不同的域（或源）。瀏覽器中有一個(gè)基本的策略，叫同源策略，即限制源自A的腳本只能操作同源頁面的DOM。 先聊一下w3c的CORS規(guī)范：CORS旨...

    learn_shifeng 評(píng)論0 收藏0

  • 淺談前端安全

    摘要：安全問題的分類按照所發(fā)生的區(qū)域分類后端安全問題所有發(fā)生在后端服務(wù)器應(yīng)用服務(wù)當(dāng)中的安全問題前端安全問題所有發(fā)生在瀏覽器單頁面應(yīng)用頁面當(dāng)中的安全問題按照?qǐng)F(tuán)隊(duì)中哪個(gè)角色最適合來修復(fù)安全問題分類后端安全問題針對(duì)這個(gè)安全問題，后端最適合來修復(fù)前端安全 安全問題的分類 按照所發(fā)生的區(qū)域分類 后端安全問題：所有發(fā)生在后端服務(wù)器、應(yīng)用、服務(wù)當(dāng)中的安全問題 前端安全問題：所有發(fā)生在瀏覽器、單頁面應(yīng)用、...

    Cympros 評(píng)論0 收藏0

  • 淺談前端安全

    摘要：安全問題的分類按照所發(fā)生的區(qū)域分類后端安全問題所有發(fā)生在后端服務(wù)器應(yīng)用服務(wù)當(dāng)中的安全問題前端安全問題所有發(fā)生在瀏覽器單頁面應(yīng)用頁面當(dāng)中的安全問題按照?qǐng)F(tuán)隊(duì)中哪個(gè)角色最適合來修復(fù)安全問題分類后端安全問題針對(duì)這個(gè)安全問題，后端最適合來修復(fù)前端安全 安全問題的分類 按照所發(fā)生的區(qū)域分類 后端安全問題：所有發(fā)生在后端服務(wù)器、應(yīng)用、服務(wù)當(dāng)中的安全問題 前端安全問題：所有發(fā)生在瀏覽器、單頁面應(yīng)用、...

    李世贊 評(píng)論0 收藏0

  • 淺談前端安全

    摘要：安全問題的分類按照所發(fā)生的區(qū)域分類后端安全問題所有發(fā)生在后端服務(wù)器應(yīng)用服務(wù)當(dāng)中的安全問題前端安全問題所有發(fā)生在瀏覽器單頁面應(yīng)用頁面當(dāng)中的安全問題按照?qǐng)F(tuán)隊(duì)中哪個(gè)角色最適合來修復(fù)安全問題分類后端安全問題針對(duì)這個(gè)安全問題，后端最適合來修復(fù)前端安全 安全問題的分類 按照所發(fā)生的區(qū)域分類 后端安全問題：所有發(fā)生在后端服務(wù)器、應(yīng)用、服務(wù)當(dāng)中的安全問題 前端安全問題：所有發(fā)生在瀏覽器、單頁面應(yīng)用、...

    alexnevsky 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<