CSRF「Cross-site request forgery」
我們知道了同源策略可以隔離各個(gè)站點(diǎn)之間的 DOM 交互、頁(yè)面數(shù)據(jù)和網(wǎng)絡(luò)通信，雖然嚴(yán)格的同源策略會(huì)帶來(lái)更多的安全，但是也束縛了 Web。這就需要在安全和自由之間找到一個(gè)平衡點(diǎn)，所以我們默認(rèn)頁(yè)面中可以引用任意第三方資源，然后又引入 CSP 策略來(lái)加以限制；默認(rèn) XMLHttpRequest 和 Fetch 不能跨站請(qǐng)求資源，然后又通過(guò) CORS 策略來(lái)支持其跨域。
所以安全性降低了，為了更好的技術(shù)應(yīng)用，同時(shí)也帶來(lái)了更多的安全隱患，如XSS，CSRF。
什么是CSRF？
跨站請(qǐng)求偽造，冒用Cookie中的信息，發(fā)起請(qǐng)求攻擊。
CSRF（Cross-site request forgery）跨站請(qǐng)求偽造：攻擊者誘導(dǎo)受害者進(jìn)入第三方網(wǎng)站，在第三方網(wǎng)站中，向被攻擊網(wǎng)站發(fā)送跨站請(qǐng)求。利用受害者在被攻擊網(wǎng)站已經(jīng)獲取的注冊(cè)憑證，繞過(guò)后臺(tái)的用戶驗(yàn)證，達(dá)到冒充用戶對(duì)被攻擊的網(wǎng)站執(zhí)行某項(xiàng)操作的目的。
CSRF攻擊過(guò)程
滿足了上面的必要條件才可以觸發(fā)
- 當(dāng)用戶已經(jīng)登錄成功了一個(gè)網(wǎng)站
- 然后通過(guò)被誘導(dǎo)進(jìn)了第三方網(wǎng)站「釣魚(yú)網(wǎng)站」
- 跳轉(zhuǎn)過(guò)去了自動(dòng)提交表單，冒用受害者信息
- 后臺(tái)則正常走邏輯將用戶提交的表單信息進(jìn)行處理
CSRF攻擊類型
GET類型
img標(biāo)簽 script。
<!DOCTYPE html>
<html>
<body>
<h1>黑客的站點(diǎn)</h1>
<img src="https://www.bank.com/withdraw?amount=1000?for=hacker">
</body>
</html>
?
黑客將轉(zhuǎn)賬的請(qǐng)求接口隱藏在 img 標(biāo)簽內(nèi)，欺騙瀏覽器這是一張圖片資源。當(dāng)該頁(yè)面被加載時(shí)，瀏覽器會(huì)自動(dòng)發(fā)起 img 的資源請(qǐng)求，如果服務(wù)器沒(méi)有對(duì)該請(qǐng)求做判斷的話，那么服務(wù)器就會(huì)認(rèn)為該請(qǐng)求是一個(gè)轉(zhuǎn)賬請(qǐng)求，于是用戶賬戶上的 100 就被轉(zhuǎn)移到黑客的賬戶上去了。
POST類型
表單中的post請(qǐng)求
<form action="http://bank.com/withdraw" method=POST>
<input type="hidden" name="account" value="xiaoming" />
<input type="hidden" name="amount" value="10000" />
<input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>
訪問(wèn)該頁(yè)面后，表單會(huì)自動(dòng)提交，相當(dāng)于模擬用戶完成了一次POST操作。
?
?
引誘用戶點(diǎn)擊
a標(biāo)簽
鏈接類型的CSRF a標(biāo)簽
<a taget="_blank">重磅消息?。?lt;a/>
只要用戶點(diǎn)擊了，就會(huì)被攻擊成功
必要條件才能觸發(fā)CSRF
與 XSS 不同的是，CSRF 攻擊不需要將惡意代碼注入用戶的頁(yè)面，僅僅是利用服務(wù)器的漏洞和用戶的登錄狀態(tài)來(lái)實(shí)施攻擊
-
目標(biāo)站點(diǎn)一定要有 CSRF 漏洞；
后臺(tái)接口一定是有問(wèn)題的，www.bank.com/withdraw?pa…,這樣的話攻擊者才有機(jī)會(huì)。
-
用戶要登錄過(guò)目標(biāo)站點(diǎn)，并且在瀏覽器上保持有該站點(diǎn)的登錄狀態(tài)；
-
需要用戶打開(kāi)一個(gè)第三方站點(diǎn)，可以是黑客的站點(diǎn)，也可以是一些論壇。
CSRF的特點(diǎn)
攻擊一般發(fā)起在第三方網(wǎng)站，而不是被攻擊的網(wǎng)站。被攻擊的網(wǎng)站無(wú)法防止攻擊發(fā)生。 攻擊利用受害者在被攻擊網(wǎng)站的登錄憑證，冒充受害者提交操作；而不是直接竊取數(shù)據(jù)，整個(gè)過(guò)程攻擊者并不能獲取到受害者的登錄憑證，僅僅是“冒用”。 跨站請(qǐng)求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等。部分請(qǐng)求方式可以直接嵌入在第三方論壇、文章中，難以進(jìn)行追蹤。 CSRF通常是跨域的，因?yàn)橥庥蛲ǔ８菀妆还粽哒瓶?。但是如果本域下有容易被利用的功能，比如可以發(fā)圖和鏈接的論壇和評(píng)論區(qū)，攻擊可以直接在本域下進(jìn)行，而且這種攻擊更加危險(xiǎn)。
防護(hù)策略
CSRF通常從第三方網(wǎng)站發(fā)起，被攻擊的網(wǎng)站無(wú)法防止攻擊發(fā)生，只能通過(guò)增強(qiáng)自己網(wǎng)站針對(duì)CSRF的防護(hù)能力來(lái)提升安全性。
根據(jù)上面總結(jié)的特點(diǎn)，制定防護(hù)策略，如下。
阻止不明外域的訪問(wèn)
同源檢測(cè)
既然CSRF大多來(lái)自第三方網(wǎng)站，那么我們就直接禁止外域（或者不受信任的域名）對(duì)我們發(fā)起請(qǐng)求。
微信小程序是把一個(gè)域名加入白名單，不然就禁止訪問(wèn)，但我們有時(shí)候不需要做這么嚴(yán)格。
請(qǐng)求頭有 Origin Header、Referer Header，這兩個(gè)Header在瀏覽器發(fā)起請(qǐng)求時(shí)，大多數(shù)情況會(huì)自動(dòng)帶上，并且不能由前端自定義內(nèi)容。 服務(wù)器可以通過(guò)解析這兩個(gè)Header中的域名，確定請(qǐng)求的來(lái)源域。
Origin Header
在部分與CSRF有關(guān)的請(qǐng)求中，請(qǐng)求的Header中會(huì)攜帶Origin字段。字段內(nèi)包含請(qǐng)求的域名（不包含path及query），如果Origin存在，那么直接使用Origin中的字段確認(rèn)來(lái)源域名就可以。
但是Origin在以下兩種情況下并不存在： IE11同源策略： IE 11 不會(huì)在跨站CORS請(qǐng)求上添加Origin標(biāo)頭，Referer頭將仍然是唯一的標(biāo)識(shí)。最根本原因是因?yàn)镮E 11對(duì)同源的定義和其他瀏覽器有不同，有兩個(gè)主要的區(qū)別，可以參考MDN Same-origin_policy#IE_Exceptions 302重定向： 在302重定向之后Origin不包含在重定向的請(qǐng)求中，因?yàn)镺rigin可能會(huì)被認(rèn)為是其他來(lái)源的敏感信息。對(duì)于302重定向的情況來(lái)說(shuō)都是定向到新的服務(wù)器上的URL，因此瀏覽器不想將Origin泄漏到新的服務(wù)器上。
Referer Header
根據(jù)HTTP協(xié)議，在HTTP頭中有一個(gè)字段叫Referer，記錄了該HTTP請(qǐng)求的來(lái)源地址。 對(duì)于Ajax請(qǐng)求，圖片和script等資源請(qǐng)求，Referer為發(fā)起請(qǐng)求的頁(yè)面地址。對(duì)于頁(yè)面跳轉(zhuǎn)，Referer為打開(kāi)頁(yè)面歷史記錄的前一個(gè)頁(yè)面地址。因此我們使用Referer中鏈接的Origin部分可以得知請(qǐng)求的來(lái)源域名。
因此，服務(wù)器的策略是優(yōu)先判斷 Origin，如果請(qǐng)求頭中沒(méi)有包含 Origin 屬性，再根據(jù)實(shí)際情況判斷是否使用 Referer 值，從而增加攻擊難度。
Samesite Cookie
為了從源頭上解決這個(gè)問(wèn)題，Google起草了一份草案來(lái)改進(jìn)HTTP協(xié)議，那就是為Set-Cookie響應(yīng)頭新增Samesite屬性，它用來(lái)標(biāo)明這個(gè) Cookie是個(gè)“同站 Cookie”，同站Cookie只能作為第一方Cookie，不能作為第三方Cookie，Samesite 有三個(gè)屬性值，分別是 Strict 和 Lax，None下面分別講解：
Samesite=Strict
這種稱為嚴(yán)格模式，表明這個(gè) Cookie 在任何情況下都不可能作為第三方 Cookie，絕無(wú)例外。比如說(shuō) b.com 設(shè)置了如下 Cookie：
我們?cè)?a.com 下發(fā)起對(duì) b.com 的任意請(qǐng)求，foo 這個(gè) Cookie 都不會(huì)被包含在 Cookie 請(qǐng)求頭中，但 bar 會(huì)。舉個(gè)實(shí)際的例子就是，假如淘寶網(wǎng)站用來(lái)識(shí)別用戶登錄與否的 Cookie 被設(shè)置成了 Samesite=Strict，那么用戶從百度搜索頁(yè)面甚至天貓頁(yè)面的鏈接點(diǎn)擊進(jìn)入淘寶后，淘寶都不會(huì)是登錄狀態(tài)，因?yàn)樘詫毜姆?wù)器不會(huì)接受到那個(gè) Cookie，其它網(wǎng)站發(fā)起的對(duì)淘寶的任意請(qǐng)求都不會(huì)帶上那個(gè) Cookie。
Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: bar=2; Samesite=Lax
Set-Cookie: baz=3
Samesite=Lax 這種稱為寬松模式，比 Strict 放寬了點(diǎn)限制：假如這個(gè)請(qǐng)求是這種請(qǐng)求（改變了當(dāng)前頁(yè)面或者打開(kāi)了新頁(yè)面）且同時(shí)是個(gè)GET請(qǐng)求，則這個(gè)Cookie可以作為第三方Cookie。比如說(shuō) b.com設(shè)置了如下Cookie：
Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: bar=2; Samesite=Lax
Set-Cookie: baz=3
當(dāng)用戶從 a.com 點(diǎn)擊鏈接進(jìn)入 b.com 時(shí)，foo 這個(gè) Cookie 不會(huì)被包含在 Cookie 請(qǐng)求頭中，但 bar 和 baz 會(huì)，也就是說(shuō)用戶在不同網(wǎng)站之間通過(guò)鏈接跳轉(zhuǎn)是不受影響了。但假如這個(gè)請(qǐng)求是從 a.com 發(fā)起的對(duì) b.com 的異步請(qǐng)求，或者頁(yè)面跳轉(zhuǎn)是通過(guò)表單的 post 提交觸發(fā)的，則bar也不會(huì)發(fā)送。
我們應(yīng)該如何使用SamesiteCookie 如果SamesiteCookie被設(shè)置為Strict，瀏覽器在任何跨域請(qǐng)求中都不會(huì)攜帶Cookie，新標(biāo)簽重新打開(kāi)也不攜帶，所以說(shuō)CSRF攻擊基本沒(méi)有機(jī)會(huì)。
而且跳轉(zhuǎn)子域名或者是新標(biāo)簽重新打開(kāi)剛登陸的網(wǎng)站，之前的Cookie都不會(huì)存在。尤其是有登錄的網(wǎng)站，那么我們新打開(kāi)一個(gè)標(biāo)簽進(jìn)入，或者跳轉(zhuǎn)到子域名的網(wǎng)站，都需要重新登錄。對(duì)于用戶來(lái)講，可能體驗(yàn)不會(huì)很好。
如果SamesiteCookie被設(shè)置為L(zhǎng)ax，那么其他網(wǎng)站通過(guò)頁(yè)面跳轉(zhuǎn)過(guò)來(lái)的時(shí)候可以使用Cookie，可以保障外域連接打開(kāi)頁(yè)面時(shí)用戶的登錄狀態(tài)。但相應(yīng)的，其安全性也比較低。
總之，SamesiteCookie是一個(gè)可能替代同源驗(yàn)證的方案，但是需要合理使用Strict Lax。
提交時(shí)要求附加本域才能獲取的信息
我們可以要求所有的用戶請(qǐng)求都攜帶一個(gè)CSRF攻擊者無(wú)法獲取到的Token/cookie
Token：存在本地local strage中的加密數(shù)據(jù)
token是一個(gè)比較有效的CSRF防護(hù)方法，只要頁(yè)面沒(méi)有XSS漏洞泄露Token，那么接口的CSRF攻擊就無(wú)法成功，也是現(xiàn)在主流的解決方案。
雙重Cookie驗(yàn)證
利用CSRF攻擊不能獲取到用戶Cookie的特點(diǎn)，我們可以要求Ajax和表單請(qǐng)求攜帶一個(gè)Cookie中的值。
雙重Cookie采用以下流程： 在用戶訪問(wèn)網(wǎng)站頁(yè)面時(shí)，向請(qǐng)求域名注入一個(gè)Cookie，內(nèi)容為隨機(jī)字符串（例如csrfcookie=v8g9e4ksfhw）。 在前端向后端發(fā)起請(qǐng)求時(shí)，取出Cookie，并添加到URL的參數(shù)中（接上例POST www.a.com/comment?csr…）。 后端接口驗(yàn)證Cookie中的字段與URL參數(shù)中的字段是否一致，不一致則拒絕。
如果用戶訪問(wèn)的網(wǎng)站為www.a.com，而后端的api域名為api.a.com。那么在www.a.com下，前端拿不到api.a.com的Cookie，也就無(wú)法完成雙重Cookie認(rèn)證。 于是這個(gè)認(rèn)證Cookie必須被種在a.com下，這樣每個(gè)子域都可以訪問(wèn)。 任何一個(gè)子域都可以修改a.com下的Cookie。 某個(gè)子域名存在漏洞被XSS攻擊（例如upload.a.com）。雖然這個(gè)子域下并沒(méi)有什么值得竊取的信息。但攻擊者修改了a.com下的Cookie。 攻擊者可以直接使用自己配置的Cookie，對(duì)XSS中招的用戶再向www.a.com下，發(fā)起CSRF攻擊。
有時(shí)候也會(huì)造成xsrf的攻擊，所以并不是一個(gè)好的解決方案。
后端接口防止XSRF漏洞
- 嚴(yán)格管理所有的上傳接口，防止任何預(yù)期之外的上傳內(nèi)容（例如HTML）。
- 添加Header
X-Content-Type-Options: nosniff防止黑客上傳HTML內(nèi)容的資源（例如圖片）被解析為網(wǎng)頁(yè)。 - 對(duì)于用戶上傳的圖片，進(jìn)行轉(zhuǎn)存或者校驗(yàn)。不要直接使用用戶填寫(xiě)的圖片鏈接。
前端提示
當(dāng)前用戶打開(kāi)其他用戶填寫(xiě)的鏈接時(shí)，需告知風(fēng)險(xiǎn)（知乎跳轉(zhuǎn)外鏈，等等都會(huì)告知風(fēng)險(xiǎn)）。
個(gè)人用戶CSRF安全的建議
經(jīng)常上網(wǎng)的個(gè)人用戶，可以采用以下方法來(lái)保護(hù)自己：
- 使用網(wǎng)頁(yè)版郵件的瀏覽郵件或者新聞也會(huì)帶來(lái)額外的風(fēng)險(xiǎn)，因?yàn)椴榭脆]件或者新聞消息有可能導(dǎo)致惡意代碼的攻擊。
- 盡量不要打開(kāi)可疑的鏈接，一定要打開(kāi)時(shí)，使用不常用的瀏覽器。
總結(jié)
為了更好的防御CSRF，最佳實(shí)踐應(yīng)該是結(jié)合上面總結(jié)的防御措施方式中的優(yōu)缺點(diǎn)來(lái)綜合考慮，結(jié)合當(dāng)前Web應(yīng)用程序自身的情況做合適的選擇，才能更好的預(yù)防CSRF的發(fā)生。
文末福利
1. 網(wǎng)絡(luò)安全學(xué)習(xí)路線圖：
【圖片過(guò)大被平臺(tái)壓縮導(dǎo)致模糊，可以在文末免費(fèi)下載高清完整版】
2. 網(wǎng)絡(luò)安全學(xué)習(xí)視頻教程
3. 網(wǎng)絡(luò)安全學(xué)習(xí)文檔資料
文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-715848.html
【需要資料的朋友，可以掃描下方二維碼，免費(fèi)獲取《282G 全套網(wǎng)絡(luò)安全學(xué)習(xí)資料包》】
文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-715848.html
到了這里，關(guān)于【網(wǎng)絡(luò)安全】CSRF詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
