攻击手法和原理
发送到同域名的请求,浏览器都会自动加上Cookie,利用这个特性来伪造请求,绕过登录态校验。
具体例子:https://springdoc.cn/spring-security/features/exploits/csrf.html#csrf
防范措施
csrf token令牌:Spring Security优先推荐的方式。在需要登录态校验的请求中(比如HEAD里)加上一个自定义token(在登录成功时由服务端生成给前端),服务端对这个token进行校验。
SameSite:也是Spring Security推荐的方式。限制只允许同一个域名下的页面的请求才携带Cookie,比如第一个tab页登录了a.com,第二个tab页面发起a.com的请求,如果第二个tab页面的域名不是a.com、那么是不携带Cookie的,也就不会绕过登录态校验了。
Http referer:服务端通过校验referer属性来判断请求是不是来自于同一个域名下的页面,如果不是则拒绝。
补充
如果接口设计比较规范,则为了用户体验在http的safe method可以不进行校验。
有些浏览器,比如新版的Edge、Chrome,会默认设置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攻击者视角出发,渗透过程中的CSRF漏洞利用