CSRF 攻擊可以使用以下方法來防護(hù)：

　　進(jìn)行同源檢測，服務(wù)器根據(jù) http 請求頭中 origin 或者 referer 信息來判斷請求是否為允許訪問的站點(diǎn)，從而對請求進(jìn)行過濾。當(dāng) origin 或者 referer 信息都不存在的時候，直接阻止請求。這種方式的缺點(diǎn)是有些情況下 referer 可以被偽造，同時還會把搜索引擎的鏈接也給屏蔽了。所以一般網(wǎng)站會允許搜索引擎的頁面請求，但是相應(yīng)的頁面請求這種請求方式也可能被攻擊者給利用。(Referer 字段會告訴服務(wù)器該網(wǎng)頁是從哪個頁面鏈接過來的)

　　使用 CSRF Token 進(jìn)行驗證，服務(wù)器向用戶返回一個隨機(jī)數(shù) Token ，當(dāng)網(wǎng)站再次發(fā)起請求時，在請求參數(shù)中加入服務(wù)器端返回的 token ，然后服務(wù)器對這個 token 進(jìn)行驗證。這種方法解決了使用 cookie 單一驗證方式時，可能會被冒用的問題，但是這種方法存在一個缺點(diǎn)就是，我們需要給網(wǎng)站中的所有請求都添加上這個 token，操作比較繁瑣。還有一個問題是一般不會只有一臺網(wǎng)站服務(wù)器，如果請求經(jīng)過負(fù)載平衡轉(zhuǎn)移到了其他的服務(wù)器，但是這個服務(wù)器的 session 中沒有保留這個 token 的話，就沒有辦法驗證了。這種情況可以通過改變 token 的構(gòu)建方式來解決。

　　對 Cookie 進(jìn)行雙重驗證，服務(wù)器在用戶訪問網(wǎng)站頁面時，向請求域名注入一個Cookie，內(nèi)容為隨機(jī)字符串，然后當(dāng)用戶再次向服務(wù)器發(fā)送請求的時候，從 cookie 中取出這個字符串，添加到 URL 參數(shù)中，然后服務(wù)器通過對 cookie 中的數(shù)據(jù)和參數(shù)中的數(shù)據(jù)進(jìn)行比較，來進(jìn)行驗證。使用這種方式是利用了攻擊者只能利用 cookie，但是不能訪問獲取 cookie 的特點(diǎn)。并且這種方法比 CSRF Token 的方法更加方便，并且不涉及到分布式訪問的問題。這種方法的缺點(diǎn)是如果網(wǎng)站存在 XSS 漏洞的，那么這種方式會失效。同時這種方式不能做到子域名的隔離。

　　在設(shè)置 cookie 屬性的時候設(shè)置 Samesite ，限制 cookie 不能作為被第三方使用，從而可以避免被攻擊者利用。Samesite 一共有兩種模式，一種是嚴(yán)格模式，在嚴(yán)格模式下 cookie 在任何情況下都不可能作為第三方 Cookie 使用，在寬松模式下，cookie 可以被請求是 GET 請求，且會發(fā)生頁面跳轉(zhuǎn)的請求所使用。