不知道小程序怎么挖掘？四个实战小程序登录口漏洞案例和AI审计

前言本文包含四个EDUSRC小程序实战案例涉及小程序appsecret泄露、AES加密三要素泄露、调试接口获取任意token、弱口令和逻辑漏洞。文中还分享了一个小程序漏洞挖掘小技巧。仅用于网络安全教学严谨利用文章内容进行恶意破坏请遵守法律法规案例A-小程序appsecret泄露打开小程序前用BP提前拦截数据包然后再打开小程序发现一个请求包的响应中完整泄露了appid和appsecret。获取appid和appsecret后在提交EDUSRC之前需验证其有效性做无害化验证。可调用微信官方提供的接口用appid和appsecret获取token。https://api.weixin.qq.com/cgi-bin/token?grant_typeclient_credentialappidwx46******9csecret9931******8638上图可以看到成功获取了access_token接着再验证该access_token是否有效。https://api.weixin.qq.com/cgi-bin/account/getaccountbasicinfo?access_token******最终发现返回的小程序名称与该小程序名称一致也证明该小程序的备案主体为某某学院。如果不想使用官方api测试也可以使用下面工具梭哈。https://github.com/mrknow001/API-Explorer可以利用多种key、access_token泄露的场景案例B-小程序sessionkey泄露导致任意登陆漏洞打开小程序前用BP提前拦截数据包再打开小程序发现一个请求包的响应中泄露了session_key。注意因为微信小程序的机制code申请后使用一次就销毁所以只能通过这种方式查看或者在HTTP历史请求里找重放是无法正常调用接口的拿到session_key后自然会联想到encryptedData、session_key、iv三要素泄露导致的任意用户注册及登录。恰好这个小程序有手机号一键登录用BP拦截到下面的请求包获得了encryptedData和iv。点击快捷手机号登录账号。用工具成功解密解密后是可以看到当前登录的明文手机号的。{phoneNumber:181*******,purePhoneNumber:181********,countryCode:86,watermark:{timestamp:******,appid:wx******}}在工具里面把解密后的手机号更改为131xxxxxxx8受害者手机号如下。{phoneNumber:131xxxxxxx8,purePhoneNumber:131xxxxxxx8,countryCode:86,watermark:{timestamp:******,appid:wx******}}随后把刚才拦截的包丢弃重新点击登录抓包。会发现iv已经发生了改变把这个iv填入工具进行加密。最后把加密内容替换请求包中encryptedData的值发送包。注意整个过程越快越好不然容易失败页面没反应就是失败了再次尝试即可下图可以看到登录成功成功获取了一个JWT令牌说明存在因小程序三要素泄露导致的任意用户注册及登录。也就是说这个漏洞只要填写任意受害者的手机号都能完成任意登陆。登录后的页面显示用户名为131****xxxx8。之所以说小程序sessionkey三要素泄露导致任意用户注册及登录是因为这种一键授权登录的机制基本上都是手机号不存在就相当于注册如果存在就相当于登录。接下来就可以去找一个系统里已有的、带角色的手机号比如学生、老师、管理员。但很不走运找了半天也没找到一个有角色的。案例C-AI审计调试API接口泄露token依旧是打开小程序前抓包但是这次没发现什么。于是就对小程序进行反编译后把源码扔给AI后审计提示词如下。请你按照“微信小程序官方文档约束型代码审计模式”工作。你需要审计我提供的微信小程序反编译文件。审计原则1. 只基于三类依据下结论- 微信小程序官方文档机制- 反编译代码中的明确证据- 授权安全测试中的可验证行为2. 不允许只凭经验直接判定漏洞。如果只是经验判断请标注为“可疑点/推断”不要直接写成漏洞。3. 不允许把小程序当成普通 Web 前端审计。必须考虑小程序运行环境、微信 API、合法域名、登录态、开放能力、云开发权限等官方机制。4. 审计每个风险点时必须包含- 风险名称- 风险等级- 代码位置- 关键代码片段- 相关微信小程序官方机制- 风险原因- 可利用影响- 合法验证思路- 修复建议- 是否属于“官方依据明确”还是“安全推断”5. 重点检查- 是否硬编码 appid、appsecret、token、密钥- 是否前端直接调用 code2Session- 是否泄露 session_key、openid、unionid- 是否把登录态、敏感信息存入 storage- 是否只依赖前端角色、前端权限判断- 是否存在未鉴权接口- 是否存在越权访问风险- 是否存在任意文件上传、下载、预览风险- 是否存在 web-view 跳转风险- 是否存在云数据库、云函数、云存储权限配置风险- 是否存在测试环境、内网地址、调试接口泄露- 是否存在接口路径、baseURL、请求头、Authorization 泄露6. 审计步骤第一步识别项目结构。第二步识别统一请求封装函数例如 api/request。第三步提取所有 baseURL、host、接口路径。第四步分析 wx.request / uploadFile / downloadFile / connectSocket。第五步分析是否有请求解密逻辑和响应加密逻辑第六步分析登录流程 wx.login、token、用户身份绑定。第七步分析页面权限、角色判断、接口鉴权逻辑。第八步输出风险清单和证据。7. 如果发现发送http请求的接口必须继续追踪- 是哪个函数调用的- 是否经过统一 request 封装- 最终是否调用 wx.request- 请求方法是什么- 是否携带 token- 是否拼接 baseURL- 是否有错误处理和未登录处理8. 禁止将 持久化到本地 storage 认为是安全风险并且不会在安全建议中提到。请严格按照以上模式审计不要给泛泛的安全建议。进行AI审计小程序反编译代码后最终AI发现了一个debug_login函数代码片段太长就不放了。这个debug_login函数的逻辑就是请求一个接口可以直接通过手机号获取token。debug的意思就是调试推测是开发人员留下的调试接口用来快速获取token但小程序上线前开发人员忘记删除调试代码就把小程序上线了。可以看到直接通过手机号就可以获取token相当于任意登陆拿到任何人手机号通过这个接口可以直接获取凭证登录。成功登录。案例D-弱口令导致身份证泄露依旧是打开小程序前抓包这次没发现什么于是开始测试功能。运气非常好一个教师登录界面用弱口令进去了。但登录成功后的响应很奇怪并没有token存在。登录进去后发现是一个考勤系统在考勤统计里泄露了62名学生的姓名、身份证、手机号信息。这个接口是通过offlineClassId直接获取该班级下学生的考勤信息。反编译小程序后提取里面的API接口发现存在一个接口推测是通过学生身份证和unitId来获取学生的班级。随后我就用获取到的身份证列表和unitId进行爆破发现其中一个学生有两个班级。获取学生姓名、身份证、手机号的接口需要传递offlineClassId这里用新获取的offlineClassId再次调用接口又泄露了40名学生的姓名、身份证、手机号。准备继续滚雪球也就是用新获取的身份证调用刚才的接口很不幸没发现新的offlineClassId。总共泄露了6240-1101名学生因为有一个学生是重复的同时在两个班级里面的姓名、身份证、手机号信息。这里也有一个逻辑缺陷因为老师登录后只会获取offlineClassId、unitId、offlineClassName后面调用接口大部分也依赖这三个值。但很明显学生肯定也知道自己的offlineClassId、unitId、offlineClassName于是就可以调用该教师接口发现其他学生的身份证信息实现垂直越权。其他教师接口理论上也可以调用但因为是考勤系统这里就没继续验证。总结前言提到的小程序漏洞挖掘小技巧细心的读者一定发现了每次打开小程序前我都会先用BP拦截数据包打开小程序后逐个分析每个包于是发现了小程序的appsecret泄露和session_key泄露。其他的反编译小程序分析JS、弱口令和逻辑缺陷都属于很常规的方法。