1、立项背景与产品问题
某 AI 工作空间类客户端存在大量本地接口与远端 API，其鉴权、额度校验、设备风控的实现方式既没有文档、也不对外开放。业务方在二次开发前必须先摸清三件事：哪些能力可以在本地可靠调用、哪些限制其实可以绕过、哪些防护是纸糊的。同时又要严格守住法律边界，不做任何越权取数。
2、行业场景与业务背景
这类需求常见于企业采购第三方 AI 产品后的集成评估、安全尽调、以及加固前的自我体检。甲方真正要的不是一份「存在漏洞」的清单，而是一张可执行的地图：每个接口能不能用、用了有什么风险、风险对应哪段代码、哪些结论还有待验证。
产出物是四个模块：
（1）接口分析：全量抓取应用运行时请求，按「可用 / 无用 / 待验证」三档打标，逐条记录 URL、方法、请求头、请求体、响应结构、动态参数来源；
（2）漏洞与风险分析：按危害分级列出可复现的问题，附复现步骤、成因定位到源码行；
（3）本地攻击面分析：梳理本地配置、缓存、日志、进程间通信、网关配置等可被本地改写的面；
（4）验证脚本：对短信验证码、额度校验等关键链路做频率与边界测试，全部用数据说话。
业务流程：导出全量 HAR → 按域名与业务模块分类 → 筛出承载核心能力的接口并定位其动态参数的生成位置 → 对混淆过的签名逻辑做 AST 批量还原 → 写脚本对关键链路做实测 → 汇总为报告并标注证据链。
1、整体架构与技术栈
采用「抓包 → 定位 → 还原 → 实测」四阶段流水线。抓包阶段用浏览器与客户端全量导出 HAR，用 Python 脚本做接口聚类与去重；定位阶段在开发者工具里对目标参数下条件断点，配合运行时插桩钩住加密与存储 API，把参数生成的真实调用栈挖出来；还原阶段对 Webpack 打包并混淆过的代码用 Babel 做 AST 层面的批量反混淆，把控制流平坦化和字符串数组还原成可读代码；实测阶段用 Python 写请求矩阵，针对验证码频控、额度校验、设备指纹做定向验证。
2、负责范围与量化结果
独立完成全部四个阶段。产出：接口分析台账 733 行约 2.3 万字；漏洞分析报告 428 行，梳理出 8 个风险项（高危 1、中危 4、低危 1、其余待验证）；本地攻击面分析 737 行约 1.6 万字。实测关键结论：同一手机号短信验证码有 60 秒冷却，但同一 IP 连续更换 20 个不同号码全部成功，说明频控只做了号码维度、没有 IP 维度；验证码连续错误 100 次无锁定；全程未见图形验证码介入。
3、难点与解决方案
难点一：动态参数在打包代码里被拆到多个模块，静态搜索搜不到赋值点。解决办法先用运行时插桩把最终值打出来，再反查调用栈，最后才去搜源码。
难点二：混淆后的代码手动读不动。解决办法是用 Babel 写一套 AST 变换，先还原字符串数组、再解控制流平坦化，批量处理而不是逐个函数改。
难点三：容易把「本地可改」误判成「服务端可绕」。早期把本地网关配置可强制覆盖当作高危，实测发现服务端有对应校验，降级为配置篡改类中危。
评论