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签名放到头部.那么以后就可以愉快的玩耍了.
互联网没有绝对的安全，这方法只能是相对安全及方便。而且改动比较小。
网友评论