聊聊 API 签名方式

前言

现在越来越多的公司以 API 的形式对外提供服务，这些 API 接口大多暴露在公网上，所以安全性就变的很重要了。最直接的风险如下：

非法使用 API 服务。（收费接口非法调用）
恶意攻击和破坏。（数据篡改、DOS）

因此需要设计一些接口安全保护的方式来增强接口安全，在运输层可添加 SSL 证书，上 HTTPS，在应用层主要是通过一些加密逻辑来实现。目前主流的两种是在 HTTP Header 里加认证信息和 API 签名。

HTTP 简单身份认证

在 HTTP 请求的 Header 中添加认证字段例如：

Authorization: 3F2504E04F8911D39A0C0305E82C3301

服务器处理前取出该字段进行校验即可。

Spring Boot 项目直接实现一个拦截器就可进行判断：

String token = request.getHeader("Authorization");

if (!Strings.isNullOrEmpty(token)) {

    hasAuth = redisTemplate.hasKey("userToken:" + token);

}

这类方法实现比较简单，可以做基本的身份认证，防君子不防小人，可通过中间人攻击获得 Authorization。使用 HTTPS 安全性会得到提高，但是无法抵御重放攻击造成的影响，例如 DDOS。

API 签名认证

API 签名的方式较前一种要复杂的多，但是可解决的安全问题也更多：

可校验请求者的合法性。
可以校验参数的完整性和是否被篡改。
可以防止重放攻击。

part1：请求端加密

API 使用者会获取到服务器颁发的 ak 和 sk 两个秘钥，ak 为公钥，sk 为私钥。

签名有以下规则：

约定请求时会携带 ak 作为参数并放入 HTTP Header。
请求参数处理：
- GET：取出所有的参数，并根据 key 进行字典排序，拼装成如下格式。
- POST：如果是 application/x-www-form-urlencoded，直接取出和 GET 参数进行排序拼接，如果是 application/json，则直接将整个 json 串 md5 加密后再 base64。

GET:

strToSign = uri + "\n" + ak=ak&k1=v1&k2=v2&k3=v3

POST:

strToSign = uri + "\n" + ak=ak&k1=v1&k2=v2&k3=v3 + "\n" + base64(md5(json_body))

使用 HmacSHA256 算法，传入 sk 进行签名计算，sign = base64(HmacSHA256(K,strToSign))，其中K=sk。
组装 HTTP 请求，将 X-Ca-Key=ak,X-Ca-Signature=sign 添加到 HTTP Header 中进行请求。

一个简单实例如下图所示：

part2：服务端解密

同样的，服务端获取到请求的 ak 后，查询出对应的 sk，使用相同的规则进行签名计算，计算出的 sign 和传入的 sign 比对，就能够知道参数是否被篡改。

经过这样签名方式后，可以保证上文提到的，校验请求者的合法性和校验参数的完整性和是否被篡改。但是如果有人施加一个中间人攻击，就可以获取到请求报文，即便攻击者无法破译出签名规则，也可以将请求重放，也就是原封不动提交给服务器，那么如果发起恶意大规模攻击，就会使服务器产生拒绝服务。

更进一步

如果需要的安全性更高，可以采用 timestamp 和 nonce 来解决这个问题。

timestamp：很好理解，调用者传入，服务端判断，一段时间失效。
nonce：在信息安全中，nonce 是一个在加密通信只能使用一次的数字。

单一使用 timestamp，可以一定程度上减少重放攻击的频率，但是无法完全遏制。

单一使用 nonce，咋一眼看可以保证请求的唯一性，但实际上服务端，随着时间推移服务端无法存储大量的 nonce，需要进入淘汰环节，一旦旧的 nonce 被淘汰，那么攻击者依旧可以卷土重来进行重放攻击。

因此，将两者结合一起来就是最终的方案，服务端首先验证 nonce 是否存在，再校验时间戳是否在规定的期限内。如果旧 nonce 被清理，也有时间戳进行把关，使得请求无法被重放。

part1：请求端生成 timestamp 和 nonce

生成时需要保证短时间内生成 nonce 的唯一性。

将 timestamp 和 nonce 写入 HTTP Header 中。

part3：服务端校验

数据库查询请求带上的 nonce 是否存在（推荐使用Redis，自带TTL功能）。
如果不存在，且请求时间有效则为合法请求，同时将 nonce 写入，并记录时间；如果不存在，且请求时间超出规定时限，判断为恶意请求。
如果已经存在，判断为恶意请求。

做足以上这几部基本上已经可以保证一定的安全性。当然还有更复杂的，可以阅读阿里的 Open API 签名文档，根据项目自身对于安全性的需求可以适当进行简化。本文讲到的基本逻辑就是根据阿里的来的。

API 签名与 HTTPS

这边还想提一下 HTTPS。之前看到一则知乎上的提问：使用了 https 后，还有必要对数据进行签名来确保数据没有被篡改吗？

总结一下就是：

API 签名保证的是应用的数据安全和防篡改，并且可以作为业务的参数校验和处理重放攻击。
HTTPS 保证的是运输层的加密传输，但是无法防御重放攻击。

换句话说，HTTPS 保证通过中间人攻击抓到的报文是密文，无法或者说很难破解。但仍然可以将报文重发，形成 DDOS。同时，如果不签名，只用 HTTP 简单认证，通过抓包，直接可以获取到 Authorization，就可以随意发起请求了。因此最安全的方法就是结合 HTTPS 和 API 签名。

总结

本文主要介绍了当前主流 API 签名方式，可以根据项目场景去挑选组合合适的方案。

博客还附带实现了一个根据上文规则描述的工具类，可以用于API签名，可见下面源码链接。如果需要使用 timestamp 和 nonce 的可在此基础上将这两个字段添加到 sortedMap 中一起拼接，并集成Redis。

源码

参考文献