微信小程序应用安全分析及设计
针对微信关于小程序安全设计的分析
针对微信小程序开发配置及部分配置机制分析微信小程序安全设计：
- 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握手过程，计划采取同样方式完成敏感信息会话密钥交换
- 基础
- 小程序内置RSA公钥，服务端留存RSA私钥
- 小程序内置RSA加密算法、AES加解密算法、AES随机密钥生成算法、BASE64算法、SHA256算法
- 会话密钥交换
- AES随机密钥生成算法生成会话密钥，小程序保管会话密钥
- RSA算法通过内置RSA公钥加密会话密钥，用于会话密钥明文传输
- wx.login获取loginCode作为密钥交换时的签名验证信息部分原文
- 对 loginCode+会话密钥 SHA256 HASH算法计算会话密钥交换握手摘要信息，用于后台验证密钥传输是否安全
- 拼接会话密钥交换握手信息，格式为
loginCode|sha256(loginCode+会话密钥)- 采用会话密钥加密握手信息，格式为
aes(握手信息)- 组装会话密钥交换报文，与后台通讯交互进行密钥交换，格式为：
{"client_hello":"握手信息", "secret":"rsa加密完的会话密钥"}- 后台接受报文，解析报文，并验证会话密钥交换是否有效，验证方式如下：
a. 后台应用内置RSA私钥解密获取会话密钥明文
b. 通过会话密钥解密握手信息获取握手明文
c. 对解密完成的明文进行校验签名信息是否正确，获取明文窜loginCode及会话密钥通过sha256计算签名信息，判断是否与客户端上送一致
d. 一致情况下对loginCode与微信服务端进行转换，调用服务端API auth.code2Session 接口校验loginCode是否有效
e. 会话密钥校验成功，后台生成会话标识，用于后续敏感信息传输时标识会话信息
- 安全接口设计
- 通过上述会话密钥交换机制，完成了安全接口的基础保障
- 在具备会话密钥后，设计安全接口交互保障敏感信息，设计流程如下：
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 (获取服务段留存会话密钥及报文时间戳，按照前端算法及明文拼接方式一致计算) –> 比对计算结果
- 设计分析
通过敏感信息会话密钥机制，可以保护交易敏感数据不被泄露，分析如下：
- 内置RSA公钥，客户端仅包含RSA公钥，在会话密钥交换过程成只有服务端留存有RSA私钥，故即使抓包，会话密钥也无法被截取
- 采用微信loginCode作为会话密钥交换时的验证因子，这样后台会话密钥交换成功时通过loginCode与微信后台进行接口交互，
确保会话交互时是通过小程序官方生成的会话，通过微信接口获取到OpenId留存会话，用于后续会话权限控制使用- s_session_key会话标识后台未采用随机算法生成，通过 sha256(UUID＋会话密钥) 保证不可预知
2、安全参数保护
针对以上内容，在应用程序中存在一个风险点为应用程序敏感配置泄漏，故需针对敏感配置进行保护
敏感配置包括：AppSecret、RSA私钥 等其他需保护的配置信息
方式1: 对配置文件进行加密保护，防止直接泄漏，但是在使用过程中仍需应用程序解密。
方式2: 采用Vault或类似方案存储敏感参数，仅了解可通过该方式实现，具体实现自行学习。
针对以上设计，已开发程序Demo上传至Gitee
通用WEB安全设计
以上安全设计仅对基础环境、通讯链路、通讯报文进行安全防护，针对WEB应用通用安全设计，需再行扩展。
权限控制：
- 身份标识与数据范围绑定，限制操作数据范围
- 身份标识不可信任客户端，由服务端维护
- 操作中鉴定每个身份字段域与当前身份一致
客户端不可信：
- 一切客户端请求源数据不可信任，数据格式不可信任，数据内容不可信任
防重放：
- 对交易进行数据标记，同标记控制交易重放
注入攻击：
- SQL注入，Mybatis框架#{}参数可以防范
- XSS注入：任意客户端上送信息需进行转码存储及展示
Tips: 常见防护原则包括：最小授权、客户端不可信。
推荐读《白帽子讲web安全》
应用安全审计简介
有安全设计，才有安全审计
审计需准确每一笔请求记录操作时间、操作人、行为、操作数据。
总结
web应用安全涉及方方面面，包括网络安全、应用安全、系统安全等，开发人员作为应用开发专业人员，需关注应用安全，具备基本的安全底线。
各项安全面需紧密结合，才可构造出一个安全的应用环境，比如网络设备再安全，应用层开发一个简单的SQL查询功能，查全库数据，那整个应用环境也是不安全的。
Tips: 作为应用开发人员，安全底线不可失，研究防范，不可研究破坏。
