小程序安全实战：从敏感信息泄露到OpenID越权的任意用户登录漏洞分析

漏洞测试

与其总是从登录框入手进行测试，不如尝试注册后台功能或者从小程序挖掘入手，这样发现漏洞的概率可能会更高。一个常见的思路是，直接使用公开的大学名单，在微信小程序中搜索相关名称进行测试，或者广泛检索“小学”、“学院”、“大学”等关键词。

本次测试的目标就是通过这种方式找到的一个小程序。

点击进入小程序后，首先会看到登录界面。

登录方式分为三种。前两种（学生和教工）都需要跳转到统一的账号密码登录页面。

如果有兴趣，可以参照一些常见的登录框测试思维导图进行初步排查。

抓取登录请求的数据包查看，可以发现密码是经过加密传输的。常规思路是收集可能的学号，结合弱口令字典进行爆破测试。不过，这里我们选择第三条路径：使用“访客”身份进行登录。

访客登录成功后，主界面会显示两个预约入口。

这类预约功能通常是越权漏洞的高发区。我们尝试填写一个预约单。

然而提交失败，系统提示“被访人”必须真实存在。

于是我们尝试通过搜索引擎收集信息。使用 site:xx.edu.cn 校长 这类语法，可以找到一些可能的关键人物信息。

site:xx.edu.cn 校长

遗憾的是，将找到的名字一一尝试后，均无法通过验证。

接下来，测试一下表单中的图片上传点，看是否存在XSS等漏洞。

上传功能存在限制，且未返回文件路径，因此暂时放弃。

随后，在个人中心找到了“信息修改”功能。涉及用户信息修改的功能点往往容易出现问题。

点击进入信息修改页面。

点击修改按钮并抓包，分析请求与响应。

这个数据包看起来会存在信息泄露吗？这需要结合一些越权测试的思路来分析。

经过测试，确实存在信息泄露漏洞。关键在于请求体中的 queryFilter 参数。将 property 和 value 字段的值都修改为 1 后，服务器返回了超过7000条包含用户三要素（姓名、证件号、手机号）及 openid 的敏感信息。

在测试过程中，尝试了 null、*、置空、%、0 等多种值，只有设置为 1 时触发了数据泄露。

很多测试者到此可能就准备提交漏洞报告了。但请注意，响应数据中包含了重要的 openid 字段。openid 在小程序生态中常被用作身份标识，这为后续的渗透测试提供了新的可能性。

我们尝试寻找直接利用 openid 的接口。翻查历史请求记录，确实找到了相关接口，但其作用是使用 openid 查询对应的用户敏感信息。由于 openid 本身也是从上个漏洞泄露的，且不能有效遍历，这个接口显得比较鸡肋。

然而，之前学习过通过替换 openid 进行登录鉴权的案例。这属于“任意用户登录”的范畴。

现在，我们重新梳理一下“访客登录”的逻辑。点击访客登录时，拦截其响应包。

观察响应包，其返回的数据格式与我们之前泄露的 openid 格式非常相似。

于是，我们尝试将之前泄露的任意用户的 openid 替换到当前访客登录流程的响应包中。

放行这个被篡改的响应包，后续请求也一并放行。

最终，我们成功登录了他人的账号。至此，漏洞的危害从敏感信息泄露升级为任意用户登录，潜在影响范围覆盖了泄露的7000多个账号。

为了证明危害，我们尝试登录了其中两个账号。

后续通过安全分析工具还发现了其他潜在风险点，例如SQL注入。

这个案例展示了如何将一个看似“只能”泄露信息的中危漏洞，通过深入分析身份鉴权机制（openid），串联升级为可造成任意用户登录的高危漏洞。对于开发者而言，不仅需要对敏感信息查询做严格的权限控制，更要确保核心的身份凭证（如openid）在生成、传递和验证的每一个环节都是安全且不可预测的。欢迎在云栈社区与更多技术同仁交流此类安全攻防心得。