CSRF（Cross-site request forgery，跨站點請求偽造）是一種是挾制終端用戶在當前已登錄的Web應用程序上執行非本意操作的攻擊方法，它允許攻擊者誘導用戶執行他們不打算執行的操作，並且該攻擊可以部分規避同源策略。通過利用受害者尚未失效的身份認證信息（cookie、會話等），誘騙其點擊惡意鏈接或者訪問包含攻擊代碼的頁面，在受害人不知情的情況下以受害者的身份向服務器發送請求，從而完成非法操作（如更改密碼，修改權限等）。
要實現CSRF攻擊，需要滿足三個條件：
- 擁有相關功能：該應用程序存在一個攻擊者意圖進行的功能，例如修改用戶權限或用戶密碼；
- 基於cookie的會話處理：應用程序僅依靠HTTP cookie來進行會話跟蹤，請求中的任何其他位置均未傳送會話相關的令牌；
- 可預見的請求參數：攻擊者可以確定執行操作所需的所有參數。
XSS和CSRF的比較：
- 跨站點腳本(XSS)允許攻擊者在受害用戶的瀏覽器中執行任意的JavaScript；
- 跨站點請求偽造(CSRF)允許攻擊者誘導受害用戶執行他們不打算執行的操作；
- CSRF可以說是跟XSS、SQL一樣，屬於老生常談的問題了，因此各位應該對其原理也比較熟悉，話不多說，直接進入實驗環節。
實驗一：毫無防范的CSRF漏洞
實驗提示：應用程序 email change模塊存在CSRF漏洞。
實驗要求：構造CSRF利用代碼並上傳到exploit server中。
使用提供的賬號進行登錄，登錄后來到 email change界面。
輸入任意值后使用Burpsuite自動生成POC。
這里生成的POC不具備自動提交功能，需要更改一下設置，然后點擊Regenerate重新生成。
之后將這段POC復制到exploit server保存后即可完成實驗。
實驗二：基於請求方式進行token驗證
實驗提示：應用程序 email change模塊存在CSRF漏洞，雖然添加了token，但僅防御了特定的請求方式。
實驗要求：構造CSRF利用代碼並上傳到exploit server中。
前面的方式都一樣，不同點在於生成POC后將方法POST更改為GET方法以繞過檢測。
將POC保存到exploit server完成實驗。
實驗三：基於token存在進行驗證
實驗提示：應用程序email change模塊存在CSRF漏洞。
實驗要求：構造CSRF利用代碼並上傳到exploit server中。
這一實驗簡單的說就是當發送請求時，如果token不存在，就會跳過驗證環節。
同樣構造POC，然后刪除csrf字段。
將POC保存到exploit server完成實驗
實驗四：token未關聯用戶會話
實驗提示：應用程序 email change模塊存在CSRF漏洞，雖然啟用了token保護，但並未整合到站點會話管理系統當中。
實驗要求：構造CSRF利用代碼並上傳到exploit server中。
根據提示可以推斷出我們可以使用一個有效賬戶的csrf token覆蓋攻擊目標用戶的token以此實現csrf攻擊。
先使用wiener賬戶進行登錄，進入email change模塊修改郵箱，然后構造POC。
然后需要一個新的有效的csrf token，重新刷新進入email change模塊可以發現已經有了一個新的csrf token。
將字段值進行替換
然后將POC保存到exploit server完成實驗。
總結
本文介紹了CSRF原理以及一些基礎的CSRF攻擊場景，后面還有四個實驗，相對復雜，后面公眾號會持續更新。
另外專門針對於CSRF的自動掃描工具並不是很多，這里貼兩個，各位小伙伴可以自行測試：
- https://github.com/s0md3v/Bolt
- https://github.com/tgianko/deemon/
TSRC 關於CSRF掃描檢測的原理介紹：
https://security.tencent.com/index.php/blog/msg/24
今天的文章分享，小伙伴們看懂了嗎？