微信小程序渗透

去年秋天，微信一个做电商的小程序渗朋友给我发来一个微信小程序，说他们的微信优惠券系统被人薅了。我打开一看，小程序渗页面做得挺正规，微信但翻到请求参数那一步就笑了——discount=0.01，小程序渗直接明文传。微信改个数字就能把满减金额调成任意值。小程序渗这不是微信个例。微信小程序渗透的小程序渗入口，往往比大家想的微信要浅。

小程序本质上是小程序渗跑在微信里的Web应用，技术栈无非是微信WXML/WXSS加JavaScript，通信走HTTPS。小程序渗但很多人忽略了一点：它的微信前端代码是打包下发到客户端的。你用开发者工具打开一个.wxapkg包，解包之后源码基本裸奔。变量命名清晰，接口路径完整，有些连注释都没删。我见过一个外卖小程序，解包后直接看到测试环境的API地址和硬编码的AppSecret。对，就是那个用来签名的密钥。

拿到密钥之后能干什么？伪造请求、越权访问、甚至直接调用微信支付的回调接口。有个案例是某共享充电宝小程序，它的退款逻辑在客户端判断——如果order.status == 'paid'就显示退款按钮，点击后调/refund接口。但服务端没校验订单归属。攻击者改一下订单ID，就能给任意订单退款，钱退到自己的微信零钱。这个漏洞的利用成本，低到只需要一个Burp Suite和半小时的抓包分析。

抓包这件事本身也值得说。小程序默认走微信的SSL Pinning，但很多开发者压根没开。你挂个Charles或者Fiddler，手机装个证书，请求就一览无余了。更离谱的是，有些小程序在开发阶段把checkSession的逻辑写反了——登录态失效时返回的是true而不是false。结果就是，只要构造一个过期的session，反而能拿到更高的权限。这种逻辑漏洞，扫描器扫不出来，全靠人工看代码。

再说一个我实际遇到的。某政务小程序有个“我的办件”页面，加载时请求/api/orders?userId=123。我把123改成124，页面直接显示了别人的身份证号和手机号。没有鉴权，没有token校验，连最基本的水平越权防护都没有。这种接口在设计时默认“用户只会看自己的数据”，但攻击者不会这么想。微信小程序的wx.request不会自动带什么防篡改机制，参数改了就改了。

那怎么防？别把安全逻辑放前端。所有权限判断、金额计算、状态流转，必须在服务端重新做一遍。接口鉴权用session_key或者自定义token，别用userId这种自增ID。敏感操作加签名，签名密钥别写在小程序代码里——你写进去就等于公开。还有，关掉开发环境的调试开关，别把debug: true带到线上。我见过一个小程序，线上版本还能通过wx.setEnableDebug打开vConsole，直接看请求日志。

渗透测试的角度看，小程序比传统Web更依赖客户端逆向。你得会解包、会反编译、会抓包改包。但门槛真不高。一个稍微懂点JS的人，跟着教程走一遍，就能挖出不少东西。问题在于，很多开发团队觉得“小程序是微信管的，应该很安全”。微信只负责容器安全，你的业务逻辑漏洞，它管不着。

最后说个细节。有些小程序把敏感接口放在wx.request的success回调里做二次校验，比如判断返回的code === 0才渲染页面。但攻击者可以直接调接口，根本不走你的页面。前端校验是给用户看的，不是给攻击者看的。这个道理，放在Web时代成立，放在小程序时代一样成立。