医疗系统登录框渗透测试全记录：从信息收集到管理员后台突破

本文将以一次真实的医疗系统渗透项目为例，详细拆解如何从一个前端登录框开始，通过系统的信息收集、接口测试与逻辑分析，最终突破防线进入管理员后台的全过程。整个思路连贯，操作细致，无论是对漏洞挖掘入门的新手，还是对登录框测试感到无从下手的同仁，都希望能带来一些启发。

信息收集与前台功能分析

开局只有一个登录框。通过观察域名中的 # 符号，并借助 Wappalyzer 浏览器插件，可以识别出这是一个使用 Vue.js 构建的前端站点，并且使用了经典的 Webpack 打包器。

面对这种情况，在功能点测试之外，前期可以尝试的渗透测试思路主要包括以下几点，基本上是逐一尝试，目标明确：主线是进入管理员后台，支线则是发现信息泄露或其他高危漏洞。

1. 常规接口未授权访问测试
2. 利用哈希路由或插件（如VueCrack）主动拼接页面，尝试触发后端接口
3. 收集全量的异步JS（chunk文件），通过正则脚本提取隐藏接口

对登录功能进行简单测试，发现系统存在用户名枚举漏洞（返回提示并非简单的“账号或密码错误”）。既然 admin 用户存在，便使用小字典在后台进行密码爆破。TOP3000 字典未命中，考虑到 admin 用户可能只是系统预设并未实际投入使用（实践中管理员常会新建独立账号），更复杂的字典意义不大，但弱口令测试作为常规步骤仍需保留。

尝试使用单双引号、万能密码等进行注入测试，均无回显，属于正常情况。于是快速转入接口测试阶段。通过测试发现，前端功能点调用的后端地址是一个新的域名 (api-xxxxxx.com)，这符合前后端分离的架构。后续所有的接口拼接测试，都需要基于这个实际提供服务的后端域名进行。

未授权接口测试

通过插件捕获到大量完整的、带有斜杠 / 的绝对路径API接口。结合之前的发现：前端页面在 a.com，后端服务在 b.com。因此，我们的接口测试需要针对 b.com 这个域名展开。

接口的拼接测试往往有章可循。如果站点鉴权存在缺陷，第一轮简单的 GET 请求拼接就可能暴露出大量未授权信息。再利用这些泄露信息中的蛛丝马迹，如账户、工号特征，构造用户名清单进行密码喷洒，是常见的突破手段。再不济，也可能发现 export 这类导出接口，直接获取业务数据。

---

然而，对插件提取的接口进行第一次 GET 请求拼接，全部返回登录页面或无响应。前台功能测试确定不存在前置目录，且部分接口返回状态码 500，提示“请先登录”。这个响应恰恰证明了接口路径是正确的，只是被鉴权拦截了。

GET XXXXXXXXXX

尝试 POST 请求模式效果更差，所有请求都被 500 状态码拦截，无一返回有效信息。后续对接口进行简单的 Fuzz 测试也一无所获。虽然本次在提供服务的后端域名 (b.com) 上未获成功，但在实战中，对前端展示域名 (a.com) 的测试也绝不能遗漏。

POST xxxxxx

Content-Type: application/json

{}

哈希路由页面测试

第一个方案（常规接口拼接）未能奏效，转而利用 VueCrack 等工具或手动尝试访问哈希路由页面 (# 后路径)，目的是触发其他功能接口，观察是否有新的信息泄露。此时需要耐心逐个访问，并开启Burp Suite记录所有产生的流量。

当跳转到具体功能页面（如用户管理）时，就像正常测试功能点一样，尝试输入查询值，观察是否会有接口被调用。对于导入导出等功能，可以测试文件上传、SSRF等漏洞。

#/userAccount

搜索功能处可测试SQL注入，尤其当出现排序选项时，不要忘记经典的 order by 注入测试。尝试跳转了几个路由页面，均无法成功调用后台接口，此路暂时不通。

/#/SpManagement

柳暗花明的是，在调整到注册页面 (/#/register) 时，发现可以成功调用注册功能。提交注册请求后，服务器返回了有效的 JWT (Json Web Token)，这意味着我们成功注册了一个低权限账号。

但是，使用这个刚注册的账号密码去登录系统却失败了，系统提示“部门错误”，说明账号权限仍受限制。不过，成功注册获得的 JWT 相当于我们已经有了一个“身份凭证”。接下来，可以携带这个未被系统完全“认可”的 JWT 去重新测试之前的接口，检验是否存在越权访问。

利用低权限JWT进行接口测试

携带这个低权限 JWT 重新对接口进行 GET 请求测试，发现了一个突破口：/student/export 接口返回了数百条学生敏感信息。而 POST 请求依然收获不大。此时，可以对 student 这个关键词进行 Fuzz，尝试发现如 teacher 等其他角色的类似接口。

GET /student/export

手工替换参数进行测试，将 student 改为 teacher，顺利获取了系统全部教职工信息。表格中再次出现了工号字段，这为后续爆破进入教师个人后台提供了条件。

/teacher/export ------>老师列表
/student/export -------> 学生列表

发现并利用页码参数

仅有注册获得的 JWT 进行接口测试，只发现了部分信息泄露。除了利用泄露的工号进行爆破外，似乎没有更直接的路径进入管理员后台。但直觉和经验表明，这个站点应该存在更深层次的漏洞。重新分析Burp Suite记录的所有流量，经过细致排查，发现了一个关键点：部分接口请求中携带了页码参数 pageNum 和 pageSize。

这是用于分页查询的常见参数。在过往经验中，我曾利用页面功能在已有数据基础上获取更多数据。那么，是否可以主动在接口测试中模仿并添加这些参数呢？

---

尝试在接口后拼接 ?pageNum=1&pageSize=99 参数再次测试。结果令人振奋：信息泄露量远超第一次！这证实了该思路的可行性。其中，/plan/task/manager/list/export 接口泄露了超过3000条包含身份证号、手机号的敏感信息。

/plan/task/manager/list/export?pageNum=1&pageSize=99 # 泄露3k+二要素

此外，/online/card/manage/list 接口的返回数据显示了全国各地不同的职业院校列表，结合系统内的学生和老师信息，可以推断该系统的受众是医学院的实习学生。

/online/card/manage/list?pageNum=1&pageSize=99 # 校园列表

至此，攻击面大大拓宽：系统用户（学生、老师）的账号极大概率是手机号。随机选取泄露信息中的手机号作为账号测试登录，系统反馈“密码不正确”，这属于典型的用户名枚举漏洞。现在，我们掌握了大量真实用户的账号，其中必然存在使用弱口令的情况，通过密码喷洒攻击进入用户后台只是时间问题。

挖掘相对路径接口

除了发现页码参数，在逐行审查数据包时，还注意到了一个被常见插件“遗漏”的接口模式：/role/register。插件通常能很好地捕获以 / 开头的绝对路径，但对于 role/register 这种缺少开头斜杠的相对路径，则可能归类到“相对路径”模块，容易被忽略。

/role/register

将捕获的接口统一整理到文本中后，全局搜索 /role/register，发现它确实不在之前使用的插件检索结果里。那么这个接口从何而来？

回到浏览器开发者工具的“Network”面板全局搜索，发现这个接口的原始形态就是 role/register。正是因为缺少开头的 /，插件将其识别为相对路径并归类。实际上，插件也捕获到了这类接口，只是存放的位置不同。

role/register

查看插件的“相对路径”模块，果然存在一千多个此类接口。现在，我们手握低权限 JWT，再加上刚发现的页码参数技巧，对这些相对路径接口进行测试，很可能会有新的收获。即使没有手动发现这个细节，按照常规流程，在插件提取的接口测试完毕后，下一步也应是收集所有异步JS文件并通过脚本批量提取接口，届时同样会发现它们。

针对相对路径接口进行测试时，需要在路径前手动添加 /，然后携带 JWT 和页码参数进行请求。

GET  /**xxxxxxx**?pageNum=1&pageSize=99

测试结果揭示了系统内部更大量的信息泄露，包括内部资源、人员列表、医学课题研究文档等，危害显著。

在翻查这些泄露的接口数据时，发现了管理员账号 (m01)。采用经典的突破思路——弱口令测试，使用简单密码 abc123 成功登录管理员后台。

m01/abc123

总结

本次渗透测试过程步骤清晰，逻辑连贯，完整展示了一次从零开始突破登录框的实战思路。核心在于通过细致的信息收集（技术栈识别、接口捕获）、灵活的测试技巧（参数拼接、路由遍历）以及对业务逻辑的深度分析（从数据推断用户体系、发现鉴权缺陷），最终组合利用泄露信息（手机号、工号）进行精准的密码喷洒攻击，成功获取系统最高权限。

文章看似顺利，实则是将许多尝试与“踩坑”过程进行了提炼。安全测试的本质是耐心与思维的结合，希望这次分享能为大家提供一些有益的参考。

文章转自先知社区，原作者一天要喝八杯水，侵删。原文链接：https://forum.butian.net/share/4644