??博客主頁(yè)：拒絕冗余 – 生命不息，折騰不止
??訂閱專欄：『Web安全』
??如覺得博主文章寫的不錯(cuò)或?qū)δ阌兴鶐椭脑?，還望大家多多支持呀！ ??關(guān)注?、點(diǎn)贊??、收藏??、評(píng)論。

簡(jiǎn)介

CSRF跨站請(qǐng)求偽造，全稱Cross-site request forgery，是指利用受害者尚未失效的身份認(rèn)證信息（cookie、會(huì)話等），誘騙其點(diǎn)擊惡意鏈接或者訪問包含攻擊代碼的頁(yè)面，在受害人不知情的情況下以受害者的身份向（身份認(rèn)證信息所對(duì)應(yīng)的）服務(wù)器發(fā)送請(qǐng)求，從而完成非法操作（如轉(zhuǎn)賬、改密等）。CSRF是Web安全中最容易被忽略的一種攻擊方式，但某些時(shí)候卻能產(chǎn)生強(qiáng)大的破壞性。

CSRF 攻擊原理

• 1用戶打開瀏覽器，訪問登陸受信任的A網(wǎng)站

• 2在用戶信息通過驗(yàn)證后，服務(wù)器會(huì)返回一個(gè)cookie給瀏覽器，用戶登陸網(wǎng)站A成功，可以正常發(fā)送請(qǐng)求到網(wǎng)站A

• 3用戶未退出網(wǎng)站A，在同一瀏覽器中，打開一個(gè)危險(xiǎn)網(wǎng)站B

• 4網(wǎng)站B收到用戶請(qǐng)求后，返回一些惡意代碼，并發(fā)出請(qǐng)求要求訪問網(wǎng)站A

• 5瀏覽器收到這些惡意代碼以后，在用戶不知情的情況下，利用cookie信息，向網(wǎng)站A發(fā)送惡意請(qǐng)求，網(wǎng)站A會(huì)根據(jù)cookie信息以用戶的權(quán)限去處理該請(qǐng)求，導(dǎo)致來自網(wǎng)站B的惡意代碼被執(zhí)行

偽造GET/POST請(qǐng)求

在CSRF攻擊流行之初，曾經(jīng)很多人認(rèn)為CSRF只能由GET請(qǐng)求發(fā)起，因此很多開發(fā)者認(rèn)為只要把重要的操作改成只允許POST請(qǐng)求就能防止CSRF攻擊。
這種錯(cuò)誤的觀點(diǎn)形成的原因在于，大多數(shù)CSRF發(fā)起攻擊時(shí)，使用的都是 //

在2007年Gmail CSRF漏洞攻擊過程中安全研究者pdp展示了這個(gè)技巧：
首先用戶需要登錄Gmail賬戶以便獲取Gmail的臨時(shí)Cookie,然后攻擊者誘使用戶訪問一個(gè)惡意頁(yè)面，在這個(gè)惡意頁(yè)面中隱藏了一個(gè)iframe,iframe的地址指向pdp寫的一個(gè)惡意鏈接，這個(gè)鏈接的實(shí)際作用就是把參數(shù)生成一個(gè)POST表單并提交。pdp的攻擊腳本會(huì)在郵箱的Filter中新建一條規(guī)則，把所有帶附件的郵件都轉(zhuǎn)發(fā)到攻擊者指定的郵箱，由于瀏覽器中已經(jīng)存在Gmail的臨時(shí)Cookie，所以這個(gè)請(qǐng)求會(huì)成功。

CSRF 蠕蟲

2008年9月百度曾經(jīng)受到CSRF蠕蟲病毒攻擊，漏洞出現(xiàn)在百度用戶中心的發(fā)送短消息功能中：

http://msg.baidu.com/?ct=22&cm=MailSend&tn=bmSubmit&sn=用戶賬戶&con=消息內(nèi)容

這個(gè)鏈接只要修改參數(shù)sn即可對(duì)指定的用戶發(fā)送短消息，而攻擊者發(fā)現(xiàn)另一個(gè)接口能查詢出某個(gè)用戶的所有好友，將兩者結(jié)合起來，可以組成一個(gè)CSRF Worm-讓一個(gè)百度用戶查看惡意頁(yè)面后，將給他的所有好友發(fā)送一條短消息，然后這個(gè)短消息中又包含一張圖片，其地址再次指向CSRF頁(yè)面，使得這些好友再次將消息發(fā)給他們的好友，這個(gè)Worm因此得以傳播。
這個(gè)蠕蟲很好的展示了CSRF的破壞性-即使沒有Xss漏洞，僅僅是CSRF也是能夠發(fā)起大規(guī)模蠕蟲攻擊的

CSRF 防御

下面看看有什么方法可以防御這種攻擊。

1.驗(yàn)證碼

驗(yàn)證碼被認(rèn)為是對(duì)抗CSRF攻擊最簡(jiǎn)潔而有效的防御方法。
CSRF攻擊的過程，往往是在用戶不知情的情況下構(gòu)造了網(wǎng)絡(luò)請(qǐng)求，而驗(yàn)證碼強(qiáng)制用戶必須與應(yīng)用進(jìn)行交互才能完成最終請(qǐng)求。但是很多時(shí)候，出于對(duì)用戶體驗(yàn)考慮，網(wǎng)站不能給所有的操作都加上驗(yàn)證碼，因此驗(yàn)證碼只能作為防御CSRF的一種輔助手段，而不能作為最主要的解決方案。

2.Referer Check

Referer Check即通過驗(yàn)證 HTTP請(qǐng)求頭中的Referer 字段檢查請(qǐng)求是否來自合法的“源”，檢查Referer是否合法來判斷用戶是否被CSRF攻擊。HTTP 頭中有一個(gè)字段叫 Referer，它記錄了該 HTTP 請(qǐng)求的來源地址。比如一個(gè)發(fā)博客的操作，正常情況下需要先登錄到發(fā)博客頁(yè)面，提交“發(fā)布”的表單時(shí)Referer的只必然是發(fā)博客表單所有的頁(yè)面，如果Referer的值不是這個(gè)頁(yè)面，甚至不是發(fā)博客的域，則很有可能受到CSRF攻擊。
Referer Check的缺陷在于，服務(wù)器并非什么時(shí)候都能夠取到Referer，很多用戶（或?yàn)g覽器）出于隱私保護(hù)的考慮，限制了Referer的發(fā)送。

3.使用token驗(yàn)證

CSRF為什么能攻擊成功？其本質(zhì)原因時(shí)重要操作的所有參數(shù)都是可以被攻擊者猜測(cè)到的?，F(xiàn)在業(yè)界對(duì)CSRF的防御，一致的做法就是增加一個(gè)參數(shù)–Token。Token必須足夠隨機(jī)（使用足夠安全的隨機(jī)數(shù)生成算法），它應(yīng)該作為一個(gè)“秘密”存在于服務(wù)器和瀏覽器中，不被第三方知曉。由于Token的存在，攻擊者無法再構(gòu)造出一個(gè)完整的url實(shí)施攻擊。實(shí)際應(yīng)用時(shí)，Token可以放在用戶的Session或者瀏覽器的Cookie中，在提交請(qǐng)求時(shí)，服務(wù)器只需驗(yàn)證表單中的Token與用戶傳過來的Token(Session或Cookie中)是否一致，如果一致則認(rèn)為是合法請(qǐng)求；如果不一致，則認(rèn)為請(qǐng)求不合法，可能發(fā)生了CSRF攻擊。文章來源地址http://www.zghlxwxcb.cn/news/detail-815009.html

到了這里，關(guān)于Web系統(tǒng)常見安全漏洞介紹及解決方案-CSRF攻擊的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！