一、Cross-site request forgery/ˈfɔːrdʒəri/，跨站请求伪造，通常缩写为 CSRF 或 XSRF，它利用用户已登录的身份，在用户毫不知情的情况下，以用户的名义完成非法操作。
原理
一、下面先介绍一下 CSRF 攻击的原理：
二、完成 CSRF 攻击必须要有三个条件：
● 用户已经登录了站点 A，并在本地记录了 cookie
● 在用户没有登出站点 A 的情况下（也就是 cookie 生效的情况下），访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点 A)。
● 站点 A 没有做任何 CSRF 防御
| 【示例】当我们登入转账页面后，突然眼前一亮惊现”XXX 隐私照片，不看后悔一辈子”的链接，耐不住内心躁动，立马点击了该危险的网站（页面代码如下图所示），但当这页面一加载，便会执行 submitForm 这个方法来提交转账请求，从而将 10 块转给黑客。
| ———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————- |
| 【示例】你登录了 bank.com 网站。此时：你有了来自该网站的身份验证 cookie。你的浏览器会在每次请求时将其发送到 bank.com，以便识别你，并执行所有敏感的财务上的操作。 现在，在另外一个窗口中浏览网页时，你不小心访问了另一个网站 evil.com。该网站具有向 bank.com 网站提交一个具有启动与黑客账户交易的字段的表单 |
|---|
| 【示例】跨站攻击示意图
上图中攻击者利用了 Web 中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
| ————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————- |
防御措施
一、防范 CSRF 攻击可以遵循以下几种规则：
●Get 请求不对数据进行修改
● 不让第三方网站访问到用户 Cookie
● 阻止第三方网站请求接口
● 请求时附带验证信息，比如验证码或者 Token
二、防御措施
● 检查 referer 字段
● 同步表单校验：表单中带有服务器生成的 token，提交时要带上
● 双重 cookie 校验
SameSite
一、可以对 Cookie 设置 SameSite 属性。
见 Cookie, document.cookie#SameSite：https://www.yuque.com/tqpuuk/yrrefz/ns4z0t
Referer Check
一、HTTP Referer 是 header 的一部分，当浏览器向 web 服务器发送请求时，一般会带上 Referer 信息告诉服务器是从哪个页面链接过来的，服务器借此可以获得一些信息用于处理。
二、可以通过检查请求的来源来防御 CSRF 攻击。
三、正常请求的 referer 具有一定规律，如在提交表单的 referer 必定是在该页面发起的请求。所以通过检查 http 包头 referer 的值是不是这个页面，来判断是不是 CSRF 攻击。
四、在某些情况下如从 https 跳转到 http，浏览器处于安全考虑，不会发送 referer，服务器就无法进行 check 了。若与该网站同域的其他网站有 XSS 漏洞，那么攻击者可以在其他网站注入恶意脚本，受害者进入了此类同域的网址，也会遭受攻击。
1、出于以上原因，无法完全依赖 Referer Check 作为防御 CSRF 的主要手段。
2、但是可以通过 Referer Check 来监控 CSRF 攻击的发生。
五、优点
1、简单易行，仅需要在关键访问处增加一步校验。
六、局限性
1、其完全依赖浏览器发送正确的 Referer 字段。虽然 HTTP 协议对此字段的内容有明确的规定，但并无法保证来访的浏览器的具体实现，亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器，篡改其 Referer 字段的可能。
Anti CSRF Token（用得最多）
一、目前比较完善的解决方案是加入 Anti-CSRF-Token。
1、即发送请求时在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器建立一个拦截器来验证这个 token。
2、服务器读取浏览器当前域 cookie 中这个 token 值，会进行校验该请求当中的 token 和 cookie 当中的 token 值是否都存在且相等，才认为这是合法的请求。否则认为这次请求是违法的，拒绝该次服务。
二、这种方法相比 Referer 检查要安全很多，token 可以在用户登陆后产生并放于 session 或 cookie 中，然后在每次请求时服务器把 token 从 session 或 cookie 中拿出，与本次请求中的 token 进行比对。
三、由于 token 的存在，攻击者无法再构造出一个完整的 URL 实施 CSRF 攻击。但在处理多个页面共存问题时，当某个页面消耗掉 token 后，其他页面的表单保存的还是被消耗掉的那个 token，其他页面的表单提交时会出现 token 错误。
| 【示例】】在同步渲染页面时，在表单请求中增加一个_csrf 的查询参数，这样当用户在提交这个表单的时候就会将 CSRF token 提交上来```javascript
``` | | --- |
四、token 仅仅是预防 csrf 用的。如果攻击者使用 xss 获取到 token，那么该方案就会失效。这样的攻击可以称为 xsrf
双重 cookie 校验
一、一重是浏览器自动附加的 cookie，另一重就是在页面代码中通过其他手段（自定义请求头、请求体、URL 查询参数）传递的 cookie。
二、攻击者发起 CSRF 攻击时，请求中只会包含浏览器附加的 cookie 请求头，把这种只有一重 cookie 的请求拦掉就实现了防御。
验证码
一、应用程序和用户进行交互过程中，特别是账户交易这种核心步骤，强制用户输入验证码，才能完成最终请求。在通常情况下，验证码够很好地遏制 CSRF 攻击。
二、但增加验证码降低了用户的体验，网站不能给所有的操作都加上验证码。所以只能将验证码作为一种辅助手段，在关键业务点设置验证码。
