攻擊手法和原理
發(fā)送到同域名的請求，瀏覽器都會自動加上Cookie，利用這個特性來偽造請求，繞過登錄態(tài)校驗。
具體例子：https://springdoc.cn/spring-security/features/exploits/csrf.html#csrf
防范措施
csrf token令牌：Spring Security優(yōu)先推薦的方式。在需要登錄態(tài)校驗的請求中（比如HEAD里）加上一個自定義token（在登錄成功時由服務(wù)端生成給前端），服務(wù)端對這個token進行校驗。
SameSite：也是Spring Security推薦的方式。限制只允許同一個域名下的頁面的請求才攜帶Cookie，比如第一個tab頁登錄了a.com，第二個tab頁面發(fā)起a.com的請求，如果第二個tab頁面的域名不是a.com、那么是不攜帶Cookie的，也就不會繞過登錄態(tài)校驗了。
Http referer：服務(wù)端通過校驗referer屬性來判斷請求是不是來自于同一個域名下的頁面，如果不是則拒絕。
補充
如果接口設(shè)計比較規(guī)范，則為了用戶體驗在http的safe method可以不進行校驗。
有些瀏覽器，比如新版的Edge、Chrome，會默認(rèn)設(shè)置SameSite=Lax， 這樣的話鏈接、GET這類請求會加Cookie，其他POST這些不加，保證了一定的安全性
參考：
https://springdoc.cn/spring-security/features/exploits/csrf.html#csrf Spring Security防范csrf的方法
https://springboot.io/t/topic/1253 SameSite講解
https://stackoverflow.com/questions/1413930/is-checking-the-referrer-enough-to-protect-against-a-csrf-attack http referer是否可以作為防范csrf的手段
https://blog.csdn.net/neal1991/article/details/114609935 http referer由瀏覽器添加、js代碼不能修改。Cookie的話如果加了HttpOnly也可以達到相同效果
你真的知道 Cookie 嗎？ SameSite 、 Secure 、 HttpOnly - javascript-lNong - SegmentFault 思否
https://www.cnblogs.com/snowie/p/15044091.html 從CSRF攻擊者視角出發(fā),滲透過程中的CSRF漏洞利用
