什么是CRSF
構(gòu)建一個(gè)地址，比如說(shuō)是刪除某個(gè)博客網(wǎng)站博客的鏈接，然后誘使已經(jīng)登錄過(guò)該網(wǎng)站的用戶點(diǎn)擊惡意鏈接，可能會(huì)導(dǎo)致用戶通過(guò)自己的手將曾經(jīng)發(fā)布在該網(wǎng)站的博客在不知情的情況下刪除了。這種構(gòu)建惡意鏈接，假借受害者的手造成損失的攻擊方式就叫CSRF-跨站點(diǎn)請(qǐng)求偽造。
瀏覽器Cookie策略
cookie分類
cookie根據(jù)有無(wú)設(shè)置過(guò)期時(shí)間分為兩種，沒(méi)有設(shè)置過(guò)期時(shí)間的為Session Cookie（會(huì)話cookie），firefoox有標(biāo)注哪些cookie是會(huì)話cookie，這種cookie保存在內(nèi)存空間中，在瀏覽器進(jìn)程的生命周期中都有效，但是一關(guān)閉瀏覽器就被抹除。另外一種設(shè)置過(guò)期時(shí)間的叫做third-party Cookie,也稱之為本地cookie，保存在本地，在過(guò)期時(shí)間內(nèi)都可以使用。
CSRF實(shí)現(xiàn)原理
一般用戶的操作都需要登錄以后才能進(jìn)行，csrf就是利用用戶的登錄cookie，讓用戶在自己的惡意網(wǎng)站中向博客網(wǎng)站發(fā)送了刪除請(qǐng)求。比如讓用戶點(diǎn)擊鏈接黑客的網(wǎng)站，黑客在網(wǎng)站中加上一個(gè)圖片鏈接，該鏈接實(shí)際是向博客網(wǎng)站發(fā)送一個(gè)刪除請(qǐng)求：
惡意網(wǎng)站
<html>
<p>這是黑客誘導(dǎo)客戶訪問(wèn)的惡意網(wǎng)站地址</p>
<img src = "http://csdn.com?delete=10">
</html>
要實(shí)現(xiàn)這個(gè)還需要用到用戶登錄csdn后的cookie，之前談同源策略的時(shí)候說(shuō)過(guò)，img、iframe之類的標(biāo)簽不受同源策略的影響，所以當(dāng)向csdn發(fā)送請(qǐng)求時(shí)，會(huì)將csdn相關(guān)的cookie都一并提交上去（會(huì)提交哪些cookie需要根據(jù)cookie作用域來(lái)決定），這樣csdn驗(yàn)證cookie后誤認(rèn)為是用戶在操作，實(shí)際上用戶是在無(wú)意識(shí)下刪除了自己的文章。
老版的ie，safari是禁止img、iframe標(biāo)簽請(qǐng)求時(shí)發(fā)送cookie的，但是最新的firefox以及chrome等主流瀏覽器都是允許的。
對(duì)于老版的ie等是允許發(fā)送會(huì)話cookie的，如果想發(fā)送本地cookie，需要在網(wǎng)站返回給瀏覽器HTTP頭中含有P3P，這樣下一次訪問(wèn)網(wǎng)站時(shí)將允許發(fā)送本地cookie。
同源策略是瀏覽器實(shí)現(xiàn)的，只要請(qǐng)求發(fā)出瀏覽器，同源策略和跨域就用不到了！
實(shí)踐
我在自己博客找到一個(gè)get請(qǐng)求（博客點(diǎn)贊請(qǐng)求）：
從上圖可以看到點(diǎn)贊請(qǐng)求帶了一堆cookie驗(yàn)證到后臺(tái)，現(xiàn)在我寫(xiě)一個(gè)新界面，界面里面用img標(biāo)簽跨域訪問(wèn)這個(gè)請(qǐng)求（前提是csdn是登錄狀態(tài)，不然拿不到cookie驗(yàn)證）；
啟動(dòng)訪問(wèn)本地請(qǐng)求：
上面的本地界面確實(shí)因?yàn)樵L問(wèn)csdn的請(qǐng)求而加載了一些csdn的cookie，其中應(yīng)該包含了登陸驗(yàn)證的字段，所以對(duì)應(yīng)的這個(gè)服務(wù)應(yīng)該成功了，檢查下那篇博客確實(shí)多了一個(gè)點(diǎn)贊。
CSRF的防御
方案一 驗(yàn)證碼
強(qiáng)制需要客戶進(jìn)行交互才能操作。跟CSRF在客戶不知情的情況下完成攻擊的方式相餑
方案二 Referer Check
Referer Check最常見(jiàn)的應(yīng)用就是防止圖片盜鏈，通過(guò)查看請(qǐng)求的來(lái)源判斷請(qǐng)求是否合理，比如通過(guò)攻擊者的網(wǎng)站嵌入訪問(wèn)博客的地址，那referer就是攻擊者網(wǎng)站的地址，這樣很大程度能判斷出這是一個(gè)CSRF攻擊，但是這個(gè)方法的缺陷是：服務(wù)器并不是每次都能取到Referer信息。
方案三 構(gòu)造不可預(yù)見(jiàn)性URL
CSRF能夠攻擊成功，其本質(zhì)原因是請(qǐng)求的URL被攻擊者猜到，如果請(qǐng)求的URL具有不可預(yù)測(cè)性，那么攻擊者也就無(wú)從下手。現(xiàn)在最通用的方式就是在URL中加入一個(gè)token參數(shù)。token可以存在用戶的cookie中，服務(wù)器也存有該客戶對(duì)應(yīng)的token值。因?yàn)镃SRF攻擊只是利用登錄cookie，并無(wú)法獲取cookie的具體值（除非用戶還被XSS攻擊了，導(dǎo)致cookie泄露，那就無(wú)濟(jì)于事了）。
token應(yīng)該同時(shí)放在提交表單中與服務(wù)器session中，在有效時(shí)間之內(nèi)，只要服務(wù)器session沒(méi)有被使用(即用戶沒(méi)有提交表單，這個(gè)需要服務(wù)器提供一個(gè)方案判斷某個(gè)session是否已經(jīng)被使用過(guò))，都使用同一個(gè)token，否則需要重新生成token，并保存到表單和session中。
token也應(yīng)該注意保密性，不應(yīng)出現(xiàn)在url中，因?yàn)檫@樣可以通過(guò)referer獲取到，一個(gè)盡量放在表單中，把敏感的操作由GET改為POST，一form表單或者AJAX的形式提交，可以避免token泄露。
方案四： SameSite Cookie，防止 CSRF 攻擊
防止 CSRF 攻擊的辦法已經(jīng)有 CSRF token 校驗(yàn)和 Referer 請(qǐng)求頭校驗(yàn)。為了從源頭上解決這個(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
https://www.cnblogs.com/ziyunfei/p/5637945.html
