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登录认证 - 简书