在渗透测试中，登录页常常是第一个拦路虎。本文将详细拆解一次从登录认证绕过到后台菜单“复活”的全过程，完整还原如何通过小程序接口替换、 JS 接口挖掘与数据结构适配拿到后台功能权限。
1. 后台权限获取
打开一看，是个再普通不过的后台系统，没有测试账号，爆破了半天弱口令也毫无结果。
遇到这种只有一个登录页、啥凭证都没有的情况，我通常会按下面几条思路去碰碰运气：
- 爆破常见弱口令
- 翻 JS 找硬编码的账密
- 分析登录逻辑，判断是不是前端认证（比如只依赖返回包里的某个字段）或者存在认证缺陷（比如只要带上特定 Header 就能过）
- 利用同系统其他角色/体系的认证字段尝试越权（比如普通用户和机构用户、前台注册用户和后台用户共用认证）
- 寻找隐藏的注册入口，直接自己造一个账号
- 从 JS 里挖敏感接口，逐个测试
- 登录口尝试 SQL 注入，注出账号密码或者用万能密码登录
- 利用中间件、组件的已知漏洞
在一通信息收集后，发现一个和 Web 系统同名的微信小程序。观察发现，它的域名和认证字段与 Web 后台完全一致。于是直接用小程序的手机号快捷登录接口拿到返回包，再原样替换掉 Web 后台登录请求的返回包——成功登录，触发了后续的后台请求。
然而，浏览器页面一片空白，什么都没有渲染出来。
2. 获取后台接口
登录后页面为空，通常是因为账号权限不足，后端没有返回高权限菜单数据，导致前端无法正常渲染页面。
2.1 JS 翻找接口
最常规的思路就是去 JS 里翻接口。即使当前账号权限很低，很多情况下所有接口还是会静静躺在 JS 资源里，拿到后可以直接构造参数尝试访问。
翻 JS 不光要知道找接口，还得注意翻得全不全。比如下面这个例子，默认页面只加载了部分 JS。
把已加载的接口名搜一搜就会发现，还有不少 JS 文件压根没被加载出来。收集这些文件名，写个脚本批量请求，把 JS 全部拉下来，就能测到更多接口。这种方式简单暴力，但有个弊端：如果部分接口的参数没有直接写在 JS 里，即使拿到了地址，构造参数也比较头疼。
2.2 寻找接口文档
接口文档往往包含了所有接口的完整参数说明，拿到手测试就舒服多了。除了 fuzz Swagger 这类文档组件，还可以从“获取菜单”的请求入手。比如登录后加载菜单的 URL 是 loadlist，那就可以在 JS 里搜一搜有没有 adminlist、getlist 之类的相关接口，找到后直接替换返回包，就能在页面上把功能点“画”出来。
回到我们这个例子，页面空白的原因就是这个接口返回为空：
从接口名 initMenu 也能猜到，它负责初始化功能菜单。因为返回里没有数据，所以页面什么也没渲染。我们先看看它到底传了什么值。在浏览器里打上断点拿到明文（断点调试的过程网上文章很多，就不赘述了）。
可以看到，传递的值本身就是空的，想通过修改请求参数获取更多数据基本行不通。
接着尝试全局搜索与“Menu”相关的菜单关键字，发现还有一处 initMenutree 接口，直觉告诉我这里面很可能是全部的功能页面数据！
直接访问返回 400。没关系，模仿 initMenu 接口的请求包和传值，用 POST 再发一次（数据包的签名可以靠断点调试生成，测试时我一开始忘了加密 body，不过后端照样正常处理了）。
成功拿到了完整的菜单数据。把这段包复制下来，登录我们的低权限账号，替换掉 initMenu 请求的返回包，照理说功能页面就应该出现了。但人生总是充满各种失败——页面还是空的。
3. 生成功能页面
继续分析 JS 对 initMenu 返回数据的处理逻辑。
原来页面生成时，取的是 res.data.data。而 initMenutree 接口返回的我们需要的值却藏在 res.data.data.tree 里，层级对不上，所以前端压根找不到正确的数据来渲染。
那只需要在本地把字段结构改一改就行，让 data 直接指向原本 data.tree 里的数组。
替换返回包后，后台功能页面终于被完整“复活”了。
后续抓包测试中，又发现了多处垂直越权及其他常规漏洞，这里就不再赘述。以上便是一次完整的前端认证绕过与菜单接口修复的渗透过程，云栈社区为你带来更多安全技术分享。
发表于 6 小时前
|
查看: 4|
回复: 0
