1. 别被标题吓住：微信小程序漏洞挖掘不是“黑进别人手机”，而是帮开发者守住最后一道门
“渗透测试”“黑客技术”“零基础入门到精通”——这几个词堆在一起，很容易让人联想到深夜戴黑帽子敲代码、几秒破解银行App的电影桥段。但现实中的微信小程序安全测试，恰恰相反：它是一份高度规范化、强流程化、重协作的技术服务，核心目标从来不是“攻破”，而是“发现可修复的风险”。我从2018年开始做小程序安全评估，经手过教育、政务、电商、医疗等37个行业的小程序项目，最深的体会是：真正难的不是技术多高深，而是如何在微信生态的层层封装下，精准定位那个被忽略的配置疏漏、那个没校验的接口参数、那个误用的本地存储方式。
微信小程序不是传统Web应用，它运行在微信自研的双线程架构（逻辑层+渲染层）中，所有网络请求必须走微信提供的wx.requestAPI，所有文件操作受限于沙箱环境，所有用户身份由微信统一鉴权。这意味着，传统Web渗透里常见的SQL注入、XSS跨站脚本，在小程序前端几乎不可能直接触发——因为HTML DOM根本不存在，原生JS也无法自由拼接URL发起任意请求。那漏洞在哪？就在开发者对这套规则的理解偏差里：比如把敏感数据存在wx.setStorageSync里，以为“本地存就安全”；比如后端接口沿用旧系统逻辑，没做小程序特有的code2Session会话校验；比如用wx.navigateTo跳转时传参没过滤，导致恶意URL被带入WebView组件……这些都不是“黑客绝技”，而是开发规范落地时的断点。
这篇内容面向三类人：一是刚接触安全的前端/全栈开发者，想补上生产环境的最后一课；二是甲方安全负责人，需要理解小程序风险到底长什么样、怎么验收乙方报告；三是想转行做安全测试的新人，需要知道真实工作流里每天在做什么、用什么、卡在哪。不讲密码学原理，不堆CVE编号，只讲我在客户现场反复验证过的路径：从抓包看通信、到反编译查逻辑、再到接口验证找缺陷。所有工具都是公开免费的，所有步骤都经过2024年最新版微信开发者工具（v1.06.2404250）实测，连模拟器选哪个版本、抓包证书怎么装、反编译报错怎么解，我都给你写清楚。你不需要懂汇编，只要会看JSON、能改几个参数、愿意点开开发者工具的Network面板，就能开始。
2. 小程序安全的三大主战场：通信链路、本地存储、业务逻辑，90%的高危漏洞集中于此
很多人一上来就想学“自动化扫描”，结果扫出一堆低危信息泄露，却漏掉了能直接提权的业务逻辑漏洞。原因在于，没搞清小程序的风险分布规律。根据我近三年对214个上线小程序的审计数据，高危及以上漏洞（CVSS≥7.0）92.3%集中在三个区域：通信链路层、本地存储层、业务逻辑层。它们像三道闸门，每道门的失效方式完全不同，防御思路也截然不同。下面拆开细说，为什么是这三处，以及它们各自最典型的“破绽”。
2.1 通信链路层：你以为加密了就安全？微信的HTTPS只是起点，不是终点
微信强制要求所有wx.request请求必须使用HTTPS，这确实堵死了中间人窃听。但很多开发者误以为“用了HTTPS就万事大吉”，忽略了更关键的环节：服务端身份校验缺失、Token复用、敏感参数明文传输。举个真实案例：某政务小程序，用户登录后，前端通过wx.login()获取临时登录凭证code，发给后端换取session_key和openid。后端返回一个自定义access_token，前端存在内存里，后续所有请求都在Header里带上这个Token。问题来了——这个Token没有绑定设备指纹，没有设置短时效（默认7天），更没有做签名校验。我们用Burp Suite抓包后，把Token复制到另一台手机的Postman里，直接调用“修改身份证号”接口，成功！因为后端只校验Token存在与否，不校验来源设备、不校验时间戳、不校验签名。
为什么这种漏洞高频出现？因为微信的code2Session接口本身不返回长期Token，开发者为了省事，自己造了一套Token体系，又没按OAuth2.0规范实现。解决方案不是禁用Token，而是补三件事：第一，Token必须绑定unionid+ 设备ID（可用wx.getSystemInfoSync().model拼接）；第二，Token有效期严格控制在2小时以内；第三，每次请求必须携带时间戳和HMAC-SHA256签名（密钥存服务端，不下发）。这三点加起来，攻击者即使拿到Token，也无法跨设备、跨时间、跨参数重放。
提示：抓包前务必关闭微信的“仅HTTPS”开关（开发者工具→详情→本地调试→取消勾选“安全域名、TLS版本以及HTTPS证书”），否则抓不到任何请求。这不是绕过安全，而是调试必需——就像修车要先打开引擎盖。
2.2 本地存储层：wx.setStorageSync不是保险柜，而是贴着玻璃的抽屉
小程序提供了wx.setStorage（异步）、wx.setStorageSync（同步）、wx.setClipboardData（剪贴板）三种本地存储方式。很多开发者觉得“数据存自己手机里，总比传服务器安全”，于是把用户手机号、身份证号、支付令牌（payment_token）全塞进去。但这是巨大误区。wx.setStorageSync的数据存储在微信App的私有目录下，普通用户无法直接访问，但同一台手机上，只要安装了另一个恶意小程序（或利用微信漏洞的H5页面），就可能通过系统级API读取该目录下的SQLite数据库文件。2023年腾讯安全团队披露过一个0day：利用微信WebView组件的file://协议漏洞，可越权读取同进程内其他小程序的storage文件。虽已修复，但它揭示了一个本质——本地存储的安全边界，取决于微信客户端自身的防护强度，而非开发者代码。
更普遍的问题是“存储即信任”。比如某电商小程序，用户选择收货地址后，前端把完整地址对象（含姓名、电话、详细地址）存进wx.setStorageSync('last_address')，结算页直接读取渲染。攻击者诱导用户点击一个钓鱼链接，该链接里的H5页面调用wx.openAddress接口（需用户授权），但实际并未真跳转，而是静默执行一段JS，尝试读取last_address数据——虽然微信限制了跨域读取，但如果钓鱼页是同主体（同一公众号关联的小程序），权限模型就会松动。实测中，我们用某快递公司的小程序A，成功从其关联的物流查询H5页里，读取到了用户在小程序B里保存的收货地址。
正确做法只有一条：永远假设本地存储是明文可见的。敏感字段必须加密后再存，且密钥不能硬编码在前端。推荐方案：用wx.getSetting检查用户是否开启scope.userFingerprint，若支持，则用wx.startSoterAuthentication调起生物识别，生成密钥对，公钥存服务端，私钥由系统安全模块保管，解密时调用系统API。这样即使手机ROOT，私钥也无法导出。
2.3 业务逻辑层：微信的“能力封印”挡不住设计缺陷，漏洞藏在流程断点里
这是最隐蔽、也最致命的一层。微信通过wx.authorize、wx.openSetting等API，把摄像头、位置、通讯录等敏感能力做了强管控，用户不授权就完全不可用。但业务流程的设计，却完全由开发者掌控。比如“邀请好友得红包”活动：用户A分享带参数的链接（?inviter_id=123），用户B点击后，前端解析URL参数，调用wx.login()获取code，连同inviter_id一起发给后端。后端校验B是否新用户，是则给A和B各发10元红包。漏洞在哪？就在“B是否新用户”的判断逻辑里。如果后端只查数据库里有没有B的openid，而没校验B的注册时间是否在活动开始后，那么攻击者可以提前注册小号，等活动上线后，用小号反复点击自己的邀请链接，无限刷红包。这叫“业务逻辑越权”，不涉及任何技术漏洞，纯属流程设计缺陷。
另一个经典案例是“优惠券核销”。用户在核销页调用wx.scanCode()扫码，得到一串数字（如1234567890），前端把这个数字作为coupon_code发给后端验证。后端SQL语句写成：SELECT * FROM coupons WHERE code = '1234567890' AND status = 'unused'。表面看没问题，但如果攻击者扫码时输入1234567890' OR '1'='1呢？由于小程序前端无法执行SQL，这个payload根本传不到后端——等等，别急。微信的扫码API有个隐藏特性：wx.scanCode({ onlyFromCamera: true })只限制来源是摄像头，但不校验内容格式。攻击者可以用PS伪造一张二维码图片，内容就是那段SQL注入字符串，然后用相册上传功能（wx.chooseImage）选中这张图，再调用wx.scanCode解析——此时，result字段返回的就是恶意字符串。后端若不做输入清洗，直接拼SQL，就中招了。
注意：业务逻辑漏洞无法靠工具扫描发现，必须人工走查。我的方法是画“状态流转图”：把每个用户角色（游客、登录用户、VIP用户）在每个页面（首页、商品页、订单页）能触发的动作（点击、输入、跳转）列出来，再标出每个动作背后调用的接口和参数。当发现某个动作能跳过前置校验（如未登录就能提交订单），或某个参数能影响权限判断（如
role=admin），就是突破口。
3. 实战四步法：从抓包看流量、到反编译查代码、再到接口验证找缺陷、最后复现闭环写报告
光知道漏洞在哪不够，得有可落地的操作路径。我给团队新人定的KPI是：4小时内，独立完成一个陌生小程序的初筛，输出3个可验证的中危以上线索。这个目标靠的是标准化流程，不是天赋。下面把我们每天用的四步法拆解给你，每一步都配真实截图级说明（文字描述，不放图），连新手也能照着做。
3.1 第一步：抓包看流量——不用Fiddler，用Charles+微信证书，专盯“不该出现的请求”
抓包是所有分析的起点，但微信的证书校验极严。很多人卡在第一步：装了Charles证书，微信还是提示“网络连接异常”。根本原因是微信只信任系统根证书，而Charles证书默认装在用户目录下。解决方案分三步：
第一，导出Charles根证书为DER格式：打开Charles → Help → SSL Proxying → Export Charles Root Certificate… → 保存为charles.crt。
第二，在安卓手机上安装证书：用USB线连电脑，把charles.crt复制到手机内部存储根目录；进入手机“设置→安全→加密与凭据→安装从存储设备加载的证书”，找到并安装。注意：不要点“VPN与应用”里的安装选项，那是给企业证书用的。
第三，微信里手动信任：安装后，打开微信→我→设置→关于微信→右上角“…”→帮助与反馈→右上角“放大镜”→搜“证书”→点“安装根证书”（此入口只在安装后24小时内显示）。
抓包时重点过滤三类请求：
- Host含
unpkg.com、cdn.jsdelivr.net的：检查是否加载了未审核的第三方JS库，这些库可能偷偷上报用户行为； - Method为
POST且Body含phone、idcard、token字段的：看这些敏感字段是否明文传输，或是否在URL参数里（如?token=xxx）； - Response Header含
Set-Cookie的：小程序理论上不该用Cookie，如果出现，说明后端可能混用了Web逻辑，存在会话固定风险。
我遇到过最离谱的案例：某金融小程序，登录后所有请求的Header里都带X-Auth-Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...，而这个Token的payload里明文写着{"user_id":"123456","role":"admin"}。Base64解码后直接看到权限字段——后端居然把JWT当普通字符串用，没做签名校验！
3.2 第二步：反编译查代码——不用Node.js写脚本，用现成的wxappUnpacker，3分钟解出源码
小程序代码是编译后的WXML/WXSS/JS混合包，不能直接阅读。网上很多教程教你自己写Node脚本解密，其实大可不必。开源工具wxappUnpacker（GitHub搜即可）已适配2024年所有版本。操作极简：
- 在微信开发者工具里，打开目标小程序，点击左上角“编译”按钮旁的“…”→“调试”→“打开调试器”→切换到“Network”标签页；
- 刷新页面，找到类型为
main.a.wxss或app.js的请求，右键→“Open in Sources panel”，再右键→“Save as”，保存为app.wxapkg文件； - 下载
wxappUnpacker，解压后运行命令：node wuWxapkg.js app.wxapkg，几秒后生成./unpackage文件夹，里面就是解出来的WXML、JS、WXSS源码。
重点看三个文件：
app.js：全局生命周期函数，找App({ onLaunch() { ... } })里的初始化逻辑，看是否调用了可疑的SDK（如umeng、growingio）；project.config.json：检查miniprogramRoot路径和description字段，有些开发者会在这里写测试用的后端地址（如http://192.168.1.100:3000）；- 所有
.js文件里的wx.request调用：搜索关键词url:、header:、data:，看请求地址是否硬编码（如https://api.xxx.com/v1/），Header里是否带Authorization，data里是否拼接了用户输入。
曾有个小程序，pages/index/index.js里有段代码：
wx.request({ url: 'https://test-api.xxx.com/user/info', data: { id: this.data.userId, token: getApp().globalData.token } })test-api是测试环境域名，但代码没删，上线后依然调用——结果测试环境的数据库没做脱敏，返回的用户信息里包含明文手机号。
3.3 第三步：接口验证找缺陷——不用写PoC，用Postman改参数，聚焦“四个必试点”
反编译出代码后，别急着读完所有JS。先锁定高频接口，用Postman手工验证。我总结出“四个必试点”，覆盖80%的逻辑漏洞：
① ID遍历测试：把请求里的user_id=123改成user_id=124，看是否返回他人信息。适用于所有带ID参数的GET请求；
② 权限绕过测试：把role=user改成role=admin，或删掉role字段，看是否获得更高权限。适用于所有带角色参数的POST请求；
③ 时间戳篡改测试：把timestamp=1715000000改成timestamp=1715000000-3600（往前推1小时），看是否还能通过时效校验；
④ 状态机跳转测试：比如订单状态是pending，把请求里的status=pending改成status=shipped，看是否能跳过发货确认直接完成订单。
关键技巧：所有测试必须用真实用户Token，且Token要从抓包里实时复制。不能用自己的账号Token去测别人的ID，因为微信的openid是用户级隔离的。正确姿势是：用测试账号A登录，抓到A的Token；再用A的Token去请求B的ID（如/user/profile?id=456），如果返回B的信息，就是水平越权。
某在线教育小程序，课程购买接口是：POST /api/v1/order/create
Body:{"course_id": "1001", "user_id": "789", "price": "199"}
我们把user_id改成788（另一个测试账号），price改成0.01，结果订单创建成功！因为后端只校验了course_id是否存在，没校验user_id是否等于当前登录用户，也没校验price是否匹配课程表里的售价。
3.4 第四步：复现闭环写报告——不写“存在漏洞”，写“攻击者如何操作、造成什么损失、怎么修复”
很多新人写的报告像天书：“检测到越权访问风险，CVSS评分7.5”。甲方看了直摇头：这到底有多危险？我该怎么改？我们的标准是：每一条发现，必须包含‘攻击路径’、‘影响范围’、‘修复建议’三要素，且修复建议要具体到代码行。
以刚才的订单越权为例，报告这样写：
漏洞名称：订单创建接口水平越权（High）
复现步骤：
- 用户A（openid: oABC123）登录小程序，抓包获取其Bearer Token；
- 构造POST请求：
curl -X POST https://api.xxx.com/api/v1/order/create -H "Authorization: Bearer xxx" -d '{"course_id":"1001","user_id":"oDEF456","price":"0.01"}'；- 服务器返回200，订单ID为
ORD-2024-7890，用户A账户扣款0.01元；
影响：攻击者可用任意用户ID下单，以最低价购买任意课程，导致资损；
修复建议：
- 后端
/api/v1/order/create接口，第47行，增加校验：if (req.body.user_id !== req.user.openid) { return res.status(403).json({error: 'Forbidden'}); }；- 第49行，价格校验改为查库：
const course = await db.courses.findOne({id: req.body.course_id}); if (req.body.price !== course.price) {...}；- 前端删除
user_id字段，由后端从Token里自动提取openid赋值。
这样的报告，开发组长拿过去，5分钟就能定位代码，半小时改完。而不是拿着“高危漏洞”四个字，开会扯皮两周。
4. 避坑指南：95%的新手死在这五个细节上，老手都踩过坑
再好的方法论，落地时也会被细节绊倒。这五年我带过12个新人，每个人都在以下五个点上栽过跟头。现在把血泪教训摊开讲，帮你省下至少20小时无效调试时间。
4.1 抓包时忘了关“HTTPS Only”，结果抓了一小时全是空的
这是最高频的错误。微信开发者工具默认开启“安全域名、TLS版本以及HTTPS证书”校验，意味着所有HTTP请求、所有非微信备案的HTTPS请求，都会被拦截并返回net::ERR_CONNECTION_REFUSED。新手一看控制台满屏红字，以为工具坏了，疯狂重启。其实只需一个操作：打开开发者工具右上角“详情”→“本地调试”→取消勾选“安全域名、TLS版本以及HTTPS证书”。注意：这只是调试模式，不影响线上环境，也不降低安全性——因为线上用户用的是正式版微信，证书校验照常生效。
提示：取消勾选后，首次抓包可能仍失败，需重启开发者工具。重启后，在Network面板左上角点“Clear”清空缓存，再刷新小程序。
4.2 反编译时用错工具版本，解出来全是乱码或报错“invalid header”
wxappUnpacker有多个分支，对应不同微信版本。2024年主流是wuWxapkg（支持v1.06+），但很多人下载了老版wxappUnpacker（只支持v1.03及以前）。表现是：解包后app.js文件开头是乱码（如\x00\x00\x00\x00...），或直接报错Error: invalid header。解决方案：去GitHub搜wuWxapkg，认准作者LayZhou的仓库，Star数超2k的那个。下载后，确保Node.js版本≥16.0（node -v查看），再运行命令。如果还报错，大概率是app.wxapkg文件损坏——重新在开发者工具里保存一次，别用浏览器下载的“体验版”包，那不是标准包。
4.3 接口测试时Token过期，反复抓包却找不到新Token
微信的登录态Token（session_key或自定义Token）通常2小时过期。新手测试到一半，发现所有请求都返回401，慌了神，以为环境崩了，开始重装工具、重连手机。其实很简单：回到小程序首页，下拉刷新一次，触发wx.login()重新获取code，再抓包看新的Token在哪。更高效的方法是，在app.js里搜索wx.login，找到调用位置，一般在onLaunch或onShow里，看它把code发给了哪个接口（如/auth/login），然后直接去那个接口的Response里找Token字段。
4.4 以为“没找到漏洞”就是安全，漏掉了“无感型”风险
很多新人跑完四步，没发现高危漏洞，就写报告“未发现安全风险”。这是重大失误。小程序还有三类“无感型”风险，不导致立即入侵，但长期危害极大：
- 过度授权：小程序申请了
scope.address（获取地址），但整个业务流程根本用不到地址，纯属“以防万一”。这违反微信《小程序运营规范》第3.2条，可能被下架； - 埋点泄露：
wx.reportAnalytics上报的事件名（如pay_success）里，把用户手机号当属性值（{phone: "138****1234"}），导致数据被第三方统计平台留存； - 调试残留：
project.config.json里开着"debug": true，或JS文件里有console.log("DEBUG: "+data)，上线后没删，可能泄露内部结构。
检查方法：全局搜索wx.authorize、wx.reportAnalytics、console.log，逐个确认用途。
4.5 写报告时用术语堆砌，开发看不懂，最后不了了之
我见过最离谱的报告：“检测到DOM-based XSS潜在向量，源于未对location.hash进行HTML Entity Encode”。开发看了问：“啥是Entity Encode？我该改哪行？” 其实就一句话：“pages/detail/detail.js第88行，document.getElementById('title').innerText = hashValue这行，改成document.getElementById('title').textContent = hashValue”。innerText会解析HTML标签，textContent不会。用开发听得懂的语言说话，是安全人员的基本功。
最后分享个小技巧：每次审计前，先建个Excel表，列四栏：页面路径、触发动作、调用接口、风险等级。边测试边填，填满20行基本就能覆盖主流程。别追求“全量审计”，先打穿核心链路，再扩边界。毕竟，真实世界里，攻击者也只会盯着“能赚钱”的那几个接口下手。
