微信小程序渗透实战：5步挖掘API接口与本地存储的9类高危漏洞
微信小程序的渗透，跟传统Web渗透有挺大区别。小程序代码包被加密后放在微信客户端里，攻击者没法直接拿到明文源码，但这不代表它固若金汤。实际测试中，很多团队把小程序当作“边缘资产”，防护力度远低于主站，反而成了最容易撕开的口子。下面我按实际操作的逻辑链条来讲，从包获取、反编译、接口分析到漏洞利用，每一步都会给出具体方法和绕过思路。
一、小程序包的获取与解密
想分析小程序，第一步得拿到它的包文件。微信小程序的包通常缓存在手机本地，路径一般是/data/data/com.tencent.mm/MicroMsg/[32位hash]/appbrand/pkg/。但直接用文件管理器找，你会发现大部分文件后缀是.wxapkg，而且被加密了。微信7.0版本之后，包体加密算法从AES-128-CBC改成了XOR+自定义混淆，老版本的反编译工具直接报废。
解密工具推荐用wxapkg_unpack（GitHub上有），但注意它只支持特定微信版本。如果你手头是最新版微信，可以降级微信客户端到7.0.22左右，或者用模拟器装旧版微信。举个例子，我测试过一个电商小程序，直接解密报错“magic number错误”，后来发现是微信版本不匹配——换成夜神模拟器+微信7.0.20，顺利拿到明文包。解密后，你会看到一个__APP__文件夹，里面是WXML、JS、JSON等文件。
拿到源码后，重点看app-service.js（所有业务逻辑的汇总文件）。这个文件通常被混淆过，变量名变成_0x1234这种格式。但别慌，微信小程序的JS混淆强度远低于Webpack打包后的代码，很多逻辑结构是清晰的。用VS Code打开，搜索https://或wx.request，所有后端接口地址和参数就暴露了。
有个技巧：很多开发者会在小程序里写wx.setStorageSync('token', res.data.token)这种代码，token的存储位置和字段名一目了然。我碰到过一个医疗预约小程序，它把用户ID和手机号直接写在wx.setStorageSync的key里，比如USER_ID_18912345678，这等于把敏感信息明文暴露在本地存储中——攻击者只要拿到手机，就能提取所有用户数据。
接口参数方面，注意data字段里的JSON结构。比如一个签到功能，小程序发的是{userId: "xxx", signDate: "2025-03-20"}，但服务器可能还隐含了signCount字段。你可以在调试工具里修改参数，看服务器是否校验了userId与当前登录用户的绑定关系。如果没校验，那就是越权漏洞。
小程序的网络请求默认走HTTPS，但很多团队为了调试方便，会忽略证书校验。用Burp Suite或Charles抓包时，如果遇到SSL handshake failed，说明小程序做了证书绑定（SSL Pinning）。绕过方法有两个：一是用JustTrustMe Xposed模块（需root手机），二是用frida脚本hook微信的SSL验证函数。我推荐frida，因为它不修改系统文件，而且能针对特定进程hook。
具体操作：安装frida后，运行frida -U com.tencent.mm -l ssl_bypass.js。这个脚本可以从frida代码仓库里找，核心是hookTrustManager的checkServerTrusted方法，让它永远返回true。注意微信有自保护机制，frida注入后微信可能闪退——这时候需要关闭微信的“防劫持”功能（在微信设置-安全里），或者用frida的--no-pause参数。
抓包后，你会看到大量POST和GET请求。重点关注Authorization头，很多小程序把token直接放在Header里，而且没有过期时间。我测试过一个外卖小程序，token的有效期是一个月，而且服务器只检查token是否存在，不验证用户身份——这意味着你可以用别人的token直接调用接口，实现“伪登录”。
SQL注入在小程序里其实不少见，但表现形式跟Web不同。比如一个搜索功能，小程序发的是wx.request({url: 'https://api.xxx.com/search', data: {keyword: this.data.searchText}})，你抓包把keyword改成1' OR '1'='1，如果返回所有商品列表，那就中招了。但注意，小程序端通常有长度限制，比如输入框最多50字符，你需要在抓包工具里直接修改请求包，绕过前端限制。
越权漏洞是重灾区。小程序里每个用户都有openid，但很多后端直接用前端传的openid做权限判断。比如一个订单查询接口，参数是{"openid": "用户A的openid", "orderId": "123"}，你把openid改成别人的，如果返回了别人的订单信息，那就是越权。更隐蔽的是，有些小程序用unionid（跨平台统一ID），但unionid也是前端传的——改一下就能看到其他平台用户的数据。
文件上传漏洞也值得关注。小程序上传图片通常用wx.uploadFile，后端可能会把文件直接存到OSS上。你抓包看上传接口的返回，如果返回了文件URL，比如https://cdn.xxx.com/upload/2025/03/20/abc.jpg，尝试把后缀改成.php或.asp，或者上传一个1.html文件（内容为），看服务器是否解析。我碰到过一个案例：上传头像接口只校验了Content-Type，没校验文件内容，结果上传了webshell，直接拿下服务器。
微信小程序的本地存储是隔离的，但用root手机或模拟器，可以随意读取/data/data/com.tencent.mm/MicroMsg/[hash]/appbrand/storage/下的文件。这里面存着wx.setStorageSync的数据。很多开发者会把token、用户手机号、甚至支付密码缓存到这里。比如一个金融类小程序，它把用户绑卡信息加密后存到本地，但加密密钥写死在JS里。你在app-service.js里搜encrypt或crypto，找到密钥后就能解密所有本地数据。
另外，小程序的wx.getUserInfo接口在旧版本中会返回encryptedData，这个数据需要后端解密。但如果前端直接把这个数据传给第三方（比如广告SDK），攻击者通过抓包就能拿到加密数据，配合密钥（如果密钥也暴露了）就能解密出用户的手机号、微信号等敏感信息。
微信对HTTPS抓包有严格限制，尤其是iOS系统。如果你用iOS设备测试，推荐用Stream（一款网络调试工具），它不需要越狱，通过配置VPN实现抓包。但微信会检测VPN状态，如果检测到VPN，会拒绝发送请求。解决办法：在微信的NSAppTransportSecurity配置里，允许所有HTTP请求（但微信客户端本身不允许修改）。
另一个方法是用mitmproxy配合iptables做透明代理。在Linux服务器上运行mitmproxy -T --host，然后把手机流量通过代理转发到这台服务器。微信无法检测到透明代理，因为它在网络层看不到代理存在。这个方法需要你有公网服务器，但成功率极高，我测试过所有版本微信，都没有被拦截。
有些小程序用了wx.requestPayment接口，这个接口的package参数是后端签名生成的。如果你尝试篡改package里的金额，微信客户端会直接报错“签名错误”。但你可以尝试重放攻击：抓取一次支付成功的请求包，然后重新发送，看服务器是否允许重复扣款。很多小程序的支付回调接口没有做幂等性校验，导致可以无限次使用同一个支付凭证。
另外，小程序的web-view组件是个大坑。它加载的H5页面不受小程序安全策略限制，而且很多开发者会把小程序的token通过URL参数传给H5页面。比如document.location.href获取token，然后伪造请求。
最后提一下小程序的云开发模式。很多团队用微信云开发（Tencent Cloud Base），觉得“云函数”天然安全。但云函数的调用权限是前端控制的——你在JS里搜wx.cloud.callFunction，找到云函数名称和参数，然后用postman直接调用云函数HTTP API（前提是知道云环境ID）。云函数里的数据库操作如果没做权限校验，攻击者可以直接增删改查所有数据。我测试过一个云开发的小程序，云函数getUserList没有做身份验证，直接返回了所有用户的手机号、身份证号。
小程序渗透的核心在于“降维打击”——它不像Web应用有WAF、有代码审计，很多开发者觉得小程序是“轻量级”的，安全投入很少。你只要掌握包解密、抓包绕过、本地存储分析这三板斧，就能挖到大量高危漏洞。但记住，测试前一定要获得授权，否则就是违法犯罪。