CSRF漏洞-个人总结
博主是网络安全的初学者，写这篇文章的目的主要是为了总结学习到的知识，方便以后查阅，如果有错误的地方，欢迎大家指出！
原理：
若在浏览器打开的情况下，某一网站有用户身份验证的cookie存在时,接受了一个黑客伪造的该网站的请求，那么这个请求就会带着用户的身份验证传送到服务端，导致用户执行了非本意的操作
存在位置
其实页面所有的都可以伪造，但个人认为实际有用的只有那些对用户账号有影响的请求，如伪造转账请求，使用户向黑客转账等；好像普通的页面访问请求等也没有必要伪造
漏洞挖掘
- 请求只有referer没有token：删掉referer还能正常请求的，存在CSRF漏洞
- 直接构建伪造请求进行测试
伪造请求
利用BurpSuite
- 准备工作：BurpSuite(下面简称为BP)，测试网站(本次用大米cms来进行测试)，测试网站的两个账号(最好用两个浏览器，这样就可以同时登陆上两个账号）
- 登陆账号，攻击者账号为root
被攻击者账号为hana
- 构造请求，本次伪造购买商品请求
随便购买一件商品
资料完善，后先不要提交订单
开启BP的请求拦截
提交订单
可以看到BP，捕捉到了订单请求
右键使用BP自带功能构造请求
点击Test in browser后把url复制出来，原本捕捉的请求就可以放掉了
- 发送伪造请求
在登陆了被攻击者账号的浏览器上，输入刚才复制的地址(大米CMS网站在关闭的情况下，也可以实现CSRF攻击，因为身份验证的cookie已经保存下来了)
点击按钮
失败，若成功的话，刷新网站页面可以看到被攻击者账号上会生成一个订单
- 失败原因
通过重新捕捉请求发现，请求体中含有”hash”这一个值，也就是说页面做了token验证
要想伪造成功，必须得知道对方的token值
利用fetch语句
在浏览器按F12，找到发送的请求，右键复制为fetch语句
在登陆了被攻击者账号的浏览器上，粘贴复制的fetch语句
删掉前面的await后，回车发送，刷新页面即可验证是否成功
防御
- 请求中加入referer验证
- 加入token验证
未完待续…
相关文章
网络安全学习篇62：CSRF 攻击_Beglage-CSDN博客
CSRF(跨站请求伪造)_谢公子的博客-CSDN博客
Token登录认证 - 简书