查看原文
其他

聊聊 API 签名方式,看完这篇就明白了!

点击上方 "程序员小乐"关注, 星标或置顶一起成长

每天凌晨00点00分, 第一时间与你相约

每日英文

Everyone to hello, not an obligation. So, want to cherish every good to you.

对你好的每个人,都不是义务的。所以,要珍惜每一个对你好的人。


每日掏心

人生就是得这么费力的活着,多考虑长期的后果,不贪图短期的快乐;现实时常左右着我们的意愿,残酷地摇曳着我们的灵魂,一切多是虚无,鲜有真实。


来自:Fururur | 责编:乐乐

链接:cnblogs.com/Sinte-Beuve/p/12093307.html

程序员小乐(ID:study_tech)第 732 次推文   图片来自网络


往日回顾:难过!能不能放下抢票套路,我只想买好好回家过年!我在网上抢火车票:多加了100元的加速包,却依然买不到票



   正文   


现在越来越多的公司以 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 为私钥。

签名有以下规则:

  1. 约定请求时会携带 ak 作为参数并放入 HTTP Header。

  2. 请求参数处理:

  • GET:取出所有的参数,并根据 key 进行字典排序,拼装成如下格式。

  • POST:如果是 application/x-www-form-urlencoded,直接取出和 GET 参数进行排序拼接,如果是 application/json,则直接将整个 json 串 md5 加密后再 base64。

GET:
strToSign = uri + "\n" + k1=v1Z&k2=v2&k3=v3
POST:
strToSign = uri + "\n" + k1=v1Z&k2=v2&k3=v3 + "\n" + base64(md5(json_body))

  1. 使用 HmacSHA256 算法,传入 sk 进行签名计算,sign = HmacSHA256(K,strToSign)。

  2. 组装 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 中。

part2:服务端校验

  1. 数据库查询请求带上的 nonce 是否存在(推荐使用Redis,自带TTL功能)。

  2. 如果不存在,且请求时间有效则为合法请求,同时将 nonce 写入,并记录时间;如果不存在,且请求时间超出规定时限,判断为恶意请求。

  3. 如果已经存在,判断为恶意请求。

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

API 签名与 HTTPS

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

总结一下就是:

  • API 签名保证的是应用的数据安全和防篡改,并且可以作为业务的参数校验和处理重放攻击。

  • HTTPS 保证的是运输层的加密传输,但是无法防御重放攻击。

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

总结

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

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


欢迎在留言区留下你的观点,一起讨论提高。如果今天的文章让你有新的启发,学习能力的提升上有新的认识,欢迎转发分享给更多人。

欢迎各位读者加入程序员小乐技术群,在公众号后台回复“加群”或者“学习”即可。

猜你还想看


阿里、腾讯、百度、华为、京东最新面试题汇集

Nginx是什么?能干嘛?看完这篇你就明白了!

8岁上海小学生B站教编程惊动苹果,库克亲送生日祝福

我的名片能运行Linux和Python,还能玩2048小游戏,成本只要20元


关注「程序员小乐」,收看更多精彩内容
嘿,你在看吗?
: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存