记一次小程序简单又坎坷的key泄露复现

前言
上级反映某单位存在请求加密被解密替换参数发给服务端成功替换了关键参数造成了请求伪造,个人第一思路是通过逆向小程序前端破解的加密:
先定位到加密数据包:
小程序逆向调试:
但是实际跟到这一步,就无法继续了。因为测试和个人账号是没有权限调用与微信服务端的接口的,而接下来的步骤却正需要调用接口跟堆栈,在这里停留了很久......
结果在服务端响应数据包找到了突破口,详情分析请看下面:
加密流程条件分析
加解密微信encryptedData
必要条件:
sessionkey
&&appID
&&iv
用户敏感数据加密流程:
客户端向微信发起请求获取用户
加密后的数据包
和iv
客户端将获取到的
加密数据包
发送到服务端服务端收到
加密数据包
后向微信请求获取该用户的sessionkey
进行解密,并存储于服务端
正常的下面这张图的小程序接口的校验逻辑都是基于上述的流程进行的
iv
和appID
在 数据包都是可以轻易拿到的,那么关键点就是在于这个sessionkey
!
sessionkey
按照微信官方文档所给出的流程,应该是只能通过请求向微信获取,而请求中必须要涉及到一个重要的参数:appsecret
该参数是不能够给客户端获取到的。
我看了下小程序源码中并没有可以直接搜到的关键字特征就只能找其他思路了。
最后在sessionkey
发现在服务端验证成功后返回的数据包中:
AES加密,其他参数固定不变,只需要替换时间戳,那么就可以达到加解密的效果,从而实现请求伪造,附上解密截图:
总结
问题定义:服务端响应敏感密钥泄露
修复方案:在服务端验证过后,限制返回数据,避免出现敏感信息。
完毕!
免责声明
1.一般免责声明:本文所提供的技术信息仅供参考,不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》,作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。
2. 适用性声明:文中技术内容可能不适用于所有情况或系统,在实际应用前请充分测试和评估。若因使用不当造成的任何问题,相关方不承担责任。
3. 更新声明:技术发展迅速,文章内容可能存在滞后性。读者需自行判断信息的时效性,因依据过时内容产生的后果,作者及发布平台不承担责任。
本文为 独立观点,未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
文章目录