AI赋能小程序渗透测试

一个以「AI推理框架」为核心、而非「固化扫描脚本」的小程序自动化渗透测试 Skill 是如何设计的？本文从架构哲学、技术落地到安全合规，全面拆解 WxApp-Mastermind 的开发思路。（工具下载链接：https://wwbvs.lanzouq.com/inr8A3sduvbc）

一、为什么做这个 Skill？

微信小程序的安全生态与 Web 安全有着本质区别：

• 源码可反编译
  ：.wxapkg 包可以被 KillWxapkg 等工具反编译，这给了白盒审计天然的条件；
• 分包懒加载
  ：小程序的分包往往在用户跳转到特定页面时才触发下载，首次反编译可能漏掉大量攻击面；
• 鉴权机制多样
  ：微信登录态（openid / session_key / code）和自建认证（JWT / Token）混合，容易产生鉴权盲区；
• 上下游关系复杂
  ：云函数、跨小程序跳转、插件供应链、第三方平台等构成了独特的攻击面。

传统自动化漏洞扫描器在 Web 领域成熟，但在小程序领域几乎没有能打的。原因很简单：小程序的反编译+审计+发包链条太长，固化的扫描流程既无法覆盖源码审计的推理深度，也无法灵活应对不同小程序的架构差异。

WxApp-Mastermind 的定位很明确：搭骨架，不写死逻辑。AI 负责发散推理，人负责策略决策。

二、核心设计哲学：从「扫描器」到「推理框架」

2.1 一场自觉的架构选择

市面上常见的安全工具设计思路是：

输入目标 → 固定流程A → 固定流程B → 固定流程C → 输出结果

这个模式的优点是确定性高，缺点也很明显——每一步逻辑都是静态的。对于变化多端的小程序架构，这种「死逻辑」很快就会撞墙：这个小程序是纯云函数架构怎么办？那个小程序的服务端做了鉴权但源码里硬编码了 admin JWT 怎么利用？返回的数据怎么联动到下一个请求的参数？

WxApp-Mastermind v1.2 的选择是：

输入目标 → AI 理解源码特征 → 自主推理攻击面 → 决策下一步方向 → 人对齐策略 → 循环

这不是一个扫描器，而是一个轻量级测试框架 + 参考知识库入口。它提供：

• KillWxapkg 反编译 + 分包补全能力（核心武器）
• 11维源码审计方法论 + 45条凭据发现规则
• 值池联动注入引擎（shared/linkage.py）
• 6阶段自动化发包脚本（scripts/api_tester.py）
• 30+ 漏洞决策树参考（references/decision-trees/）

它不规定第一步该发哪个请求、第二步该改哪个参数。AI 根据反编译源码的实际特征，自主推理该测什么、怎么测。

2.2 四条核心原则

整个框架被压缩到仅四条必须遵守的铁律：

1. 白盒源码审计 + 黑盒发包验证
    → 反编译是攻击面收集的根基
2. 安全分层 — 先无凭证再有凭证
    → 干完不需要凭证的事再问用户要 Cookie
3. 伤害证明 — FOUND ≠ CONFIRMED
    → 没有证明危害的发现不是漏洞
4. 中文输出 + SRC 合规
    → ≤5条越权数据证明，禁止破坏性操作

这四条是骨架。在骨架上，AI 可以自由发挥。

三、技术架构全景：四阶段联动循环

整个工作流被组织成一个闭环——值池联动循环（The WxApp Linkage Loop）：

① KillWxapkg 反编译（主包 + 已有分包）
     ↓
② 页面遍历 → 触发懒加载分包 → 补反编译 → 循环直到无新分包
     ↓
③ wx_extract.py + AI 源码审计(11维)
     → endpoints.json / jump_targets.json / secrets.json
     ↓
④ 未授权发包 → ResponseMiner 响应挖掘 → _leaked_values.json
     ↓
⑤ ★ PairingEngine 联动注入：A返回的值 → B请求的参数
     openid → userId → orderId → 更多数据
     ↓
⑥ 定向渗透（三步自检 → 验证高危攻击面）
     ↓
Triage（FOUND ≠ CONFIRMED）→ 攻击链合并 → 中文 .md 报告

这个环的精妙之处在于：第⑤步的值池联动注入。它不是盲目的全量fuzz，而是让每一个成功响应的数据都成为下一轮请求的「弹药」。从接口A拿到的 openid，被注入到接口B的 userId 参数，返回的 orderId 再被注入到接口C——数据驱动的攻击面逐渐展开。

四、核心创新：值池联动注入引擎

这是 WxApp-Mastermind 最具特色的设计。文件位于 shared/linkage.py，包含四个核心组件：

4.1 ResponseMiner — 响应挖掘器

从每个 API 的 JSON 响应中递归提取字段名和字段值，自动识别并分类：

自动避开空值、布尔值和过短字符串。支持 JSONP 和非标准 JSON 格式的容错提取。

4.2 PairingEngine — 联动配对引擎

这是值池联动的核心调度器。它的工作逻辑是：

1. 遍历所有端点，对每个端点的每个参数；
2. 在值池中查找同名字段的值（精确匹配 + 语义匹配）；
3. 排除来源端点的自注入（A接口返回的值不回注到A接口）；
4. 按优先级排序（CRITICAL > HIGH > MEDIUM > LOW）；
5. 生成测试矩阵：(端点, 参数, 值池中的值) 三元组。

典型的联动链：

openid → /api/user/info → userId → /api/order/list → orderId → /api/payment/info

每一步的响应都可能挖掘出下一步的参数值。这就是「数据驱动的攻击面展开」。

4.3 SaturationDetector — 饱和度检测器

联动不是无限的。引擎内置了三个停止条件：

• 参数饱和度
  ：同类参数已测试超过 5 个不同值；
• 增长饱和
  ：连续 3 轮无 HIGH 或 CRITICAL 级别的新增；
• 时间边界
  ：30分钟上限。

这三个条件保证了测试的效率——拿到新 Token 或新分包后，可以重启联动循环。

4.4 ResponseComparator — 响应语义对比

区别于简单的响应大小对比，它比较的是语义差异：HTTP 状态码差异、JSON key 差异、敏感字段值变化、错误信息泄露。这让客户端字段篡改测试（如 clientType: miniapp → admin）的判断不再依赖人工肉眼比对。

五、反编译管线：从 .wxapkg 到完整攻击面

5.1 KillWxapkg 集成

WxApp-Mastermind 内建了对 KillWxapkg 的封装调用，支持：

• 主包 + 分包反编译
  ：自动识别 __APP__.wxapkg 与 _packageX_.wxapkg 的命名规则；
• 敏感信息扫描
  ：-sensitive 参数触发 45 条规则扫描，产出 sensitive_data.json，涵盖了云 AK/SK、JWT、私钥、Webhook URL、GitHub Token、微信凭据等；
• 代码美化
  ：-pretty 参数对反编译产物做美化处理，便于后续审计。

5.2 分包补全循环（v1.1 核心能力）

这是针对小程序架构特点设计的独有能力。小程序的分包是懒加载的——不访问对应页面，分包文件就不会被下载到本地缓存。因此仅凭首次反编译拿到的主包和已有分包，攻击面是不完整的。

WxApp-Mastermind 的解法是：

1. 从 paths.json 获取所有页面路径；
2. 通过 Playwright 自动化（或 MCP wechat_navigate）遍历每一个页面；
3. 每次跳转触发懒加载，微信自动下载新的 .wxapkg 文件；
4. 检测到新分包后，自动执行「补反编译」；
5. 新分包解出的页面路径可能包含新的子页面，因此回到步骤 1 继续循环；
6. 最多 5 轮，直到无新分包出现。

这个设计确保了攻击面的完整性——不因为分包懒加载而遗漏任何一个潜在的接口。

5.3 wx_extract.py 提取引擎

反编译完成后，wx_extract.py 使用 brace-matching 算法从 app-config.json 和 app-service.js 中提取：

• endpoints.json
  ：完整 API 端点（含 method / params / auth / content_type / 来源分包 / 源码行号）
• paths.json
  ：全部页面路径
• jump_targets.json
  ：wx.navigateToMiniProgram 跨小程序跳转目标（含 appId / path / extraData）

六、11维源码审计方法论

AI 在审计阶段会加载 references/wx-source-audit.md（约 23KB），对反编译源码执行 11 个维度的系统审查：

凭据三问：发现任何凭据必须回答——凭据解锁什么新能力？签名密钥能伪造吗？云 AK 能列资源吗？三个问题全部无法回答 → 该凭据不可利用 → 归档 INFO。

七、安全合规：SRC 标准的内化

7.1 破坏性操作边界

DELETE/PUT/PATCH 接口被标记为 DESTRUCTIVE_ENDPOINT，系统自动跳过实际执行。

7.2 数据获取边界

• IDOR/越权测试：严格控制 ≤5 条真实数据作为漏洞证明；
• 禁止 SQLmap 等自动化攻击工具；
• XSS 测试：用 <s>XSS</s> 预检，console.log('xss') 验证，不用 alert() 弹窗；
• 声明规范：「已控制数据获取量 ≤5条」而非「未访问真实用户数据」。

7.3 凭证门（Credential Gate）

当超过 80% 的 API 需要认证而当前无凭据时，框架会向用户一次性说明所需凭据类型，并提供：

• 无凭证也可测试的公开端点列表；
• 需认证端点写入附录 A（待测项），不丢弃。

用户拒绝提供凭据后，不再反复追问。这个设计避免了传统自动化工具「卡住不动」的窘境。

八、三 Agent 架构：从侦察到报告的全链路

WxApp-Mastermind 内部拆分为三个独立 Agent，各司其职：

wxapp_recon（侦察 Agent）

• Phase 0: appid 检测 + 微信缓存扫描 + 环境自检
• Phase 1: KillWxapkg 反编译 + 分包补全循环 + 11维源码审计
• 产出：endpoints.json / paths.json / jump_targets.json / secrets.json / 初始值池

wxapp_fuzz（Fuzz Agent）

• Phase 2: 无授权全接口发包 + 客户端字段篡改 + 版本降级 + 响应挖掘 + 值池联动循环
• 6阶段自动化：未授权 → SQLi/XSS → IDOR → JWT → Header 注入
• 产出：_leaked_values.json（持续增长）/ vulnerabilities.json

wxapp_exploit（利用 & 报告 Agent）

• Phase 3: 登录态深度测试（IDOR / 泛查询 / 垂直越权 / JWT / 支付逻辑 / 跨端复用）
• Phase 4: Triage Gate 判定 → 攻击链合并 → 中文报告生成
• 产出：confirmed.json / pending.json / 最终 .md 报告

九、上下文预算管理：防卡死机制

一个容易被忽视但极为重要的设计：上下文预算控制。在与 AI 的交互中，长文本的积累会导致推理质量下降甚至幻觉。

WxApp-Mastermind 规定：

• 禁止同时加载超过 3 个参考文件
  （不含本 SKILL.md）；
• 禁止加载完整的 decision-trees.md
  （99KB，必须按需选 1-2 个）；
• 每个参考文件用完即弃：审计完后立即丢弃审计规则文件，报告时只加载骨架模板（3KB），补充细节时临时加载对应决策树；
• 检测到反复加载同一文件循环 → 立即停止，输出当前已完成发现。

这个设计纯粹是从实战中「撞出来的痛」——99KB 的决策树文档一股脑塞进上下文，AI 就会迷失在细节里。

十、脚本工具箱速览