记一次简单的src挖掘

一.起

开局一个登录框,简单测试了几个弱口令无果后

图片[1]-记一次简单的src挖掘-NGC660 安全实验室

注意力转到找回密码处

图片[2]-记一次简单的src挖掘-NGC660 安全实验室

先输入两个非法的参数

图片[3]-记一次简单的src挖掘-NGC660 安全实验室

点击获取验证码,抓包,查看响应代码返回0,前端显示未查询到账户信息

图片[4]-记一次简单的src挖掘-NGC660 安全实验室
图片[5]-记一次简单的src挖掘-NGC660 安全实验室

再来一次,抓包并修改响应包,将0改为1,放包后成功来到第二步,前端自动请求了一个后端接口发送验证码

图片[6]-记一次简单的src挖掘-NGC660 安全实验室

查看该接口的响应,发现验证码作为响应体被返回了

图片[7]-记一次简单的src挖掘-NGC660 安全实验室

填入验证码,直接跳转到第三步修改新密码,填入新密码后,点击提交

图片[8]-记一次简单的src挖掘-NGC660 安全实验室

发现请求体里只有userIds和password两个参数,前者是要修改密码用户的uid,后者是新密码的值,猜测这里可能存在任意账户密码重置,而后又意识到我们传入的用户不存在,所以前端存储的userid变量为0,于是我们将请求包中userIds字段修改为1,尝试重置管理员密码。
后端响应为1,证明密码重置成功了,走到这里只觉喜出望外,赶紧拿着新密码去登录管理员账户

图片[9]-记一次简单的src挖掘-NGC660 安全实验室

结果

图片[10]-记一次简单的src挖掘-NGC660 安全实验室

想不通,难道是管理员的账户名不是admin?接连试了几个常见管理员用户名都失败后,想到还有个注册点,兴许可以爆破出管理员账号呢?
结果还是不行:

图片[11]-记一次简单的src挖掘-NGC660 安全实验室

二.承

无奈,此路不通另寻他路,注意到有个APP下载的二维码,解析之,而后下载到apk

图片[12]-记一次简单的src挖掘-NGC660 安全实验室

用工具快速扫描一下,发现两个移动端的接口地址有点不同寻常

图片[13]-记一次简单的src挖掘-NGC660 安全实验室

访问之,好家伙,竟然返回了所有用户的uid和电话号码

图片[14]-记一次简单的src挖掘-NGC660 安全实验室

三.转

惊喜之余突然回过神来,马上到接口中去检索uid为1的用户

图片[15]-记一次简单的src挖掘-NGC660 安全实验室

结果证明uid=1的用户不是管理员权限,而是一个普普通通的员工id,之前由于太过笃定管理员的uid就是1,导致我们在这个点上浪费了太多时间。

四.合

随后也是通过这个未授权的接口找到了管理员的id

图片[16]-记一次简单的src挖掘-NGC660 安全实验室

但是为了不对业务系统造成严重破坏,我们仅重置了一个普通用户的密码,随后成功登录以验证漏洞的存在:

图片[17]-记一次简单的src挖掘-NGC660 安全实验室

本文作者:Alpaca

本文转载于先知社区,如有侵权请联系删除

© 版权声明
THE END
喜欢就支持一下吧
点赞5 分享