评论

从安全角度审视,我是奉劝您,尽量不要轻易升级至APIv3

APIv3肯定是趋势,何以“破解”API证书权限过大问题,当下时间节点,还是等等官方的大智慧吧。

运行环境

微信支付运行时,依托强大的微信环境,国民级应用,安全性想说都没法说,杠杆滴;而接口服务,是一个后端服务,几乎看不到摸不着,这里我就简单的说一两句。

数据签名

之所以有数据签名,也是基于安全考虑,在异步运行时环境里,变量因素太多,保证请求到数据没有被篡改、伪造,简单粗暴的方式就是对数据签名,引申出的就有如下的签名方案:

MD5摘要(哈希)算法

这其实是个单向数据摘要方案,官方加密方案是把secret拼接到待摘要字符串末尾,进行摘要。MD5摘要的签名,目前公认不安全了(暴力强算可逆),不建议再使用了。

HMAC-SHA256摘要(哈希)算法

稍微比MD5数据签名安全一点的是HMAC-SHA256,这也是单向数据摘要方案。HMAC缩写的全称是Hash-based Message Authentication Code,摘要算法支持 sha256, sha512 等算法。

在这不得不提一下APIv2上几个不洁癖的地方,就是在返回值验签上,有些接口验签默认值MD5,有些是HMAC-SHA256,有些接口xml只返回了sign字段,有一些还没有,迭代风格迥异。

研发的同学可以按如下规律来判断,在有返回sign字段的时候,官方是采用的哪种签名方案,即:

  • 返回sign长度为32字节,平台方采用的是MD5数据摘要方案;
  • 返回的sign长度为64字节,官方采用的是HMAC-SHA256数据摘要方案;

无sign字段的几个接口,属于特定领域使用的,估计官方也不会再迭代了,先将就着用吧。

AES-ECB加解密

Advanced Encryption Standard with ECB (Electronic Codebook 电码本) mode 模式是分组密码的一种最基本的工作模式。算法及模式可以百科一下,这里就不展开了,属于对称加密,安全强度相较于 MD5/HMAC-SHA256 要高许多,不过存在共享密钥问题。

AES-GCM加解密

Advanced Encryption Standard with GCM (Galois/Counter Mode) 指的是该对称加密采用Counter模式,并带有GMAC消息认证码。属于对称加密,密文相较于AES-ECB解密难度要高,对应的安全等级也高一些,不过也存在共享密钥问题。

RSA-OAEP加解密

RSA加密属于非对称加密,公钥加密/私钥解密,公钥是系统间交互的,私钥是双方秘密保存的,解决了共享密钥问题,相对来说,安全级别高许多。

APIv2 适用业务形态

  • 收单服务
  • 资金应用
  • 营销工具
  • 通关报关

APIv3 适用的业务形态

  • 收单服务
  • 资金应用
  • 支付分
  • 智慧零售
    • 智慧商圈
    • 支付即服务
    • 支付即会员
    • 消费者服务
  • 营销工具

两个版本安全对比

业务形态 APIv2密钥 API证书 APIv3密钥
收单服务 需要 无需 需要
资金应用 需要 需要 需要
营销工具 需要 需要 需要
通关报关 需要 需要 -
支付分 - 需要 需要
智慧零售 - 需要 需要

从上图表格以及技术方案来看,APIv3的数据安全等级高了许多,然而,所有的操作,均使用一套 APIv3证书APIv3密钥,这对商户的安全等级考量是非常高的了,至少要达到 安全合格 检查的3类级别,通俗的讲就是要去商户,对关键信息具有较强的安全管控,以规避因误造成的损失。白话说一下风险点就是,只要掌握了商户的 API证书,那么商户的“底裤条纹及颜色”就曝露在光天化日之下了,这是对商户的一个考验。

而APIv2,收单服务仅依赖密钥,在不暴露 API证书(或者根本没有申请)的情况下,仅存在理论上的“暴露短裤”风险,短裤和底裤比较起来,相对还好的吧。。。

所以,在当下这个时间节点,在升级APIv3这件事情上,商户需要谨慎考虑并且需要做 等保合规 评估。

安全防护方面较弱的商户,我的建议是,能不提供 API证书 的绝不提供;能用APIv2的,绝不升APIv3;实在没法儿的业务,坚决要做到API证书管控,宁可不做,也不能存资金安全隐患。

不得不用的场景

对于官方新晋的赋能产品,有很多产品功能包,均是以APIv3形式提供,比如 消费者投诉接口,这项服务是微信生态内,健康交易的一个双向保障,对以服务为导向的行业来说,有此接口能力,是一个很好的体现服务质量的通道。强烈建议商户朋友们能够尽快接入。

若要接入,这下问题就来了,APIv3接口,全部需要API证书,而API证书又什么都能干。这么大的权限,对不得不接入的功能,应该如何接入呢?

从实践上,有如下几个建议:

  1. 建议API证书做安全等级管控,商户/服务商平台上,对于出资金可以设置白名单的地方,均设置上安全请求IP白名单(白名单目前只有5个名额,而且还不支持IP网段形式,且用且珍惜);
  2. 建议使用独立的签名服务,把API证书圈定在有限的环境内,避免将API证书本身分发出去,特别地,对于APP对接微信支付,千万千万 不要把API证书内置了,APP本身就是分发机制,这证书要是分发出去,后果简直这太可怕了;
  3. 建议独立的签名服务要对请求签名的应用请求进行身份认证鉴权;尤其是对于关键的 出资金 业务,不仅要验证应用请求和参与签名的路径,甚至请求报文的核心字段要做验证;

远期上来看,APIv3肯定是趋势,何以“破解”API证书权限过大问题,待就等等官方的大智慧吧。

附注链接

最后一次编辑于  2021-05-10  
点赞 3
收藏
评论

6 个评论

  • 青寒
    青寒
    2021-04-30

    点赞再看!

    V3签名不会写怎么办?有PHP手把手教学吗?

    2021-04-30
    赞同 1
    回复
  • 来一间
    来一间
    2021-09-23

    如你所说的,还是谨慎一点暂不升级好!

    2021-09-23
    赞同
    回复
  • Doris🇨🇳-软件开发🐎
    Doris🇨🇳-软件开发🐎
    2021-07-01

    看了2遍文档还是不敢升级,APIV2希望能够一直用下去

    2021-07-01
    赞同
    回复
  • 周潭潭
    周潭潭
    2021-06-20

    API能接成功就烧高香了,还要求这么多

    2021-06-20
    赞同
    回复
  • Colbert先生
    Colbert先生
    2021-05-06

    指出1个明显的错误,希望不要误导大家:

    文中说AES-ECB安全强度相较于 MD5/HMAC-SHA256 要高许多是不恰当的,理由有三:

    1)AES是对称加密算法主要解决机密性问题,MD5/SHA5是擦凑算法主要解决完整性和认证的问题,应用场景不同两者没有可比性

    2)在签名验签的场景,业界推荐使用HMAC-SHA256

    3)AES的ECB模式已是业界公认的不安全模式,推荐使用GCM模式和CBC模式


    2021-05-06
    赞同
    回复 1
    • 北望沣渭
      北望沣渭
      2021-05-06
      感谢指正 **不恰当** 的地方,本人不是安全专家,仅是从应用场景上推理出:v2的安全等级不见得比v3低;v3的缺陷在于严重依赖证书,对于升级v3,商户侧切记要做足安全防护,避免疏于防范而酿成大问题
      2021-05-06
      回复
  • 蔡婷
    蔡婷
    发表于移动端
    2021-04-30
    给大佬点赞👍🏻
    2021-04-30
    赞同
    回复
登录 后发表内容