跨站請求偽造（CSRF）挖掘技巧及實戰案例全匯總
- 2019 年 10 月 10 日
- 筆記
1、漏洞理解
Cross-Site Request Forgery跨站請求偽造漏洞，簡稱CSRF或XSRF，強制最終用戶在當前對其進行身份驗證的Web應用程序上執行不需要的操作，瀏覽器的安全策略是允許當前頁面發送到任何地址的請求，所以用戶在瀏覽無法控制的資源時，攻擊者可以控制頁面的內容來控制瀏覽器發送它精心構造的請求。
CSRF和SSRF的相似處在於請求偽造，區別在於CSRF偽造的請求是針對用戶，SSRF針對的是服務器；和XSS相似處在跨站，都需要誘導用戶點擊惡意鏈接/文件，區別在於攻擊效果及原理：CSRF基於Web的隱式身份驗證機制，XSS本質是一種注入漏洞。漏洞原理如下：
根據請求方式的不同可以將漏洞分為：
1）資源包含（GET）
2）基於表單（POST）
3）XMLHttpRequest
2、挖掘技巧
2.1 常見功能
CSRF廣義上存在於任何增刪改操作中，根據經驗常見的有：
1）冒充身份：訂閱/關注/轉發/投票操作，刪除文件，更改配置等
2）帳戶接管：密碼修改，郵箱綁定，第三方帳戶關聯
3）其他：登錄/註冊/註銷/註冊
4）安全設計原則：CSRF登錄後令牌未更新、登出後未註銷等
2.2 缺少CSRF保護（Lack）
最簡單的漏洞類型，沒有任何針對CSRF的防護，也是挖掘中最常見的情形：關注每一個關鍵操作的請求包，若參數中沒有CSRF令牌參數，篡改referer仍然返回正常，則大概率存在CSRF漏洞。
2.3 CSRF防護繞過（Bypass）
針對CSRF的兩種防禦分別有bypass手段：
1）Referer繞過
- 空referer繞過：其他協議（data：）或https跳http
- 包含referer：若只檢查是否包含網址，只需在我們的網站上創建一個文件/文件夾即可，如 https://www.yoursite.com/https://www.theirsite.com/
2）CSRF-token繞過：
- 刪除令牌：刪除cookie/參數中token，免服務器驗證
- 令牌共享：創建兩個帳戶，替換token看是否可以互相共用；
- 篡改令牌值：有時系統只會檢查CSRF令牌的長度；
- 解碼CSRF令牌：嘗試進行MD5或Base64編碼
- 修改請求方法：post改為get
- 竊取token：重定向、XSS、web緩存欺騙、clickjacking等都可能導致token泄露
3、實戰案例：
1）郵箱綁定——賬戶接管
KhanAcademy可汗學院郵箱綁定處未設置header頭和token校驗：
抓取post，構造XHR發包的HTML文件poc.html：
將poc.html文件放在自己的服務器上，誘使受害者點擊HTML文件，F12查看實則借用受害者權限向服務器發送請求：
查看綁定郵箱，已經篡改為攻擊者郵箱，下面可通過此郵箱進行密碼修改，從而接管任意賬戶，這也是CSRF實戰攻擊的一般流程。
2）空Referer繞過
Xvideo網站評論處未使用token機制，僅驗證了referer且未驗證空referer情況（無referer字段），利用data:協議繞過，如我們訪問
data:text/html,<script>top.location.href='http://www.google.com/';</script>則會顯示referer為空，所以構造payload：
攔截查看請求包：
返回包顯示，請求成功：
3）CSRF——其他漏洞的輔助
Self-XSS+CSRF=Reflected-XSS
評論、登錄、文件上傳等處的Self-XSS，結合CSRF可變為反射型XSS，如評論處：
觸發XSS：
還有經典的登錄XSS：
編寫payload：
觸發XSS：
4、漏洞防禦：
1） 驗證header字段
常見的是Referer和Origin，Referer容易繞過，且會包含有一些敏感信息，可能會侵犯用
戶的隱私，而Origin字段代表最初請求，更建議使用。
2） Token令牌機制
當前最成熟的防禦機制，但若存在驗證邏輯及配置問題則存在繞過風險。Token的生成機制通常和session標識符掛鈎，將用戶的token與session標識符在服務端進行匹配。當下已經有很多開源庫和中間件都可以實現token生成。
3） 驗證自定義header
如基於cookie的csrf保護，驗證cookie中的某些值和參數必須相等
