查看原文
其他

实战|记一次简单的src挖掘

Alpaca 乌雲安全 2023-05-18
作者:Alpaca,转载于先知社区。

一.起

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

注意力转到找回密码处

先输入两个非法的参数

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

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

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

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

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

结果

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

二.承

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

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

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

三.转

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

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

四.合

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

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

加个好友进技术交流群

请备注:进群

欢迎 在看留言分享至朋友圈 三连

 好文推荐  


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存