2026-08-08 06:41:51 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 该论文系统性地揭示了小程序生态中基于OAuth的认证机制(OBA)存在的安全滥用问题。研究团队提出了业界首个动态分析框架MiniAuth，对微信和百度两大平台近4.7万个小程序进行实测，发现超过1800处认证滥用，涉及1600多个小程序。论文将滥用归纳为三类模式：凭证交换泄露、身份断言滥用和通道请求滥用。研究还披露了一个百度平台级的密码学设计缺陷。该工作获得了11个CNVD/CNNVD漏洞编号确认，为小程序安全领域提供了重要的系统性分析和可操作建议。 综合评分： 85 文章分类： 漏洞分析,安全研究,移动安全,WEB安全,渗透测试

cover_image

【论文分享】小程序，大问题：动态分析揭开小程序类 OAuth 认证滥用的安全黑洞

星图实验室星图实验室

奇安信技术研究院

2026年7月27日 18:00 北京

在小说阅读器读本章

去阅读

一、引言

如今，微信、百度这类”超级 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 服务器（提供支付、消息等系统能力）和开发者自建服务器（负责用户管理与业务数据）。

图 1微信小程序的双层架构

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 解密出手机号等敏感数据。

图 2微信小程序中的 OBA流程（其他平台流程类似），图中红色标注即为三类滥用发生的位置

这里最关键的一条信任边界是：session_key 是整套机制的”信任根”（cryptographic root of trust），只能存在于开发者后端。一旦开发者误解了小程序 OBA 工作流的信任边界，将敏感内容泄露到前端，攻击者就能脱离平台中介、独立解密甚至伪造平台加密数据，OBA的安全模型也就被彻底击穿。

三、问题的本质：为什么静态分析无法解决？

以往针对小程序安全的研究，大多聚焦于硬编码凭证、权限滥用等静态问题。但它们在检测 OBA 滥用时存在两个根本性局限：

· 无法应对混淆。 真实环境中大量小程序经过重度混淆，页面路由、事件处理、组件元数据被打乱，静态分析难以将 UI 元素映射到 OBA 逻辑。

· 看不见”运行时”行为。 这是最致命的一点,敏感参数（如 session_key）可能被注入到网络流量中，却在前端源码里完全不留痕迹。

这里我们用一个真实案例: BDZR 博物馆购票小程序（其真实名称已经脱敏处理）进行说明。这个小程序同时命中了两类滥用：

1. 在步骤 VI，开发者服务器把 session_key 连同 OpenID/UnionID 一起返回给了前端。攻击者在自己的设备上运行该小程序，通过 MITM 代理嗅探到 session_key，再结合 IV 解密出 encryptedData；随后把自己的手机号替换成受害者的，重新加密并回传。服务器端验证通过并放行，使得攻击者成功以受害者身份登录。

而在步骤 XI，这套精心设计的加密机制反被开发者亲手架空：OBA 流程本是为”安全验证用户身份、并获取手机号等敏感信息”而生，可开发者走完整套流程、解密拿到手机号后，却把它以明文回传、并直接当作用户的唯一身份标识。前面所有的加密验证由此瞬间形同虚设：攻击者根本无需触碰任何加密环节，只要在请求里把手机号替换成受害者的，就能冒名登录。

图 3BDZR博物馆小程序的滥用与攻击过程

值得强调的是，现有工作都无法有效检测到这类问题。如图 4 所示，前端代码里根本没有任何与 session_key 相关的逻辑，密钥只出现在运行时的网络流量中

图 4BDZR小程序 OBA流程的前端代码片段——其中完全没有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）：

图 5MiniAuth的整体工作流程：预过滤 →登录页定位 →动态分析

①预过滤器（Pre-Filter）。 关键洞察是：在小程序生态里，OBA 是访问敏感用户数据的唯一途径，而按监管要求，开发者使用相关 API 前必须公示隐私声明。因此 MiniAuth 通过 AppID 抓取隐私声明页并做模式匹配，快速筛出可能使用 OBA 的小程序，把海量语料收敛到可分析的子集。

②登录页定位器（Login Page Identifier）。 针对挑战 C1（如何在混淆小程序中自动定位 OBA 登录页）：

· 对未混淆小程序做跨渲染层/逻辑层的静态分析——定位 wx.login、getPhoneNumber 等 API，沿处理函数反向污点追踪，再借 bindtap、bindgetphonenumber 等事件属性锁定触发 OBA 的