概述
CSRF(Cross-site request forgery,跨站请求伪造)。
它是指攻击者利用了用户的身份信息，执行了用户非本意的操作。
它首先引导用户访问一个危险网站，当用户访问网站后，网站会发送请求到被攻击的站点，这次请求会携带用户的cookie发送，因此就利用了用户的身份信息完成攻击。
防御方式
SameSite
SameSite 是一个与 HTTP 状态码和响应头相关的属性，用于定义浏览器如何处理跨站点请求。这个属性主要用于防止跨站点请求伪造（CSRF，Cross-Site Request Forgery）攻击，它允许服务器要求某些类型的 cookie 在跨站点请求中不被发送。
以下是 SameSite 属性的几种取值及其含义：
-
Strict: 这种模式下，cookie 将不会被包含在任何跨站点请求中。也就是说，只有在请求的域与设置 cookie 的域完全一致时，cookie 才会被发送。
-
Lax: 这种模式下，cookie 将被包含在顶层导航请求中，但不会在跨站点请求中被发送。例如，如果你从一个网站链接到另一个网站，浏览器会发送 cookie，但如果你尝试通过 JavaScript 发起一个跨站点请求，cookie 则不会被发送。get 请求会携带 cookie，但是 post 请求不携带。
-
None: 这种模式下，cookie 将被包含在跨站点请求中。如果你想让 cookie 在跨站点请求中被发送，就需要将
SameSite设置为None，并且同时设置Secure属性，以确保 cookie 只在 HTTPS 上传输。
从 Chrome 80 开始，默认的 SameSite 变更为 SameSite=Lax，这意味着如果你的服务器没有明确设置 SameSite 属性，那么浏览器将默认以 Lax 模式处理 cookie。
为了确保跨站点请求能够正确地携带 cookie，你需要：
- 设置
SameSite=None。 - 设置
Secure属性，确保 cookie 只在 HTTPS 上传输。
示例代码：
Set-Cookie: key=value; SameSite=None; Secure
使用 CSRF Token
CSRF Token 是一种常见的防御机制，它要求每个请求都必须包含一个由服务器生成的、随机的、唯一的 token。服务器在处理请求时会验证这个 token 是否有效。具体步骤如下：
- 生成 Token: 当用户登录后，服务器生成一个 CSRF Token 并将其存储在服务器端的会话中。
- 发送 Token: 服务器将 Token 发送给客户端，并要求客户端在后续的请求中包含这个 Token。
- 验证 Token: 当客户端发起请求时，服务器会检查请求中是否包含 Token，并且验证 Token 是否与服务器端存储的 Token 匹配。
这种方法的关键在于，攻击者无法预测 Token 的值，因此即使他们能够诱导用户点击链接或提交表单，由于 Token 不匹配，请求也会被服务器拒绝。
比如这里我打开某网站，他就是使用的 csrfToken。
什么是CSRF？为什么CSRF Token写在COOKIE里面？_csrf cookie-CSDN博客
使用 Referer 检查
Referer 是 HTTP 请求头中的一个字段，用于指示请求是从哪个页面发起的。服务器可以通过检查 Referer 来防御 CSRF 攻击：
- 检查 Referer: 服务器在处理请求时，检查请求的 Referer 头部，确认请求是否来自可信的来源。
- 验证来源: 如果 Referer 头部指向的是攻击者的域名，服务器可以拒绝处理请求。
然而，这种方法有几个局限性：
- 用户可能禁用了 Referer 头部，或者浏览器设置可能导致 Referer 头部不被发送。
- 攻击者可以构造请求，使其 Referer 头部指向合法的来源。
- 不能访问 base64 编码
