本文主要是介绍记一次对某佛教系统的漏洞挖掘，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
前言
简单记录一次漏洞挖掘，一个系统居然爆了这么多类型的洞，于是想记录哈。(比较基础，我是菜狗，大佬轻喷)
业务介绍
是一个某佛教的系统
有一些佛教的学习资源、一些佛教相关的实物商品可购买，有个人中心，供奉活动，讲堂，禅院动态
漏洞发现
获得测试账号权限
由于没有普通用户权限，只是访客权限，于是想先注册一个账号
结果是不允许注册的，只允许已有的用户进行登录，输入我的手机号会校验是否是已有的用户，不是则不允许发送验证码
这可怎么办呢，爆破手机号显然不现实，而且就算爆破手机号，也无法收到验证码啊，这样一来连普通用户权限都没有了，这对进行其他功能点的测试来说是一个极大的阻碍
于是我不死心地再试了试测试手机号，也就是开发在做这个发送验证码的功能时，大都会创建一个默认的测试手机号，用来验证功能是否完善有无bug等等，如果开发没有即时删除这个默认的测试手机号，攻击者就能轻易以测试账号的权限登录进系统，因为这种测试账号的密码也一般就是弱口令
于是我试了试经典的 13888888888、15888888888、18888888888 都成功发送了验证码！说明存在测试账号！
抓包，看响应包
好家伙响应包直接返回了验证码！msg不就是验证码的md5值吗，md5解密即可
输入验证码，登录成功，到这里就从访客权限提升到了普通会员权限了，但是由于是测试账号，没有什么数据
OSS任意文件上传
然后果断来到修改头像处，想要试试拿shell
结果上传的文件后缀倒没有任何限制，只是全上传到OSS去了哈哈，拿shell是没戏了
还可以试试看OSS能不能解析HTML，如果可以那么就是一个存储型XSS，当然如果能解析PHP那么就拿shell了(几乎不可能)
尝试了，所有后缀都是只下载，不解析，但是可以上传任意后缀文件到OSS中
任意用户接管
看这个修改手机号的功能，一眼就有问题对吧
修改为新的手机号时，他这里只校验了当前手机号，对当前手机号发验证码，没有对新手机号进行校验，因为需要确保这个手机号的确属于你啊，否则就构成了任意用户换绑从而可接管任意用户账号！
大量水平越权
发送验证码，抓个包看看
嗯？这是个什么操作！？手机号数据直接从前端取出的，因为还带有用来脱敏的星号"*"，那么这说明了什么呢？说明他这里没有做身份校验，手机号不是按照用户权限在数据库中取出对应的手机号，而是直接从前端取出的！于是可以大胆推测这里的userid，与phone肯定是没有绑定的！既可以修改userid，又可以修改手机号！
可以看到，请求包中没有cookie，session等校验用户身份的字段，响应包直接set-cookie了！？那么肯定就是全靠userid来识别用户身份了，像这样的使用userid的来鉴权的点还有非常多，通通都可以水平越权！
既然都可以直接通过userid去set-cookie了，那么遍历一下userid就可以获得全站几乎所有用户的操作权限了撒
接着验证一下上面提到的任意用户接管，发送验证码，填写新的手机号，抓包
果然，可以直接改改手机号连前面的验证旧手机号的逻辑都可以直接跳过了，而且同理，把这个cookie删掉也是也可以直接修改用户的手机号的，也可以算是接口未授权
这里既然发了验证码，那么继续测测看，能不能短信轰炸，经简单的测试发现，虽然响应包显示发送成功，但是实际上还是只能收到一条验证码
支付逻辑缺陷
接着测一测购买的功能吧
填好表单
支付时弹了一个窗，嗯？这又是什么操作？直接前端让我选择是否完成支付，而不是调用微信支付的接口去支付？
那么我选已完成支付
查看我的订单，还真有啊？
看看数据包
看这个statusIds是1对吧，也是典中典的逻辑漏洞场景了，这个statusIds代表支付过程完成的步骤，比如正常流程是：
先给你预览订单，让你确认订单，这时statusIds=0
如果确认订单了，statusIds=1
然后让你支付，如果支付成功，statusIds=2
也就是这个statusIds代表支付过程的几个关键的节点，如果各个节点之间没有做好对上一步骤是否真的完成了的校验，那么攻击者可以直接跳步执行逻辑，从而可以跳过支付步骤，直接购买成功！
此时statusIds=1，显示状态为待支付
直接改为2，好家伙直接，显示状态为待发货了，成功跳过支付步骤
信息泄露thinkphp报错
thinphp反序列化
ThinkPHP V5.0.24版本存在反序列化漏洞
未授权访问数据库信息
通过手翻burp历史数据包找到了后台 /admin/login/index.html
发现了CMS及其版本信息
直接拿去搜索Nday，果然有一个未授权访问数据库信息Nday
/admin/system.system_databackup/tablelist.html路径可以未授权读取数据库表名
直接就读取成功了
Druid未授权访问
burp插件扫描到的Druid未授权访问
Redis未授权访问
扫了一下端口发现有6379，redis，尝试连接一下
连接成功，可以直接执行一些redis的命令
就差一点点就可以反弹shell了，结果没有写入的权限，是只读权限
这篇关于记一次对某佛教系统的漏洞挖掘的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
