CSRF漏洞原理：
CSRF是跨站請求偽造，不攻擊網站服務器，而是冒充用戶在站內的正常操作。通常由於服務端沒有對請求頭做嚴格過濾引起的。CSRF會造成密碼重置，用戶偽造等問題，可能引發嚴重后果。
我們知道，絕大多數網站是通過cookie等方式辨識用戶身份，再予以授權的。所以要偽造用戶的正常操作，最好的方法是通過XSS或鏈接欺騙等途徑，讓用戶在本機（即擁有身份cookie的瀏覽器端）發起用戶所不知道的請求。CSRF攻擊會令用戶在不知情的情況下攻擊自己已經登錄的系統。
CSRF攻擊的目的是濫用基本的Web功能。如果該網站可以使服務器上的狀態變化，如改變受害者的電子郵件地址或密碼，或購買的東西，強迫受害人檢索數據等等。CSRF攻擊會修改目標狀態。在這一過程中，受害者會代替攻擊者執行這些攻擊，攻擊者中不會收到響應，受害者會代替攻擊者執行這些攻擊。
在跨站點請求偽造（CSRF）攻擊中，攻擊者經由用戶的瀏覽器注入網絡請求來破壞用戶與網站的會話的完整性。瀏覽器的安全策略允許網站將HTTP請求發送到任何網絡地址。此策略允許控制瀏覽器呈現的內容的攻擊者使用此用戶控制下的其他資源。
需要對頁面參數做修改時，可以使用burpsuite生成的csrf poc，從而進行poc測試，測試完成之后一定要驗證，瀏覽器執行了我們生成的poc測試，令數據產生變化。
csrf可以和XSS聯系在一起，XSS獲取cookie，CSRF偽造跨站請求完成指令。
漏洞利用重點：
1、CSRF的攻擊建立在瀏覽器與web服務器的會話中
2、欺騙用戶訪問URL
攻擊場景：
CSRF攻擊（GET）：
這種類型的CSRF一般由於程序員的安全意識不強造成的。GET類型的CSRF利用非常簡單，只需要一個HTTP請求，所以，一般會這樣利用：<img src=http://test.com/csrf?xx=11 />
在訪問含有這個img的頁面后，成功向http://test.com/csrf?xx=11 發出了一次HTTP請求。
假如微博存在CSRF漏洞，有一個GET請求讓別人點擊后關注我，這時可以做一些誘惑性的博客。
假如想讓每個用戶都幫助自己轉發微博，制造一次蠕蟲攻擊，找到轉播文章的頁面與關注我的頁面，寫一個POC，用<iframe>標簽來加載URL，加載兩條URL，這時當用戶點擊會關注並且自動轉發。
CSRF攻擊（POST）：構造form表單，利用javascript提交。
讀取型CSRF：
什么是讀取型CSRF，如下的漏洞可以歸納進讀取型CSRF，因為這些漏洞的利用手法都跟CSRF是一樣的：
- JSONP劫持
- Flash跨域劫持
- CORS跨域資源讀取
...等等，還有一些Sliverlight跨域這些。
瀏覽器Cookie機制：
cookie的兩種表現形式：一種是本地Cookie，又稱持久性Cookie；
一種是臨時Cookie，又稱Session Cookie；
檢測CSRF漏洞：
1、手工檢測如：http://www.test.com/test?id=1 通過此id可以刪除指定的用戶。可以編寫一個POC get方式。
2、半自動檢測：工具CSRFTester，另外burpsuite scanner模塊也支持檢測CSRF漏洞。
3、全自動檢測：主要是插件。
預防跨站請求偽造：
其實現在有關CSRF漏洞防護已經是比較成熟了，其主要防護的思路就是需要在進行后台數據修改操作的過程中，添加對當前用戶身份的有效驗證措施，而不能僅限於cookie的識別。
（1）來源校驗
使用http請求頭中的referer來源，對客戶端源身份校驗，此方法早期使用較多，但是仍然容易被繞過，所以這里並不建議使用。
（2）用戶token校驗
添加基於當前用戶身份的有效tokens隨機驗證機制，即在向后端提交數據操作請求時，添加基於當前用戶的隨機token校驗值，此種校驗方法當前使用比較多；（xss和csrf漏洞同時存在時token校驗生效）
（3）當前用戶密碼驗證
在修改關鍵信息時，要當前用戶輸入其自身的密碼，以驗證當前用戶身份的真偽，防止未授權的惡意操作；
（4）添加驗證機制
在請求數據提交前，需填寫驗證碼信息提交，以增加對用戶來源的有效驗證，防止惡意未授權的操作產生。
繞過防御的經驗：
相信大家在很多時候抓包一看有token或者刪除referer重新發包報錯了就會覺得這里不會有csrf漏洞了，可實際情況可不一定。還有一種常見情況就是使用驗證碼，目前識別驗證碼的方法都無法直接利用到繞過CSRF防御上來，所以不考慮用戶體驗的話，驗證碼是防御CSRF攻擊最有效的方法。
情況A：
無token無referer驗證這種情況現在比較少了，一般出現在一些新上線的業務。一般測試時都是用firefox的live Http Headers插件先抓取一個正常請求的數據包，如果沒token的話，先去掉referer字段再重新提交看返回值。如果沒報錯的話，那就可以直接寫一個表單（POST型）或者構造個鏈接（GET型）重新測試了，一般都會成功；但有些通過ajax提交的是行不通的，因為ajax無法跨域。
情況B：
無token有referer驗證這種情況比較常見，也許我們抓包發現無token正慶幸時，刪除referer重新提交一看發現報錯了，難道就這樣放棄了嗎？
（1）可以試試空的referer：即刪除header中的referer的值，如果服務器只是驗證了是否存在referer沒驗證referer值的話，重新提交會發現一個CSRF漏洞又被發現了，因為所有跨域協議傳遞的請求都不會送referer的
（2)可以試試修改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檢測。