实战|记一次简单的src挖掘
2022-11-1 11:25:23 Author: www.secpulse.com(查看原文) 阅读量:22 收藏

作者: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/190162.html


文章来源: https://www.secpulse.com/archives/190162.html
如有侵权请联系:admin#unsafe.sh