背景
最近，公司由于业务繁忙人手不够，将部分业务外包给第三方公司做。在开发的过程中，遇到了外部调用内部敏感接口场景。为了保证接口的安全，基于微信公众号消息验证机制，实现了一套安全验证流程。
微信公众号消息验证流程
当开发者向微信提交信息（含 token 配置）后，微信服务器会发送携带参数的GET请求到开发者的服务器，携带的验证信息如下：
| 参数 | 描述 |
|---|---|
| signature | 加密签名 |
| timestamp | 时间戳 |
| nonce | 随机数 |
| echostr | 随机字符串 |
开发者将通过检验 signature对请求进行验证。验证流程如下：
1）将token、timestamp、nonce三个参数进行字典序排序
2）将三个参数字符串拼接成一个字符串进行sha1加密
3）开发者获得加密后的字符串可与signature对比，若相同，则验证成功。
总结一下微信验证的原理，通过比对开发者生成的签名与微信发送的签名，来验证请求是否合法。
微信与开发者共同维护一个 token（作为秘钥，不发生传递），使用相同的签名机制，得到相同的签名。
验证机制设计
签名流程
前提：接口提供方与接入方，协商维护一个token。可以看做双方维护的密钥。
- 请求方携带参数请求接口，参数包括
signature、timestamp、nonce、业务参数。
例如，传送的参数如下：
signature: 8bbf7cde111af0c0655f578c5a84185e8f533880
timestamp: 1535253509
nonce: TyPoTPVYmp
user_id: 1
- 将参数和
token以字母升序（A-Z）排序，除去signature。
特别注意：
- 参数名 以字母升序排序
-
signature不参与排序
const token = 'youthcity';
const { signature, timestamp, nonce, user_id } = ctx.request.query;
const unordered_params = {
timestamp,
nonce,
user_id,
token,
};
const ordered_params = {};
Object.keys(unordered_params).sort().forEach((key) => {
ordered_params[key] = unordered_params[key];
});
- 再以
'key=value'+ '&' + 'key=value'连接所有参数得到字符串。
let sign_str = Object.keys(ordered_params)
.map((key) => `${key}=${ordered_params[key]}`)
.join('&');
- 将
sign_str进行 sha1 加密
const expected_signature = crypto.createHash('sha1').update(sign_str).digest('hex');
服务端拦截规则设计
对于开放接口，主要面临3个安全问题：
- 请求身份是否可信任
- 请求的参数是否被篡改
- 请求是否唯一（防止重放攻击）
将针对这三个问题，进行拦截设计。
1）验证请求参数是否包含 signature、timestamp、nonce、业务参数。若参数缺少或类型不合法，则返回错误码。
2）判断服务端接受请求时间与请求参数中的timestamp的时间差是否在合理的范围内（建议为正负 5min）。若时间差超过合理值，则请求过期，视为无效请求。（即使请求URL中的 timestamp被篡改，signature会对其合法性进行校验）
3）判断请求是否已被使用。根据 nonce，判断缓存中是否存在 KEY，若存在，则请求已被使用，返回错误码。若不存在，则以 nonce为KEY，写入缓存，并设置过期时间为 10min。
主要目的是为了防止重放攻击。避免请求参数被泄露，被其他方盗用攻击。
4）根据请求参数生成签名。对比签名是否相同。若相同，则进入业务逻辑，否则，进行拦截。
小结
通过 时间戳（timestamp）和随机数（nonce）我们可以防御大多数的请求重放攻击。随机数（nonce）可以防御短期的重放攻击，若随机数过期，则黑客可以绕过随机数的防御。这时，可以利用时间戳（timestamp）的长期防御，拦截请求。
优化与改进
- 对于安全等级较高的接口，我们还可以利用IP白名单机制，进行防御。
总结
在签名验证设计中，我们将时间戳和随机数作为验证的一部分。主要目的是防止请求链接盗用。关于时间戳的有效范围，需要根据实际业务场景和接入方服务情况进行调整。时间范围太小，可能会导致接入方请求失败。时间范围太长，请求唯一性的保证就越弱。
此外，安全验证只能验证接入方是否合法。不能保证 token泄密或者受信任方滥用接口的情况。因此，需要在业务层面，根据具体情况进行二次防御设计。例如，记录调用历史，或限制每日调用频次限制。
