简述：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字段的数据验证了服务器确实检测了该字段；只允许之前访问域名中有该域名信息的链接访问；防止恶意链接跳转访问

解决方法：将文件名改成目标ip地址或者域名

修改后再次访问该链接；发现出现了成功修改的信息；通过登录测试发现密码已经变成了88888888

High

这关使用token验证；不再验证referer字段

使用插件绕过；设置插件配置用于获取和替换目标网站的token

配置完成后直接访问poc链接；发现页面跳转了，但是没有任何提示；通过登录验证发现密码已经修改了

总结

从这几个案例中可以了解csrf的原理和危害已经防御方法

条件：同一浏览器+同时打开至少两个网站+保持登录其中一个存在csrf漏洞的网站并在另一个网站中访问了刚好针对该登录网站的恶意链接

危害：个人数据被修改；资产消失等；现实这种漏洞实现条件苛刻，了解就行

防御方法：token验证，验证码，浏览器同源策略等

10