JWT令牌泄露如何开启旁站渗透测试：信息收集、越权与漏洞利用全记录

漏洞挖掘

测试的第一步自然是访问目标网站，同时留意页面源码（“熊猫头”）中是否存在信息泄露。这次很凑巧，泄露的是一段 JWT (JSON Web Token)。

拿到 JWT 后，接下来就是尝试拼接各种接口和路径进行访问。然而，大多数尝试最终都只返回了 401 Unauthorized 状态。

走到这一步，常规思路可能是爆破登录框或者 Fuzz 寻找未授权接口。这些尝试都一无所获后，我们决定回头进行更深入的信息收集。通过对 IP 进行资产测绘，发现该目标还存在其他旁站系统。

访问旁站并测试登录功能时，发现虽然系统界面不同，但部分接口路径看起来非常相似。于是，我们尝试将先前泄露的 JWT 令牌放入旁站系统的请求头中进行测试。

第一个系统和第二个系统的接口路径对比：

测试过程

在登录框中随意输入账号密码，抓取登录请求的数据包。将数据包放入重放模块进行构造，关键步骤是在请求的 Header 中加上 token: {发现的JWT}。在众多接口中，/platAccount/list 引起了我的兴趣，通过 F12 开发者工具查找该接口的调用参数。

按照找到的参数进行拼接访问，但提示缺少必要参数。此时，只需将 POST 请求 Body 中的参数（pageNum、pageSize）移动到 URL 查询字符串中即可。修改后成功获取到用户列表数据，这证明这个 JWT 令牌在旁站系统是可用的。

此时我们已经获取到了账号相关信息，并且还发现了一个重置密码的接口 /platAccount/resetPwd。继续测试该接口，首先提示 “账号ID不能为空”。我们从刚才获取的用户信息中提取 platAccountId 字段填入，随后提示 “密码不能为空”。回想登录时使用的密码字段就是 password，补全后，重置密码操作成功。

接下来的目标自然是重置管理员（admin）的密码。操作成功后，使用新密码成功登录后台。

SQL注入

在后台其他功能点进行测试时，加入单引号后发现报错。仔细查看错误信息，发现是 Druid 连接池防火墙的报错。而 Druid 防火墙是可以通过报错函数进行注入的。这里使用的 payload 为 /0 or updatexml(1,concat(0x7e,user(),0x7e),1)=1，成功获取到数据库用户名，同理也可以获取数据库名。

XSS

由于该系统使用 Vue 框架，其内部存在一些默认的过滤机制。在 F12 查看页面元素时，看上去 XSS 代码已经写入了，但实际上已经被 Vue 转义处理了。

要绕过此类限制，通常需要寻找开发者误用 v-html 指令的地方，或者寻找富文本编辑器。编辑器通常是测试 XSS 最直接的地方，要么是上传 HTML 等文件，要么就是在编辑器内容中插入可执行的标签。

在编辑器的“内容”字段中插入 XSS payload <img src=1 onerror=alert(123)> 并提交。

成功触发 XSS 弹窗。

敏感信息泄露

现在很多网站通常不会直接接受文件存储在本地服务器，而是会放在云存储桶中。这虽然防止了一些直接的文件上传导致的代码执行漏洞，但如果权限配置不当，同样会在获取上传凭证时泄露相关的 Access Key、Secret Key 以及临时的 STS Token。在上传文件功能点，发现返回的数据包中包含了 AK/SK 等敏感信息，使用 OBS Browser+ 成功接管其五十多个存储桶。

由于现在是 admin 账户登录的，获取到的密钥权限可能较高。我们尝试将获取敏感信息接口请求中的 Token 替换回一开始泄露的那个主站 JWT，请求同样成功了。这意味着主站泄露的 JWT 在旁站拥有极高权限，这本身又是一个独立的漏洞点。

越权漏洞

在已经拿到后台权限的情况下，完全可以测试不同账号间的越权问题。直接使用后台功能重置一个普通用户的密码，然后用另一个浏览器登录该普通用户账号。

可以看到该用户的权限菜单很少，但这并不代表其功能权限真的被严格限制了。有些网站只对前端显示的菜单进行权限校验，而不会在后台对每个功能点接口做二次鉴权。通过 F12 找到该普通用户的 token 值，在 Burp Suite 中将之前 admin 的 token 替换成这个普通用户的 token。然后尝试访问之前的高危接口：获取 AKSK，成功；获取所有租户列表，同样成功。这证实了垂直越权漏洞的存在。

总结与反思

本次测试始于一个看似不起眼的 JWT 泄露，通过系统的信息收集，发现了同 IP 下的旁站。利用主站的 JWT 在旁站实现了越权登录，并进一步发现了重置密码、SQL 注入、存储型 XSS、敏感信息泄露以及垂直越权等多个漏洞。整个链条清晰地展示了：一个微小的信息泄露点，如何通过不安全的令牌共享机制和缺失的权限验证，演变为一次完整的系统渗透。

对于开发者而言，这起案例提醒我们：

1. JWT 等令牌绝不能硬编码或泄露在前端。
2. 不同系统间应使用独立的认证体系，或建立严格的令牌校验与权限边界。
3. 后台接口必须进行严格的、基于角色和功能的权限校验，不能仅依赖前端菜单隐藏。
4. 云服务凭证的发放应遵循最小权限原则，并妥善保管。

对于安全从业者来说，这充分体现了渗透测试中“由点及面”的思考方式。不放过任何一丝线索，将信息收集做深做透，往往就能打开新的突破口。如果你对这类实战案例的分析过程感兴趣，欢迎到云栈社区的【安全/渗透/逆向】板块，与更多同行交流探讨。