概述

CSRF（Cross-site request forgery）跨站请求伪造，利用跨站请求，在用户不知情的情况下，以用户的身份伪造请求，其核心是利用了浏览器 Cookie 或者 Session，盗取用户身份。

下面是 CSRF 的常见特性：
+ 依靠用户标识危害网站
+ 利用网站对用户标识的信任，欺骗用户的浏览器发送 HTTP 请求给目标站点

原理

要完成一次CSRF攻击，受害者必须依次完成两个步骤：

登录受信任网站A，并在本地生成Cookie。
在不登出A的情况下，访问危险网站B。

当用户第一次访问网站A时，网站A为用户设置了含有用户身份信息的Cookie，而用户在网站A的cookie未过期的时间内，访问了网站B，而网站B可能有多种方式令用户在不知情的情况下向网站A发起请求，例如

使用<script>以类似jsonp的方式发送get请求
使用<img>的src属性发起get请求
js脚本静默发起请求（要解决跨域问题）
在网站B上含有通往网站A的超链接，诱骗用户点击发起请求。(有些还伪装成短域名，用户无法分辨)

攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个 QQ 好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。

所以遇到 CSRF 攻击时，将对终端用户的数据和操作指令构成严重的威胁。当受攻击的终端用户具有管理员帐户的时候，CSRF 攻击将危及整个 Web 应用程序。

预防

防御手段主要是识别请求者身份。

重要数据交互采用 POST 进行接收，当然是用 POST 也不是万能的，伪造一个 form 表单即可破解。
使用验证码，只要是涉及到数据交互就先进行验证码验证，这个方法可以完全解决 CSRF。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段，不能作为主要解决方案。
验证请求头中的 Referer 字段，该字段记录了此次 HTTP 请求的来源地址，最常见的应用是图片防盗链。但有些场景不适合将来源URL暴露给服务器，所以可以设置不用上传，并且referer属性是可以修改的，所以在服务器端校验referer属性并没有那么可靠。
验证请求头中的 origin 字段，通过XMLHttpRequest、Fetch发起的跨站请求或者Post方法发送请求时，都会带上origin,所以服务器可以优先判断Origin属性，再根据实际情况判断是否使用referer判断。

还有一种非常可靠的方法是使用token验证用户身份：
+ 在浏览器向服务器发起请求时，服务器生成一个CSRF Token（字符串）发送给浏览器，然后将该字符串放入页面中
+ 浏览器请求时（如表单提交）需要带上这个CSRF Token。(可以存放在headers中)服务器收到请求后，验证CSRF是否合法，如果不合法拒绝即可。

原创文章，作者：彭晨涛，如若转载，请注明出处：https://www.codetool.top/article/web%e5%ae%89%e5%85%a8%e4%b9%8bcsrf%e6%94%bb%e5%87%bb/