「Burpsuite练兵场」CSRF(一)
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界面。
这里生成的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
今天的文章分享,小伙伴们看懂了吗?