CSRF、Cross Site Request Forgery是一种网络攻击方式，2007年被列为互联网20大安全风险之一。
网站通过cookie识别用户。 如果用户验证成功，浏览器将获取标识其身份的cookie。 以后访问此网站时，请带上此cookie，除非您关闭浏览器或退出登录。 如果在此期间浏览器被控制为请求该网站的url，则用户可能会执行不想做的行为(修改个人资料、严重行为(**** ) () ) ) 这些请求也可以通过第三方网站提交。 也就是说，是跨站。
CRF攻击是攻击者使用受害者的cookie骗取服务器信任，但攻击者无法获得cookie，也看不到cookie的内容。 另外，关于服务器返回的结果，由于浏览器的同构策略的限制，攻击者也无法分析。 因此，攻击者无法从返回的结果中获得任何信息，只能向服务器发送请求，执行请求中包含的命令，直接更改数据值，而不是在服务器端窃取服务器数据。 所以应该保护的对象是可以直接产生数据变更的服务。
CSRF的防御策略(From IBM DeveloperWorks )针对CSRF攻击的防御策略主要有三种。
验证HTTP Referer字段
根据HTTP协议，HTTP头部包含一个名为Referer的字段，用于记录HTTP请求的源地址。 通常，同一站点请求访问受安全限制的页面。 例如，是否需要访问http://bank.example/withdraw？ 对于account=bob amount=1000000 for=mallory，用户必须首先登录bank.example，然后单击页面上的按钮触发转移事件。 在这种情况下，转账请求的Referer值是转账按钮所在页面的URL。 通常是以bank.example域名开头的地址。 如果黑客对银行网站实施CSRF攻击，他只能在自己的网站上创建请求。 当用户通过黑客网站向银行发送请求时，该请求的Referer指向黑客自己的网站。 因此，为了防御CSRF攻击，银行站点只需验证每个转账请求的Referer值即可。对于以bank.example开头的域名，该请求来自银行站点本身，表示是合法的。 如果Referer是其他站点，则可能是黑客对CSRF的攻击，将拒绝该请求。
这个方法的明显好处是简单。 站点的典型开发人员不需要在意CSRF漏洞，最后只需在所有安全敏感的请求中添加拦截器来检查Referer的值。 特别是对于当前现有的系统，不需要修改当前系统的现有代码和逻辑，没有风险，非常方便。
但是，这个方法并不万全。 Referer的值由浏览器提供。 虽然HTTP协议有明确的要求，但每个浏览器的Referer的具体实现可能存在差异，并不保证浏览器本身没有安全漏洞。 验证Referer值的方法是将安全性全部依赖于第三方，也就是浏览器来保障，理论上是不安全的。 事实上，一些浏览器(如IE6和FF2 )目前有多种篡改Referer值的方法。 如果bank.example站点支持IE6浏览器，黑客可以将用户浏览器的Referer值设置为以bank.example域名开头的地址，并通过身份验证进行CSRF攻击。
即使使用最新的浏览器，黑客也无法篡改Referer值。 这个方法还有问题。 由于Referer值记录用户的访问源，因此一些用户认为这侵犯了自己的隐私权。 特别是，一些组织担心Referer值会将组织内部网络中的某些信息泄露到外部网络。 因此，用户可以自行设置浏览器，以便在提交请求时不再提供Referer。 当他们正常访问银行站点时，该站点会将其视为CSRF攻击，因为请求中没有Referer值，并拒绝合法用户访问。
(简单地说，虽然是甜瓜，但是误报率很高，也有可能影响部分特别用户的使用)
将token添加到请求地址并进行验证
CSRF攻击成功是因为黑客可以完全伪造用户的请求。 此请求中的所有用户凭据都存在于cookie中，因此黑客可以直接利用自己的cookie进行安全验证，而无需知道这些凭据。 为了防止CSRF，黑客将无法伪造的信息放入请求中，该信息不存在于cookie中是很重要的。 您可以将随机生成的token作为参数添加到HTTP请求中，并在服务器端创建拦截器以验证该token。 如果请求中没有token或token的内容不正确，则认为可能存在CSRF攻击而拒绝该请求。
这个方法比检查Referer更安全。 token可以在用户登录后生成并放入session中，在每次请求时从session中取出token并与请求中的token进行匹配，但这种方法的难点在于如何将token作为参数添加到请求中。 对于获取请求，token会附加在请求地址之后。 这样URL就变成http://url了吗？ csrftoken=tokenvalue。 对于POST请求，请将其添加到form末尾。 这将token作为参数添加到请求中。 但是，在一个网站上，可以接受请求
求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，**通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。**这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。
（更安全，也相对复杂一些）
在HTTP头中添加自定义属性并验证
这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护，要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。
（没有方法2那么复杂，但是用户体验下降，对于现成网站的加护工作量大）
CSRF产生危险的核心就是利用他人的cookie。区别对待带cookie和不带cookie两种情况是扫描器的检测逻辑的关键点。CSRF Scanner的检测步骤如下：
不带cookie访问页面得到form1带cookie访问页面得到form2判断form1与form2是否为同一个表单，是，则继续检测；否，则进入下一检测对象。判断form2是否存在token、g_tk等字样，如果不存在，则继续检测；存在，则说明对象有做一定的CSRF防御（上述方法2），为了提高检测效率，进入下一检测对象。判断form2是否存在search、login等字样，如果不存在，则继续检测；存在，则说明提交的表单不存在敏感性（仅做查询操作而非修改）判断form2是否存在保存、修改、提交等白名单字样，如果存在，则说明对象具有一定的敏感性（存在数据修改行为），具有敏感性而又没有检测到相应的防护措施，提交CSRF漏洞报告。 Y N Y N Y N Y N 不带cookie访问页面得到form1 带cookie访问得到form2 判断form1与form2是否相同 结束 form2是否存在token和g_tk等字样 form2是否存在search和login等字样 form2是否存在修改和保存等敏感 字样 对象存在CSRF漏洞 参考资料 IBM DeveloperWorkshttps://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/index.html腾讯安全应急响应中心
https://security.tencent.com/index.php/blog/msg/24