CSRF（Cross-site request forgery），中文名稱：跨站請求偽造，也被稱為：one click attack/session riding，縮寫為：CSRF/XSRF。一般來說，CSRF是除XSS外最常見一種漏洞，也是一大刷分利器。 有關CSRF的具體利用，CEO早在 08年就給我們詳細介紹了，大家可以去膜拜下：
文章鏈接http://blog.csdn.net/lake2/Article/details/2245754
下面分享下我個人在測CSRF漏洞時繞過防御的一些主要經驗，希望能和大家一起交流下。目前騰訊百度等站點防御CSRF漏洞的主要方法是添加 token（一般參數名為g_tk，bdtoken）與referer驗證，相信大家在很多時候抓包一看有token或者刪除referer重新發包報錯 了就會覺得這里不會有csrf漏洞了，可實際情況可不一定。還有一種常見情況就是使用驗證碼，這種情況我暫時沒找到什么方法，查閱了一些網絡資料，目前識 別驗證碼的方法都無法直接利用到繞過CSRF防御上來，所以不考慮用戶體驗的話，驗證碼是防御CSRF攻擊的最有效的方法。如果有大牛有其它思路繞過的話 希望能分享給大家一起討論下。
情況A:
無token無referer驗證這種情況現在比較少了，一般出現在一些新上線的業務。我一般測試時都是用Firefox的Live Http Headers插件先抓取一個正常請求的數據包，如果沒token的話，先去掉referer字段再重新提交看返回值。如果沒報錯的話，那就可以直接寫一 個表單（POST型）或者構造個鏈接（GET型）重新測試了，一般都會成功；但有些通過ajax提交的是行不通的，因為ajax無法跨域。
如下圖1：
情況B：
無token有referer驗證這種情況比較常見，也許我們抓包發現無token正慶幸時，刪除referer重新提交一看發現報錯了，難道就這樣放棄了么？當然NO。。。
一.我們可以試試空referer：即刪除header中的referer的值，如果服務器只是驗證了是否存在referer沒驗證referer值 的話，我們重新提交會發現一個CSRF漏洞又被發現了~因為所有跨協議傳遞的請求都是不會送referer的，如https->http,(這個利 用成本有點高）還有javascript->http,data->http.如下面兩個例子：
1.javascript->http <img src=http://hiphotos.baidu.com/aullik5/pic/item/b2cdb444a5ea4402cffca317.jpeg /> <script> window.sc="<img src='http://www.businessinfo.co.uk/labs/hackvertor/images/logo.gif?"+Math.random()+"'>"; </script> <iframe src="javascript:parent.sc"></iframe> 2.data->http <iframe src="data:text/html; base64,PGltZyBzcmM9aHR0cDovL2hpcGhvdG9zLmJhaWR1LmNvbS9hdWxsaWs1L3BpYy9pdGVtL2IyY2RiNDQ0YTVlYTQ0MDJjZmZjYTMxNy5qcGVnIC8+" ></iframe> //base64 加密的部分實際上就是我們構造的CSRF鏈接
二.我們可以試試修改referer值：如果原referer值為Referer： t.qq.com/xxxx 話，我們可以試試修改為Referer: t.qq.com.baidu.com/xxx。如果服務器只是驗證了referer是否存在qq.com或者t.qq.com等關鍵詞的話，爭對前一種 情況，我們可以在騰訊某子站點（http://xx.qq.com）發個帖子將圖片地址修改為我們構造的csrf鏈接或者寫好CSRF表單后將地址發布在 微博上等待其它用戶點擊，針對后一種情況我們可以建立個t.qq.com.yourdomain.com的域名存放CSRF表單來繞過REFERER檢 測;
三.偽造referer(具體方法我也沒測試過，可自行百度)
如下圖2，圖3：
