为什么使用 https 调用 API 仍然推荐需要使用 key 来签名

[dayeye2006199]

例如如下的 API -- https://open.shipout.com/portal/documentation/introduction.html#%E9%89%B4%E6%9D%83

仍然使用了获取的 key 来签名 http 头文件。我的理解是 https 已经保证了通信过程中内容的不可篡改性，这种情况下，手动签名主要是为了解决什么问题呢？

我是安全小白。

[seth19960929]

@zed1018 看了一下 5 内的常见解决方案, 上个 redis 或者用 bitmap, 缓存时间 >= 允许容错的时间.

[seth19960929]

@ZE3kr 感觉应该是理解上的问题, 让我问问阿里云

[ZE3kr]

@seth19960929 我查了下并不是所有版本 TLS 都可以防止重放。以及中间人可以干扰 HTTPS 连接导致客户端那边发多个 HTTP 内容相同但数据包不同的重试请求实现“重放”。不过不论哪种重放本来也需要业务上作处理，因为网络不稳定时客户端就可能重试请求

[momocraft]

要求 payload 里放一份自己发明的 json HMAC 的 大多是中国特产
我怀疑是刻舟求剑跟某几个大厂学的

[libook]

识别请求发起方的身份。比如我是一个攻击者，因为这个域的 CA 公钥是公开的，那么我完全可以发起一个跟合法用户一样加密的 HTTPS 请求。如果加上签名了，相当于服务器会对客户端的合法性进行验证，也就是说攻击者只要没法造出合法的签名，服务器就可以认定为非法请求。

你给出的 API 文档里说，你要在 map 序列化后拼接分配给你的 SK ，这个 SK 只有你和服务器知道，别人不知道，那么服务器就可以拿分配给你的 SK 做和你一样的操作就能得出相同的 MD5 ，就能证明请求是你发的，而不是其他人发的。

对于 HTTPS 来说，header 也是会被加密传输的，所以其实不是特别有必要将你的参数序列化一起签名。假设你签名不需要带着参数，一旦某一次的签名泄漏了，攻击者就可以拿着这个签名带着任何他想要的参数去发请求，服务器会误认为是你发的，所以带着参数一起签名可以在你签名泄漏过一次的时候，至少不会被别人伪造不同参数的请求。

签名的时候拼了时间戳，可以确保当签名泄漏一次后，在一定时间之外，攻击者无法使用相同参数来发起攻击。

[dzdh]

@seth19960929 #16

这场景都是 C->S 。那 S-S 呢。

C->S 自己实现一套 Sign 的意义呢。浏览器端 JS 公开的，sign 的 salt 哪里来呢。安卓端 Hook 之后一览无遗。图个啥呢。

[rekulas]

@ZE3kr 只能通过升级客户端和系统提高中间人攻击操作难度，但没法防御

[ychost]

AK/SK 和 Https 不冲突

[seth19960929]

@dzdh S->S 更需要啊
意义就是可以屏蔽大部分直接裸露的接口.
你看爬虫入门都是爬 xxx 家的接口, 就因为他们家的接口不用任何校验.
那你看看抖音的接口能直接捉吗(web)

[andyskaura]

就好比寄快递：
ssl：保证快递运输安全，不会被掉包偷盗。
key：快递员要求验证身份证，确保是本人收件。

[jiulang]

只有 https：直接放屁；
https+这个签名：先脱个裤子，再放个屁

[jiulang]

喜欢脱裤子放屁的人说：我脱了裤子再放，自我感觉卫生；
直接放屁的人说：方便还没啥问题，卫生不卫生看屁本身；

[dzdh]

@ychost
@andyskaura

的确不冲突。但是。是否 [必须] 要 md5/sha*/hmac* + salt 。直接在 https 基础上 basic auth 行不行呢？

[dzdh]

@jiulang #32
精辟！

[dzdh]

@seth19960929 #29
太能了。客户端抓个包而已。

https://zhuanlan.zhihu.com/p/355450670
https://blog.csdn.net/qq_44862120/article/details/107467725
https://www.cnblogs.com/cherish-hao/p/12815603.html

ios 越狱后照抓不误。函数 hook 完每一步干了啥都清清楚楚。S-S 服务端，没必要，可以客户端证书。C->S 端，更更没必要。

[andyskaura]

@dzdh 虽然 key 有那么一丁点保证安全的能力，但我更多的是把 key 理解为一个业务需求。

[dzdh]

@andyskaura yep

[seth19960929]

@dzdh 直接裸露的难度是几, 捉包的难度是几, 反编译找到 key 的难度是几.

[seth19960929]

按你这么这么说, 希望各个大厂 app 都不要加所谓保护机制了, 直接调就行了. 你去和他们说才管用.

[dzdh]

https://v2ex.com/help/api

包括 v2 的 api 也是 有个固定的 token 就行。我保护好我的 token 即可，泄露了就重新生成。Server-Server 的模式。

sign 私以为适合的是类似 S3 的私有文件开放给他人下载场景用，三方用户无需任何配置可直接凭 URL 访问资源。