superstudy

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

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

  • 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查询功能,查全库数据,那整个应用环境也是不安全的。

Tips: 作为应用开发人员,安全底线不可失,研究防范,不可研究破坏。

分类:

技术点:

相关文章: