一.漏洞解释
CSRF（Cross-site request forgery），也称XSRF，跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。与XSS相似，但与XSS相比更难防范，是一种广泛存在于网站中的安全漏洞，经常与XSS一起配合攻击。
二.发生原因
1.URL请求所有的参数均可确定
2.URL请求的审核不严格，如：只验证了Cookie
三.漏洞发生过程
1.受害者登录a.com，并保留了Cookie。
2.攻击者引诱受害者访问了b.com。
3.b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。
4.a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
5.a.com以受害者的名义执行了act=xx。
6.攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作
四.常见危害
1.篡改目标网站上的用户数据；
2.盗取用户隐私数据；
3.作为其他攻击向量的辅助攻击手法；
4.传播CSRF蠕虫。
五.漏洞利用方式
1.通过HTML标签发送合法的跨域请求
2.通过Ajax发送请求（由于CORS机制的存在，一般不使用）
六.Referer头绕过
1.检测referer是否检测路径
假设原referer如下：
Referer: http://admin.teagle.top/test/
发现删除referer删除后失败后
删除域名后边的东西，成功则说明不检测路径（呃，一般不检测路径）
Referer: http://admin.teagle.top/
2.检测referer是否属于指定域
将二级域名替换为别的字符，成功则说明后台检测的是referer是否属于teagle.top域
Referer: http://aaaaa.teagle.top/
绕过：
寻找个任意二级域名*.teagle.top，构造xss
<img src=payload>
3.检测referer中包含指定关键字
将admin.teagle.top放到路径位置，域名换为别的；
成功则说明服务器检测了关键字
Referer: http://www.baidu.com/admin.teagle.top/
绕过：
构造admin.teagle.top目录，将文件放到该目录下
4.检测referer中是否含有指定的域
构造如下Referer，如果成功，则说明服务器检测了域
Referer: http://admin.teagle.top.baidu.com/
绕过：
在自己的域名上添加解析，然后将指定的域名包含进去
其他
昨天遇到一种情况，点击添加购物车后，后面跟了四个请求，针对这种情况，可以按照如下操作来决定决定性请求是哪一个：
1.四个请求走完流程
2.关掉firefox的代理，将history中的四个条目逐个发送到repeate模块
3.删除刚才添加到购物车里的东西
4.四个请求，逐个发送，每发送一次边刷新一次购物车
5.找到那个决定性请求后，删除刚才添加到购物的东西
6.再发送一次刚才发现的请求
7.如果成功，那么说明添加购物车只需要这一个请求，在这个请求上尝试csrf即可
8.如果失败，说明需要多个链接，也就意味着接近GG
七.漏洞防御方式
1) Token
我们知道CSRF攻击的请求除了Cookie以外，其他的内容必须提前确定好，那么如果我们在服务端要求提交的某一个参数中是随机的值呢？
这里我们称这个随机的、无法被预计的值叫做Token，一般是由服务端在接收到用户端请求后生成，返回给用户的Token通常放置在hidden表单或用户的Cookie里。
当用户打开正常的发送请求的页面时，服务器会生成一串随机的Token值给浏览器，在发送请求时带上此Token，服务端验证Token值，如果相匹配才执行相应的操作、销毁原Token以及生成并返回新的Token给用户，这样做不仅仅起到了防御CSRF的作用，还可以防止表单的重复提交。
由于HTML标签产生的合法跨域只能是单向请求，无法通过CSRF直接取返回的内容，所以我们无法使用CSRF先取Token值再构造请求，这使得Token可以起到防御CSRF的作用。
注意Token不应该放置在网页的Url中，如果放在Url中当浏览器自动访问外部资源，如img标签的src属性指向攻击者的服务器，Token会出现作为Referer发送给外部服务器
2) Referer
前边我们提到，CSRF伪造的请求与用户正常的请求相比最大的区别就是请求头中的Referer值不同，使用我们可以根据这点来防御CSRF。
在接收请求的服务端判断请求的Referer头是否为正常的发送请求的页面，如果不是，则进行拦截。
不过此方法有时也存在着一定的漏洞，比如可绕过等，所以最好还是使用Token。
判断Referer的一般方法就是利用正则进行判断，而判断Referer的正则一定要写全，不然就会如上所说，可绕过！曾经的Wooyun上就有许多CSRF的漏洞是由于Referer的正则不规范导致。
比如^http\:\/\/a\.com，只验证了是否Referer是否以http://a.com开头，可是没想到我们可以在自己的顶级域名添加一个子域名http://a.com.hacker.com；还有http\:\/\/a\.com\/，通过http://hacker.com/?http://a.com/绕过。
有些网站由于历史原因会允许空Referer头，当https向http进行跳转时，使用Html标签(如img、iframe)进行CSRF攻击时，请求头是不会带上Referer的，可以达到空Referer的目的。
3)设置SameSite
具体见我博客的另外一篇文章
4) 验证码
在发送请求前先需要输入基于服务端判断的验证码，机制与Token类似，防御CSRF效果非常好，不过此方法对用户的友好度很差。
5) 关注点
关于CSRF的防护应首先关注高危操作的请求，比如:网上转账、修改密码等，其次应重点关注那些可以散播的，比如：分享链接、发送消息等，再者是能辅助散播的，如取用户好友信息等，因为前者加上后者制造出来的CSRF蠕虫虽不如XSS蠕虫威力大，可是也不可小觑。最后应关注那些高权限账户能够进行的特权操作，如：上传文件、添加管理员，在许多渗透测试中，便是起初利用这点一撸到底。
八.CSRF的常用检测方法
1) 黑盒
1.首先肯定确定是否除Cookie外其他参数均可确定，即：无验证码，无Token等。
2.再者如果发现是Referer头判断的话，可以尝试是否可以绕过正则。
3.还有就是考虑能不能绕过Token，比如Url处的Token用加载攻击者服务器上的图片来获取。
4.最后可以考虑与XSS结合，如：攻击者使用iframe跨域，存在xss漏洞的网站插入的XSS执行代码为eval(window.name)，那么我们构造的iframe标签里可以添加个name属性与子页面进行通信，
2) 白盒
1.查看是否有Token，验证码，Referer等不确定参数判断。
2.判断Referer的正则是否安全。
3.判断Token返回的位置是否为安全位置。
4.判断生成的Token是否足够随机，毫无规律。
(从上到下挖掘难度依次递增)
参考：
https://www.0x002.com/2019/%E5%85%B3%E4%BA%8ECSRF%E7%9A%84%E9%82%A3%E7%82%B9%E4%BA%8B%E5%84%BF/#0x02-CSRF%E5%8E%9F%E7%90%86
https://www.cnblogs.com/-qing-/p/11015075.html
http://www.teagle.top/index.php/archives/71/