CSRF（Cross-site request forgery，跨站点请求伪造）是一种是挟制终端用户在当前已登录的Web应用程序上执行非本意操作的攻击方法，它允许攻击者诱导用户执行他们不打算执行的操作，并且该攻击可以部分规避同源策略。通过利用受害者尚未失效的身份认证信息（cookie、会话等），诱骗其点击恶意链接或者访问包含攻击代码的页面，在受害人不知情的情况下以受害者的身份向服务器发送请求，从而完成非法操作（如更改密码，修改权限等）。
要实现CSRF攻击，需要满足三个条件：
- 拥有相关功能：该应用程序存在一个攻击者意图进行的功能，例如修改用户权限或用户密码；
- 基于cookie的会话处理：应用程序仅依靠HTTP cookie来进行会话跟踪，请求中的任何其他位置均未传送会话相关的令牌；
- 可预见的请求参数：攻击者可以确定执行操作所需的所有参数。
XSS和CSRF的比较：
- 跨站点脚本(XSS)允许攻击者在受害用户的浏览器中执行任意的JavaScript；
- 跨站点请求伪造(CSRF)允许攻击者诱导受害用户执行他们不打算执行的操作；
- CSRF可以说是跟XSS、SQL一样，属于老生常谈的问题了，因此各位应该对其原理也比较熟悉，话不多说，直接进入实验环节。
实验一：毫无防范的CSRF漏洞
实验提示：应用程序 email change模块存在CSRF漏洞。
实验要求：构造CSRF利用代码并上传到exploit server中。
使用提供的账号进行登录，登录后来到 email change界面。
输入任意值后使用Burpsuite自动生成POC。
这里生成的POC不具备自动提交功能，需要更改一下设置，然后点击Regenerate重新生成。
之后将这段POC复制到exploit server保存后即可完成实验。
实验二：基于请求方式进行token验证
实验提示：应用程序 email change模块存在CSRF漏洞，虽然添加了token，但仅防御了特定的请求方式。
实验要求：构造CSRF利用代码并上传到exploit server中。
前面的方式都一样，不同点在于生成POC后将方法POST更改为GET方法以绕过检测。
将POC保存到exploit server完成实验。
实验三：基于token存在进行验证
实验提示：应用程序email change模块存在CSRF漏洞。
实验要求：构造CSRF利用代码并上传到exploit server中。
这一实验简单的说就是当发送请求时，如果token不存在，就会跳过验证环节。
同样构造POC，然后删除csrf字段。
将POC保存到exploit server完成实验
实验四：token未关联用户会话
实验提示：应用程序 email change模块存在CSRF漏洞，虽然启用了token保护，但并未整合到站点会话管理系统当中。
实验要求：构造CSRF利用代码并上传到exploit server中。
根据提示可以推断出我们可以使用一个有效账户的csrf token覆盖攻击目标用户的token以此实现csrf攻击。
先使用wiener账户进行登录，进入email change模块修改邮箱，然后构造POC。
然后需要一个新的有效的csrf token，重新刷新进入email change模块可以发现已经有了一个新的csrf token。
将字段值进行替换
然后将POC保存到exploit server完成实验。
总结
本文介绍了CSRF原理以及一些基础的CSRF攻击场景，后面还有四个实验，相对复杂，后面公众号会持续更新。
另外专门针对于CSRF的自动扫描工具并不是很多，这里贴两个，各位小伙伴可以自行测试：
- https://github.com/s0md3v/Bolt
- https://github.com/tgianko/deemon/
TSRC 关于CSRF扫描检测的原理介绍：
https://security.tencent.com/index.php/blog/msg/24
今天的文章分享，小伙伴们看懂了吗？