关于某支付公司api缺陷分析及改进建议

0x01
前言

因为我们厂某产品需要跟某第三方支付公司合作，拿到他们的支付api文档及demo后发现存在一些问题。

0x02

首先他们提供的demo中，分别有一个public.key和一个private.key，以及对应的加解密方法。一般看到这两个key可能会想到它们的作用分别是：

public key 用来加密客户端数据，发送到服务器端，服务器端根据私钥进行解。

private key 服务器端用客户端的公钥加密数据发送到客户端，客户端通过私钥进行解密。

0x03
看看api文档有些什么?

因为文档可能泄密，所以字段名及字段内容已经删除。

API中的HTTP Request和Response 结构大概是这样的：

1.所有的请求都是以表单的方式提交.

2.所有表单里的键都进行了排序(a-z).

3.通过提供的公私钥对数据进行签名或者校验.

4.然后将签名的数据再放到表单中提交.

我大致理解了这个设计者的思路：

1.保证每次请求数据的一致性.

2.保证每次返回数据的一致性.

3.没了

发现的缺陷：

1.支付中无法避免重放攻击

2.繁琐的调用方式

改进的方法：

1.将数据签名校验和放到Headers，服务端可以获取该请求后在没有对表单数据转换的情况下，进行签名校验.可以有效减少服务器压力.

2.在支付公司信任的页面上,给我们厂提供一个产生数据签名的key的页面.或者也提供一个可以方便管理key的接口.

3.Headers中加入时间戳.

4.购买HTTPS证书.

将刚刚说的 key+时间戳+表单数据+URL进行HASH签名放到头部.那么以后就可以愉快的玩耍了.

互联网没有绝对的安全，这方法只能是相对安全及方便。而且改动比较小。

同样的首发在 简书