小程序安全防护-微信网关&小程序加固突破（上）
写在前面
以下都是情节模拟，并非具体情况，请细加甄别
在25年中，业务以“专门下载 APP 太慢啦，我们要小程序操作”为由，施压产研，希望要求把开门等业务重要逻辑重新放回小程序，于是老板找我评估一下安全性
拜托，即使我是23年才来，我也是半接手把开门从小程序“入土”的，现在又要改回去，开什么玩笑！
“我也理解你，所以微信那边给出了一个方案，说是接微信网关和小程序加固就可以保证安全性，你看看”
然后我就被拉入了相关群组，也就意味着去测试微信网关等一系列小程序安全措施了
事前准备
其实之前在推业务下线小程序的时候，我就做过测试，论证了为什么小程序的相关实现不安全，因为从根本来说，小程序可以被理解为是微信内置浏览器渲染出的前端而已，是可以被动态调试的，一如浏览器 F12 后 Debugger
当时我还研究过 .wxapkg 的逆向拆解，还原代码之类的，可以参考：
但其实完全没必要这么麻烦……
使用工具
微信 PC 客户端：V3.9.10.19
话说回来，明明企业微信自己都带 DevTools = =
“受害者”入场
就来两个已经接入和采用方案的小程序试试呗
- 小程序：某克、某特
开始动手
某特
先假装不敌，败下阵来
某特的小程序要求微信版本不低于4.1.1（后来知道是不低于最新版本微信），但实际上这个限制可以绕过，先不浪费时间，没事，还有下篇呢
某克
完全不是对手，技术力感觉不如我这家公司= =
主要采集了三个请求和响应点：商品分类、个人主页、个人主页-地址簿
商品分类
可以明显地看到请求头和请求体是明文的，没有用特殊协议，也没有进行加密
个人主页
在 events 中可以看到本地客户端信息和与 api.nike.com.cn 的关联信息
个人主页-地址簿
作为用户隐私信息之一的地址信息，耐克是用 GET 请求，通过 upmid 去分配用户存储路径返回的
隐藏请求
在测试的过程中，仅发现了“sa?project=MiniProgram”下的 Payload 类似加密，但解析过后发现，仅仅是 Base64 编码后 URL 编码了一下，不算加密，也不是微信自身的协议形式：
动态调试
以 upmid 为着手点，动态调试得到用户地址的获取过程：
写在后面
说实话，某克测下来给我感觉完全不行啊，好像都没什么防护措施，后续也向微信那边再次确认了，他们的措辞是“可能是因为接入的是已经很久前的版本了巴拉巴拉”，那么就请看下篇吧
