作者:Alpaca,转载于先知社区。
开局一个登录框,简单测试了几个弱口令无果后
注意力转到找回密码处
先输入两个非法的参数
点击获取验证码,抓包,查看响应代码返回0,前端显示未查询到账户信息
再来一次,抓包并修改响应包,将0改为1,放包后成功来到第二步,前端自动请求了一个后端接口发送验证码
查看该接口的响应,发现验证码作为响应体被返回了
填入验证码,直接跳转到第三步修改新密码,填入新密码后,点击提交
发现请求体里只有userIds和password两个参数,前者是要修改密码用户的uid,后者是新密码的值,猜测这里可能存在任意账户密码重置,而后又意识到我们传入的用户不存在,所以前端存储的userid变量为0,于是我们将请求包中userIds字段修改为1,尝试重置管理员密码。
后端响应为1,证明密码重置成功了,走到这里只觉喜出望外,赶紧拿着新密码去登录管理员账户
结果
想不通,难道是管理员的账户名不是admin?接连试了几个常见管理员用户名都失败后,想到还有个注册点,兴许可以爆破出管理员账号呢?
结果还是不行:
无奈,此路不通另寻他路,注意到有个APP下载的二维码,解析之,而后下载到apk
用工具快速扫描一下,发现两个移动端的接口地址有点不同寻常
访问之,好家伙,竟然返回了所有用户的uid和电话号码
惊喜之余突然回过神来,马上到接口中去检索uid为1的用户
结果证明uid=1的用户不是管理员权限,而是一个普普通通的员工id,之前由于太过笃定管理员的uid就是1,导致我们在这个点上浪费了太多时间。
随后也是通过这个未授权的接口找到了管理员的id
但是为了不对业务系统造成严重破坏,我们仅重置了一个普通用户的密码,随后成功登录以验证漏洞的存在:
本文作者:hackctf
本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/200144.html