一、引言
如今，微信、百度这类”超级 App”里的小程序，已经渗透到金融、医疗、政务、出行等生活的方方面面。 为了在无需跳出超级 App 的前提下识别用户身份、获取手机号等敏感信息，各小程序平台都提供了一套基于OAuth 2.0实现的认证机制（后文称之为 OBA，OAuth-Based Authentication）。它让小程序可以借助平台专有 API 完成登录与授权。
然而，与流程标准化、文档严谨、集中审查的传统 Web OAuth 不同，小程序 OBA 深度绑定在超级 App 的封闭生态里，实现细节高度依赖平台私有 API，复杂度陡增。于是，成千上万的第三方开发者在集成这套流程时频频出错。而任何一处对信任边界的误解，都可能被攻击者利用，进而冒充受害者登录、伪造身份、窃取隐私。 为系统性地揭示并量化这一问题，奇安信技术研究院星图实验室与山东大学、香港中文大学、上海交通大学、清华大学以及加拿大西蒙菲莎大学，在 ACM CCS 2026 上发表了论文 《Mini-Programs, Mega-Problems: Unveiling OAuth-based Authentication Misuses in Mini-Programs via Dynamic Analysis》。这也是星图实验室继 ACM CCS 2024之后，在小程序安全领域斩获的又一项高水平学术成果。
本工作实现了业界首个面向小程序 OBA 滥用的大规模动态分析框架 MiniAuth，对微信与百度两大平台共计 46,994 个小程序进行了实测，发现 1,834 处认证滥用、涉及 1,688 个小程序，并披露了一个可在 20 分钟、约 2.74 美元成本内被暴力破解的平台级密码学设计缺陷。相关发现已获得 11 个 CNVD/CNNVD 漏洞编号确认。
二、背景：小程序里的 OBA
小程序的双层架构。 小程序是运行在超级 App 内的 WebView 应用，前端分为两层：负责界面与静态资源的渲染层（Render Layer，WeChat 用 WXML、Baidu 用 SWAN），以及负责逻辑处理和与后端通信的逻辑层（Logic Layer，JavaScript）；后端则包括超级 App 服务器（提供支付、消息等系统能力）和开发者自建服务器（负责用户管理与业务数据）。
OBA 认证与取数流程。 与拥有 redirect_uri、state、签名令牌等浏览器可见状态的标准 OAuth 2.0 不同，小程序 OBA 运行在”用户已登录超级 App”的沙箱内（如：用户必须登录微信才可以使用小程序），全流程由平台私有 API 中转。其核心步骤如下（见图 2）：
- 步骤 I–II： 用户打开小程序，前端调用 wx.login（百度对应 swan.login）向超级 App 申请一个短时、一次性的登录 code（以微信为例，有效期 5 分钟），并发送给开发者服务器；
- 步骤 III–IV： 开发者服务器携带应用凭证，把 code 转发给超级 App 后端 API（如 code2Session），换回用户标识 OpenID/UnionID 和一把会话密钥 session_key；
- 步骤 V–VI： 服务器把用户标识返回前端，而 session_key 必须严格留在服务器端；
- 步骤 VII–IX： 用户点击授权后，小程序调用 getPhoneNumber 拿到加密载荷 encryptedData + 初始化向量 IV，转交后端，后端用 session_key 通过 AES-CBC + PKCS7 解密出手机号等敏感数据。
这里最关键的一条信任边界是：session_key 是整套机制的”信任根”（cryptographic root of trust），只能存在于开发者后端。一旦开发者误解了小程序 OBA 工作流的信任边界，将敏感内容泄露到前端，攻击者就能脱离平台中介、独立解密甚至伪造平台加密数据，OBA的安全模型也就被彻底击穿。
三、问题的本质：为什么静态分析无法解决？
以往针对小程序安全的研究，大多聚焦于硬编码凭证、权限滥用等静态问题。但它们在检测 OBA 滥用时存在两个根本性局限：
- 无法应对混淆。 真实环境中大量小程序经过重度混淆，页面路由、事件处理、组件元数据被打乱，静态分析难以将 UI 元素映射到 OBA 逻辑。
- 看不见”运行时”行为。 这是最致命的一点,敏感参数（如 session_key）可能被注入到网络流量中，却在前端源码里完全不留痕迹。
这里我们用一个真实案例: BDZR 博物馆购票小程序（奇真实名称已经脱敏处理）进行说明。这个小程序同时命中了两类滥用：
- 在步骤 VI，开发者服务器把 session_key 连同 OpenID/UnionID 一起返回给了前端。攻击者在自己的设备上运行该小程序，通过 MITM 代理嗅探到 session_key，再结合 IV 解密出 encryptedData；随后把自己的手机号替换成受害者的，重新加密并回传。服务器端验证通过并放行，使得攻击者成功以受害者身份登录。
- 而在步骤 XI，这套精心设计的加密机制反被开发者亲手架空：OBA 流程本是为”安全验证用户身份、并获取手机号等敏感信息”而生，可开发者走完整套流程、解密拿到手机号后，却把它以明文回传、并直接当作用户的唯一身份标识。前面所有的加密验证由此瞬间形同虚设：攻击者根本无需触碰任何加密环节，只要在请求里把手机号替换成受害者的，就能冒名登录。
值得强调的是，现有工作都无法有效检测到这类问题。如图 4 所示，前端代码里根本没有任何与 session_key 相关的逻辑，密钥只出现在运行时的网络流量中。
四、 OBA 滥用模式分类
按照滥用发生在 OBA 生命周期的哪个阶段，本工作将运行时滥用系统性地归纳为三类：
M1：授权前的凭证交换泄露（Credential Exchange Before Authorization）。 后端本应是唯一能构造/解密身份载荷的实体，却把 session_key 等认证参数暴露给了不可信的前端。按泄露时机又细分为：
- M1a——身份伪造： 密钥在认证请求发出之前（如步骤 VI）就暴露，攻击者可在本地把任意受害者的标识封装成合法加密载荷。我们将其定义为”一种由攻击者、而非平台来决定用户身份的动态认证绕过”。
- M1b——认证后数据伪造： 密钥在登录之后才暴露，虽无法伪造当次登录请求，但凭证隔离已被打破，攻击者可解密、篡改、再加密后续平台载荷（例如篡改 getUserInfo 的 encryptedData 伪造用户属性）。
M2：授权中的身份断言滥用（Identity Assertion During Authorization）。 UnionID 本是”同一开发者旗下多应用间的用户映射标识”，只应用于数据关联；但许多小程序把它当成独立的认证凭证。由于 UnionID 是静态的，攻击者可以从同一厂商下一个安全性更弱的应用里拿到它，直接提交给服务器即可冒名登录——相当于把一个公开标识符变成了永久密钥。
M3：授权后的通道请求滥用（Channel Request After Authorization）。 开发者用 OBA 取到手机号等敏感数据后，却在后续业务请求中以明文传输、缺乏任何完整性保护。攻击者只需在传输途中把明文标识改成受害者的，即可绕过认证、冒充任意用户。
| 类型 | 名称 | 发生阶段 | 攻击者获得的能力 |
| M1a | 凭证交换泄露 · 身份伪造 | 凭证交换（授权前） | 用泄露的 session_key+IV 伪造任意受害者身份，直接登录 |
| M1b | 凭证交换泄露 · 认证后数据伪造 | 凭证交换（授权后） | 解密/篡改/重加密后续平台载荷，绕过后续鉴权 |
| M2 | 身份断言滥用 | 授权中 | 复用静态 UnionID 跨应用冒名登录 |
| M3 | 通道请求滥用 | 授权后 | 篡改传输中的明文标识（如手机号）冒充用户 |
五、MiniAuth 的设计
面对上述挑战，本工作设计并实现了 MiniAuth：首个面向小程序、能自动执行并分析 OBA 流程的动态分析框架，同时支持微信和百度两大平台。它由三个核心组件串联而成（见图 5）：
① 预过滤器（Pre-Filter）。 关键洞察是：在小程序生态里，OBA 是访问敏感用户数据的唯一途径，而按监管要求，开发者使用相关 API 前必须公示隐私声明。因此 MiniAuth 通过 AppID 抓取隐私声明页并做模式匹配，快速筛出可能使用 OBA 的小程序，把海量语料收敛到可分析的子集。
② 登录页定位器（Login Page Identifier）。 针对挑战 C1（如何在混淆小程序中自动定位 OBA 登录页）：
- 对未混淆小程序做跨渲染层/逻辑层的静态分析——定位 wx.login、getPhoneNumber 等 API，沿处理函数反向污点追踪，再借 bindtap、bindgetphonenumber 等事件属性锁定触发 OBA 的 <button> 组件；
- 对混淆小程序，则利用平台强制要求、且不被混淆的路由配置文件（如 app.json）作为”地图”，配合 OCR 关键词识别 + 深度优先遍历，并在必要时回溯已访问页面（有些可点元素只在特定路径后才出现），直到触发那个平台统一样式的授权弹窗。
③ 动态分析器（Dynamic Analyzer）。 针对挑战 C2（如何在封闭沙箱里自动化交互）：小程序无法像普通 App 那样通过标准接口直接操控。MiniAuth 无需改动源码或依赖平台 SDK，而是借用了超级 App 的启动机制——在微信上用 Xposed 插件注入带有 AppID 和页面 Path 的 Intent，在百度/支付宝/抖音上则构造深链接 URI——即可从外部直接拉起并操控任意小程序。它能自动处理三类交互场景：平台授权弹窗（模拟点击”Agree”）、开发者隐私协议（自动勾选并确认）、以及 OBA 流程本身（见图 6）。
随后，OBA 流量监控器对全流量做基于上下文的模板检测：同时利用参数值的结构特征（如 session_key 的固定长度、base64 编码）与其在请求/响应中的结构角色进行识别。即便开发者把 session_key 改名为 skey、sk 也能识别。一旦命中即判定为对应滥用类型；对 M1a，MiniAuth 还会直接用截获的 session_key+IV 尝试解密 encryptedData，解密成功即证明身份伪造确实可行。
六、大规模测量结果
MiniAuth在 44,273 个微信 + 2,721 个百度小程序（总计约 130 GB）上进行了评估，得益于小程序的热更新机制和MinuAuth的动态分析设计，我们 分析的始终是平台上最新版本的小程序，端到端平均约 2 分钟/个。
OBA 滥用极为普遍。 微信中 22.9%（10,159/44,273）、百度中 23.6%（641/2,721）的小程序使用了 OBA；而在使用 OBA 的小程序里：
- 微信 13.8%（1,397 个）、百度高达 45.4%（291 个）存在至少一类 OBA 滥用；
- 其中微信 583 个、百度 36 个（共 619 个）同时存在多类滥用；
- 合计 1,834 处滥用，其中 M1 最为常见（微信 1,201、百度 51）。
值得注意的是，微信 OBA 小程序中有 47.4% 经过重度混淆、百度约 50.9%——这直接凸显了静态分析的天花板，也印证了动态方案的必要性。检测精度方面：抽样复核显示微信仅 3% 的误报（均为 M3）、百度零误报，且在成功分析的小程序中未观察到漏报。
真实影响规模：小程序运行在超级 App 的封闭生态里，通过官方应用市场分发，外界几乎拿不到它们真实的用户规模数据。为了评估这些存在问题的小程序究竟波及多少用户，我们对爬取到的后端服务域名采集了被动 DNS（pDNS）数据来估算访问量。需要强调的是，这个数字是一个保守下界，而非真实访问量：一方面，pDNS 只能观测到全球一部分递归解析器的流量，视角本就不完整；另一方面，DNS 缓存会在 TTL 内”吞掉”大量重复查询，很多真实访问根本不会产生新的可观测解析记录。也就是说，真实规模只会比测到的更高。
即便按这个下界来看，受影响的用户体量也已经相当可观——部分小程序月访问量超过 2000 万，一个博物馆类小程序超过 1100 万，一个银行类小程序超过 700 万。 这些数字，正是我们所披露问题在真实世界中可能波及的用户规模下限。检测覆盖范围对比。 与现有 SOTA 工具相比，静态方案因无法处理混淆，仅能分析微信数据集的 6.2%（2,748/44,273）、百度 0 个，且对 M2/M3 的检出为 0；MiniAuth 则完整覆盖 M1a/M1b/M2/M3 全部四类。
“意外之喜”的平台级缺陷。 在测量过程中，我们还发现了百度 OBA API 的一处密码学设计缺陷（特别感谢吴祥凡同学的帮助！）：百度使用 128 位 session_key（AES-CBC + PKCS7），但其 IV 并非随机生成，而是复用了 session_key 的前 42 位。由于 encryptedData 与 IV 都会经网络传输，攻击者可发起离线暴力破解恢复出完整 session_key：即便开发者严格遵守了所有最佳实践也无法幸免。在使用开源工具 aes-brute-force（Intel AES-NI 加速）在一台 GPU 云实例上实测：一次成功破解仅需约 20 分钟、成本约 2.74 美元，攻击”既可行又划算”。该问题已上报百度并获确认、正在修复；微信存在类似缺陷（IV 同样复用部分密钥），但因其 256 位密钥暂无法在有效期内破解，已上报腾讯并获修复。
七、真实案例分析
案例一：ADJ代驾小程序。 ADJ是国内代驾服务市场排名前三的小程序，拥有超过 10 万名注册司机，在百度与微信双端上线。论文分析其百度版代码发现一条危险链路：getPhoneNumber → getLoginCode 取 code → getBdOpenid（响应中泄露 session_key）→ 把 encryptedData/IV/session_key 一起交给 getBdPhone 解密手机号 → 交给 userLogin 完成登录。这同时构成 M1a 与 M3 两类滥用。
攻击者只要知道受害者手机号，就能通过 M1a 伪造加密载荷、或通过 M3 直接替换明文手机号，冒充受害者登录、查看行程记录、甚至以其名义下单，对隐私与资金安全构成严重威胁。更值得警惕的是：ADJ的微信版经过重度混淆，现有静态工具无从下手，但 MiniAuth 依然触发出了完全相同的漏洞；对比两端流量可见，请求体与暴露的敏感字段几乎完全一致（图 10），说明开发者跨平台复用业务逻辑，也系统性地复制了安全缺陷。
案例二：SYDEY 医院。 SYDEY医院小程序提供预约挂号、检验报告、医保支付的医疗小程序，微信版通过第三方插件对敏感交互做了传输层加密（安全），百度版却以明文传输 session_key（M1）。由于两端共用同一后端，攻击者只需攻击更脆弱的百度版，就能伪造凭证、访问统一后端——即使微信版看起来固若金汤，整个系统依然沦陷。
跨平台风险。 论文对 43 个微信/百度双端上线的小程序追查发现：它们全部也在企业微信上线，17 个在支付宝、8 个在抖音；而其中 43/43（企业微信）、42/43（百度）、17/17（支付宝）、8/8（抖音）都复现了与微信版相同的问题。一句话总结：一个小程序只要在某个平台上不安全，它在其他平台上的孪生版本极可能存在同样的弱点。甚至有开发者为绕过微信内置的 session_key 静态检查，特意把参数改名为 sk。
八、根因与讨论
根因。 论文将 OBA 滥用的成因归纳为：
- 前后端职责边界不清：开发者误解了哪些环节必须留在服务器端，把 session_key 这样的后端凭证暴露给了不可信前端（导致 M1）；
- 后端缺乏真实性与新鲜性校验：陷入”解密即认证（decryption-equals-authentication）“的谬误，把解密数据或静态标识直接当作身份证明，而未将其绑定到一次新鲜的 OBA 交换（导致 M2/M3）；
- 平台抽象易错、强制力有限：紧凑的 API 设计模糊了三方信任边界，而平台侧当前主要依赖静态源码扫描，无法可靠地在运行时流量中发现滥用，尤其当开发者对敏感字段改名时。
负责任披露与后续跟踪。 团队全程仅在自有账号、设备与小程序上验证漏洞，测试流量限速 20 请求/分钟、仅在封闭实验网络内回放。研究者先向百度、腾讯上报了平台级密码学缺陷与 M1–M3 滥用（两家均确认平台缺陷、认可滥用模式，但认为第三方实现不在其直接响应范围内）；随后上报 CNVD、CNNVD、CNCERT/CC 等国家级协调机构； 90 天后，团队对 11 个已确认案例（覆盖银行、医疗、智能锁、加油支付等高影响服务）进行了回访：部分小程序已部署有效修复（加密通信、从载荷中移除 session_key、重构登录流程、增加令牌/签名/二次认证等），也有部分仍未修复、被下架或仅做了表面修补。
九、总结
当标准化统一封装的便利，遇上第三方开发者、封闭生态与对信任边界的误解，小程序里那套看似平常的 身份 认证，就可能沦为攻击者冒名顶替的入口。MiniAuth 首次证明：小程序 OBA 滥用中真正致命的一类漏洞，只在运行时的网络流量里现身，静态分析对其无能为力。通过预过滤、OCR 辅助的动态定位与自动化交互、以及基于上下文的流量模板检测，MiniAuth 在近 5 万个小程序中揪出了 1,834 处滥用，并牵出一个平台级密码学缺陷。
我们认为：小程序 OBA 的安全，是平台与开发者的共同责任：平台需要重新审视 API 的抽象与边界、把运行时审计纳入发布前的检查；开发者则必须超越”表面合规”，落实到真正保护认证真实性与服务端密钥机密性。尤其在 AI 驱动漏洞挖掘的当下，OBA 这类”逻辑漏洞”正变得更易被规模化发现、批量利用。我们的跨平台测量已经显示，同一套缺陷会被成批复制到微信、百度、支付宝、抖音等多端。对于这个仍在扩张、正被 AI 加速放大、却长期被忽视的攻击面，需要引起整个小程序生态的重视。
论文链接：https://arxiv.org/abs/2607.08232