简述：CSRF漏洞实际很少；条件限制很多；局限性很大；实验仅供参考，熟悉csrf概念和攻击原理即可
Pikachu靶场
CSRF GET
登录用户vince的账户可以看到用户的相关信息；
点击修改个人信息，发现数据包里除了cookie没有任何其他验证信息
通过右键Engagement tools选项找到生成csrf poc
将生成的poc复制放到html文件然后打开；或者直接选择test in browser
注意：这里的payload是通过表单进行提交的；GET请求时也可以直接构造链接进行诱导
如<a href="localhost/vul/csrf/csrfget/csrf_get_edit.php?sex=123&phonenum=123&add=123&email=123&submit=submit">iphone14抽奖立减3000元</a>
打开的页面如下；只有一个确认按钮；剩下的选项被隐藏了；一旦点击就会是用户信息都改为123
CSRF POST
同上；登录allen的账号
同样抓取修改信息的数据构造csrf poc
同样的访问csrf页面，点击按钮
点击后发现用户信息都被修改了
CSRF token
这关加了token验证；普通流程过不去
登录kobe账户；发现时GET方法；但是增加了token验证；每次请求token值都不同；由服务器随机分配的
同样的利用bp生成poc
访问链接
点击恶意链接，发现用户信息并未被修改；这是因为token验证失败的结果；
这说明对于CSRF攻击token验证就可以做到完美防御
绕过思路：可以利用bp插件绕过；下载csrf token trace插件
仅供实验参考；实际不可用；由于浏览器设置了bp作为代理；所以能实现绕过
bp下载对应插件
下载完成后对插件进行设置
此时在点击恶意链接发现用户信息被修改了；这说明该插件在请求发送之前获取了服务器的token值并对请求进行了替换
DVWA 靶场 CSRF
LOW
登录网站；点击修改密码；bp抓包；发现没什么其他验证；GET方法+cookie
通过右键工具生成csrf poc
测试poc
通过浏览器登录验证；发现密码确实被修改为了123
Medium
同样的方法；修改密码；抓包查看数据；发现跟LOW一样
获取csrf poc；
点击链接
跳转之后发现；密码未修改成功；后端进行验证了；推测时referer字段验证（只有这一个不稳定参数）
通过修改referer字段的数据验证了服务器确实检测了该字段；只允许之前访问域名中有该域名信息的链接访问；防止恶意链接跳转访问
解决方法：
1.将文件名改成目标ip地址或者域名
2.将文件放到含有目标ip地址/域名的文件夹下
3.创建一个网站域名包含目标站点的域名；然后把文件放到该网站根目录下即可
方法1和方法2可能不成功；因为referer字段有时候不包含文件名（可能是浏览器设置或者网站安全策略的问题）；如果只得到实验结果的话可以手动对referer进行修改
方法3是可以实现的；
通过小皮创建一个dvwa123的网站；因为我把dvwa网站的域名设为dvwa了；新建的域名包含目标网站的域名，将生成的poc文件放到该网站根目录下
再次访问对应的链接，通过抓包发现referer是不包含文件名的；
但是密码被修改了
High
这关使用token验证；不再验证referer字段
使用插件绕过；设置插件配置用于获取和替换目标网站的token
配置完成后直接访问poc链接；发现页面跳转了，但是没有任何提示；通过登录验证发现密码已经修改了
总结
从这几个案例中可以了解csrf的原理和危害已经防御方法
条件：同一浏览器+同时打开至少两个网站+保持登录其中一个存在csrf漏洞的网站并在另一个网站中访问了刚好针对该登录网站的恶意链接
危害：个人数据被修改；资产消失等；现实这种漏洞实现条件苛刻，了解就行
防御方法：token验证，验证码，浏览器同源策略，增加输入原始密码的选项（自定义验证字段）等
10