注:本文仅供学习参考

csrf定义:

CSRF跨站点请求伪造(Cross—Site Request Forgery)攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。

个人理解(我是没权限修改你信息,但如果这个站点存在csrf的话,你想完成转账修改信息等操作,并且你知道这个站怎么请求这些信息的,你可以构造一个恶意的数据包,骗对方点击,对方点击后会以自己的名义给服务器发送请求是合法的,但是攻击者已经完成了他想要的操作)

csrf利用条件

目标必须已经登录这个网站存在认证信息

并且点击了攻击者的链接

所以条件是比较苛刻的通常配合xss其他漏洞使用

因此，要成功实施一次CSRF攻击，需要天时，地利，人和

实战

假设受害者为lili,登录到这个网站上

如果这个站点存在csrf，我们可以伪装恶意数据包,抓个包生成恶意数据包

可以看到信息是一一对上的,这时修改我们想修改的信息

已经修改完了,这时候发送链接给lili,这里模仿lili点击了这个链接

发现信息已经修改成为我们预想中的信息了。这就是一个很普通的csrf

我们也可以让受害者打开就提交，不用受害者点击

csrf防御修复方案

检测CSRF漏洞是一项比较繁琐的工作，最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。随着对CSRF漏洞研究的不断深入，不断涌现出一些专门针对CSRF漏洞进行检测的工具，如CSRFTester，CSRF Request Builder等。

常见三种方法

验证 HTTP Referer 字段；

在请求地址中添加 token 并验证；

在 HTTP 头中自定义属性并验证

验证 HTTP Referer 字段

验证referer字段的话就是说你从浏览器哪里来的,如果你不是从我这里去访问,而是从其他浏览器去访问的话就会禁止，认为存在危险行为。但这种Referer值根据浏览器不同而有不同的认证，依赖于第三方浏览器。相对来说不安全

在请求地址中添加 token 并验证

简单来说，就是构造一个值是攻击者所无法仿造的,服务器验证这个值后才允许一系列的操作，这个值就是token。一定是随机的，有些token根据时间制定的话不安全，但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。

在 HTTP 头中自定义属性并验证

这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护，要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。

csrf暂时总结到这里！