csrf攻击
CSRF攻击
记录cookie以及域名
第二步：攻击者做了一个网页，到处发链接，这个网站会去响应一个页面，会在页面里面加一个图片，
浏览器在渲染的过程中会请求这个地址，请求到了银行的服务器，转账给谁，转多少钱
请求的是银行，请求的地址和之前在cookie时记录的地址是一样的，之前的cookie会被带过去
请求已经发出去了
防御方式
1.第一种，
最狠的，不用cookie,浏览器就不会去自动携带，对于上面的转账请求就不会被发送出去了
身份是需要用js代码加到请求头里的
所以一些单页面应用都是使用localStorage来存储，不用cookie了
问题
兼容性比较差，有些可能不支持localStorage
ssr可能会遇到困难
正常页面请求时请求一个空页面，然后用js来去生成一些页面，在客户端完成DOM的创建和渲染
服务端渲染，就是服务器已经将页面创建好了，
最早的页面都是服务端渲染，
客户端渲染的话，好处就是服务器压力比较小，
服务端渲染的话，利于seo,搜索引擎更喜欢服务端渲染，搜索引擎不会运行你的js
服务端渲染也会遇到问题，登录之后看到的页面和登录之前看到的页面，由于页面是在服务器创建的，服务器需要知道你有没登录，但是没有使用cookie,他就不知道你有没有登录，（第一次请求），所以就会遇到困难
但是可以解决的，服务器引导你到另一个界面，发送localStorage，这样他就知道你有没有登录了
2.sameSite
sameSite:none
sameSite:strict目前处于什么页面，目前处在危险页面，就不能发送cookie,但是有些太严格了
sameSite=Lax：宽松的，get请求发cookie,post请求不带cookie，因为对数据产生影响的一般都是post请求
问题：
兼容性比较差
容易挡住自己人（因为大公司的网站，很多都是跨站访问的，这样限制，很容易个自己人挡住）
3.使用CSRF token
对网站数据有影响的操作，不光光会验证身份，还会去验证csrf token
首先是拿到转账的页面，然后再提交
在去请求表单的时候，服务器会随机生成一个token，随机生成的，不是用户登录的那个token,通过session记录，一次性的，用过就失效了，同时发给客户端
CSRF Token 是 服务器生成 → 给前端（HTML 或 API 返回） → 前端 JS 主动加到请求里，而不是依赖 cookie 自动带上。
这样攻击者就算能让浏览器发请求，也没法伪造正确的 token。
验证之后，说明你是通过我的网页提交的，
问题：
一般来说服务器都给token删了，但是有一个比较特别的场景
用户有可能，访问，想去转账，拿到token,但是没有提交，这个时候点击了危险网站，所以就出问题了，但是这种情况非常的少
CSRF Token 的流程
- 存储：后端生成 CSRF Token，把它保存在当前用户的 Session 里（方便之后验证）。
- 下发：通过 HTML 页面（meta/hidden input）或者 API 把这个 token 数据传给前端。
- 发送请求：前端 手动把这个 token 放到请求头（或请求体）中。
- 验证：后端用 cookie 里的 Session ID 找到 Session，从中取出 token 对比请求里带的 token。
4.referer防护过去比较常用
无论是post请求还是get请求都有一个referer,代表的地址源，不是白名单里面的，就有可能是伪造请求，非常简单有效的方式
但是他防不了base64编码，如果是base64的话，请求就不会带referer了