针对微信关于小程序安全设计的分析

针对微信小程序开发配置及部分配置机制分析微信小程序安全设计：

• AppSecret

管理员生成AppSecret，在与微信后台交互过程中部分接口使用，如 auth.code2Session 获取会话密钥session_key

安全分析

AppSecret维护必须为小程序管理员维护，默认微信侧管理安全

❗ AppSecret在生成后需要后台应用保存维护，存在泄漏风险，AppSecret后台留存安全性需后台应用考虑。❗

Tips: AppSecret的保存需作为后台应用安全设计的考虑项。

• session_key

通过小程序获取客户敏感信息时需使用会话密钥对数据进行解密，详见 微信开放平台

安全分析

• session_key获取需后台获取，依赖于AppSecret、小程序wx.login操作
• 小程序组件获取敏感信息需获取客户明示同意，且获取信息为加密信息，加密信息解密需后台通过session_key解密，session_key获取依赖AppSecret

✊ 敏感信息获取涉及wx.login、加密数据、AppSecret、session_key、客户明示同意，环环相扣。

• 服务器域名

添加服务器域名白名单，必须通过ICP备案且为HTTPS，设置后小程序可与该域名进行信息交互

Tips: 小程序image src不受服务器白名单限制。

安全分析

• 即使小程序内采用不安全的JS组件（如通过NPM导入开源组件）也可控制请求链路限制信息外泄，将不安全限制在小程序内
• 常规WEB不安全组件，获取页面敏感信息后通过构造script、image等标签发起网络请求，传输非法数据，微信小程序通过域名白名单机制，结合小程序不支持通过JS动态WXML构造image等标签，即使组件获取到信息通过网络请求向外推送
• 强制HTTPS确认通讯通道安全

✊ 通过白名单配置从传输通道控制信息外传风险。

Tips: 未来小程序是否支持类似于JS操作DOM方式通过JS动态修改WXML不可预知，若支持可能会引入其他的安全设计。

❗ HTTPS不安全网络下仍可被抓包查看，接口权限控制、敏感数据保护等仍需通过应用安全设计控制。

• 版本管理

版本提交可设置提交版本IP白名单，限制访问策略

安全分析

通过该机制防止APPID丢失时恶意修改代码上传

• 开发安全

提供官方微信开发者工具，保证开发工具安全

通过以上提到的开发配置及小程序机制结合分析，微信针对小程序准备了前端应用基础环境的安全保障，小程序开发者主要需要关注应用安全设计，如接口权限控制、敏感数据保护等，接下来需要考虑如何防范小程序基础环境外的安全保护。

微信小程序应用安全考虑点

针对以上分析，在小程序基础环境安全体系内，首先需要开发人员关注点包括两部分：

1、不安全网络HTTPS抓包，交易敏感信息明文传输

HTTPS抓包分析

HTTPS抓包主要通过代理软件欺骗客户端隐藏真实服务端、伪造客户端访问后台服务方式实现HTTPS报文抓取，如BurpSuite Proxy，通过代理模拟服务端证书抓包

在HTTPS抓包下，服务端被伪造，暴露交易明文，故需通过合理的安全设计防范被抓包后的敏感信息泄露，个人考虑可以参考HTTPS握手机制，模拟敏感信息会话密钥交换，保护交易报文敏感信息

• 敏感数据传输设计

首先可了解一下HTTPS握手机制 HTTPS加密（握手）过程

接下来对小程序敏感数据传输进行讨论：

参考HTTPS握手过程，计划采取同样方式完成敏感信息会话密钥交换

• 基础

1. 小程序内置RSA公钥，服务端留存RSA私钥
2. 小程序内置RSA加密算法、AES加解密算法、AES随机密钥生成算法、BASE64算法、SHA256算法

• 会话密钥交换

1. AES随机密钥生成算法生成会话密钥，小程序保管会话密钥
2. RSA算法通过内置RSA公钥加密会话密钥，用于会话密钥明文传输
3. wx.login获取loginCode作为密钥交换时的签名验证信息部分原文
4. 对 loginCode+会话密钥 SHA256 HASH算法计算会话密钥交换握手摘要信息，用于后台验证密钥传输是否安全
5. 拼接会话密钥交换握手信息，格式为 loginCode|sha256(loginCode+会话密钥)
6. 采用会话密钥加密握手信息，格式为 aes(握手信息)
7. 组装会话密钥交换报文，与后台通讯交互进行密钥交换，格式为：
   {"client_hello":"握手信息", "secret":"rsa加密完的会话密钥"}
8. 后台接受报文，解析报文，并验证会话密钥交换是否有效，验证方式如下：

a. 后台应用内置RSA私钥解密获取会话密钥明文

b. 通过会话密钥解密握手信息获取握手明文

c. 对解密完成的明文进行校验签名信息是否正确，获取明文窜loginCode及会话密钥通过sha256计算签名信息，判断是否与客户端上送一致

d. 一致情况下对loginCode与微信服务端进行转换，调用服务端API auth.code2Session 接口校验loginCode是否有效

e. 会话密钥校验成功，后台生成会话标识，用于后续敏感信息传输时标识会话信息

• 安全接口设计

1. 通过上述会话密钥交换机制，完成了安全接口的基础保障
2. 在具备会话密钥后，设计安全接口交互保障敏感信息，设计流程如下：

a. 前端生成交易明文 json_data

b. 组织安全接口报文，包含要素：

• 会话标识 s_session_key 来源为密钥交换成功后服务端响应给客户端的会话标识
• 交易时间戳 s_time_stamp
• 交易数据密文 s_data 来源为 aes(json_data) aes加密密钥为会话密钥
• 交易报文摘要 s_mac 来源为 sha256(会话密钥+json_data+s_time_stamp)

c. 后台报文解密及验证，验证流程如下：

根据s_session_key获取会话密钥 --> 解密s_data获取交易明文 --> 服务端计算 s_mac_server (获取服务段留存会话密钥及报文时间戳，按照前端算法及明文拼接方式一致计算) --> 比对计算结果

• 设计分析

通过敏感信息会话密钥机制，可以保护交易敏感数据不被泄露，分析如下：

1. 内置RSA公钥，客户端仅包含RSA公钥，在会话密钥交换过程成只有服务端留存有RSA私钥，故即使抓包，会话密钥也无法被截取
2. 采用微信loginCode作为会话密钥交换时的验证因子，这样后台会话密钥交换成功时通过loginCode与微信后台进行接口交互，
   确保会话交互时是通过小程序官方生成的会话，通过微信接口获取到OpenId留存会话，用于后续会话权限控制使用
3. s_session_key会话标识后台未采用随机算法生成，通过 sha256(UUID＋会话密钥) 保证不可预知

2、安全参数保护

针对以上内容，在应用程序中存在一个风险点为应用程序敏感配置泄漏，故需针对敏感配置进行保护

敏感配置包括：AppSecret、RSA私钥 等其他需保护的配置信息

方式1: 对配置文件进行加密保护，防止直接泄漏，但是在使用过程中仍需应用程序解密。

方式2: 采用Vault或类似方案存储敏感参数，仅了解可通过该方式实现，具体实现自行学习。

针对以上设计，已开发程序Demo上传至Gitee

小程序端

后台

通用WEB安全设计

以上安全设计仅对基础环境、通讯链路、通讯报文进行安全防护，针对WEB应用通用安全设计，需再行扩展。

权限控制：

• 身份标识与数据范围绑定，限制操作数据范围
• 身份标识不可信任客户端，由服务端维护
• 操作中鉴定每个身份字段域与当前身份一致

客户端不可信：

• 一切客户端请求源数据不可信任，数据格式不可信任，数据内容不可信任

防重放：

• 对交易进行数据标记，同标记控制交易重放

注入攻击：

• SQL注入，Mybatis框架#{}参数可以防范
• XSS注入：任意客户端上送信息需进行转码存储及展示

Tips: 常见防护原则包括：最小授权、客户端不可信。

推荐读《白帽子讲web安全》

应用安全审计简介

有安全设计，才有安全审计

审计需准确每一笔请求记录操作时间、操作人、行为、操作数据。

总结

web应用安全涉及方方面面，包括网络安全、应用安全、系统安全等，开发人员作为应用开发专业人员，需关注应用安全，具备基本的安全底线。

各项安全面需紧密结合，才可构造出一个安全的应用环境，比如网络设备再安全，应用层开发一个简单的SQL查询功能，查全库数据，那整个应用环境也是不安全的。