在 HTTPS 时代对请求进行签名是否还有必要？

[cheetah]

今天看到百川大模型的接口文档 https://platform.baichuan-ai.com/docs/api 中要求对请求内容和时间戳进行签名，想到前几天在 V2EX 看到的帖子吐槽腾讯大模型 API 的签名( https://v2ex.com/t/975832 )。

而我们去看 OpenAI 等公司提供的 API ，是不需要这种签名的。

所以想讨论一下，在 HTTPS 时代这种签名是否还有必要？还是一种思维惯性？

我的理解：在 HTTPS 之前，这样的签名可以有效防止请求内容被篡改，是很有必要的，但现在 HTTPS 普及了，这里的好处并不存在了。另一点是重放攻击，我了解不多，请懂的朋友讲讲。

本贴不是讨论是否有了 HTTPS 之后不需要任何签名，而是讨论如百川、腾讯这两个例子里，对其他开发者提供 public API 时，是否还需要这种对请求体+时间戳进行签名的方式

[cosiner]

HTTPS 是保证链路安全, 请求签名是鉴别请求者身份的, 作用都不一样

[Wetoria]

昨天看到了，今天还在讨论😂。

客户端加密不就是为了防止接口被不信任的人调用嘛？做过爬虫就知道了。有签名和没签名的平台，实现爬虫的工作量完全不在一个量级。

https 防止的只是在传输过程中，数据不是明文，不被直接曝光。

[LynFt]

@xmumiffy ssl 防的是第三方,签名防的是用户自己.按照银行保险柜来举例子,我老婆也知道保险柜密码,现在我和她离婚了,你怎么防?

[xmumiffy]

@Wetoria 这个问题讨论的不是客户端 API ,而是服务端 API

[xmumiffy]

@LynFt 向他人透露密码后果自负.
"签名防的是用户自己",对不起,签名方法也是公开的.

[xmumiffy]

@Wetoria 这个情况下,签名算法是公开的.所以你是把你的用户开发者当爬虫防啊

[LynFt]

@xmumiffy 签名方法是公开的,所以我说的是提高攻击难度,而不是防止攻击.

[brader]

有必要，而且是有使用场景的。
比如某些不需要登录的公开 API：
无签名机制：直接抓包工具抓到接口就可薅你接口的羊毛。
有签名机制：抓包抓到接口无用，还需要反编译你的 APP ，并从混淆过的屎山代码中，找出你的签名规则部分的代码，才可薅你接口的羊毛。

虽然最终结果都是可被破解的，但我们能看到，有签名机制，增加了破解难度，可以拦截掉一大部分只是尝试心态、无能力或者无时间、无精力去反编译代码找签名规则的人。

[xmumiffy]

@brader

你不需要什么抓包工具啊,api 文档公开网上随便下.
你的破解难度就在于怎么获取到一个有效的 api key .
你能拿到一个有效的 key,不管有没有签名都一样能用,最多就是要照着文档写一遍签名.
然后一般服务商都直接提供 SDK 帮你写了签名函数.你看服务商多好,还帮你去破解他.

或者你只是看了标题,没看内容. 这个问题讨论的不是客户端 API,而是服务商提供给别的开发者用于服务端的 API.

[brader]

@xmumiffy 奥这个啊，我以为说的是给自家 APP 用的服务端 API 呢

[wuwukai007]

参数签名加密，如果数据比较重要，对爬虫还是有点效果的

[momocraft]

讨论到现在看到的真实好处也就一个增加爬取成本
而且这是公司的好处，不是密钥没泄漏的客户的好处

说到底市场定位不一样
有的公司比如企鹅，客户捏着鼻子也得用
有的公司可能觉得自己是企鹅，或者觉得像企鹅一样折腾客户就能成为下一个企鹅
用户方便不方便最不重要，毕竟人的时间不值钱

[Wetoria]

@xmumiffy 好像是。是我欠思考了。

[liuguang]

请求签名是为了证明是你调用的，而不是别人。方便区分用户，如果不签名，别人就可以冒用你的身份。

[Wetoria]

@Wetoria 防爬虫也没必要。

前台直接调用本身还要考虑跨域问题，而解决跨域一般后端增加接口做转发。

既然做转发了，那 api key 本身就隐藏在后台，签不签名问题不大。

[xmumiffy]

@liuguang 不签名用 key 也可以.
这个问题的关键在于 HTTPS 链路上可不可以明文传递 key

[GuangXiN]

几乎所有的 https API 都不会要求通过客户端证书建立 TLS 连接。apikey 、access_token 在每一次 API 请求时都会在网络上传输，只要一次 MITM 攻击就可能泄漏，风险较高，所以一般设计有效期都不会太长。secret 一经颁发就长期保存在客户的服务器上用于签名，不会再通过网络传输，泄漏的风险小很多。

[dayeye2006199]

X 经问题，我之前也问过： https://www.v2ex.com/t/868678#reply64

结论是：给恶意使用者制造一点麻烦，但是基本防不住厉害的东西。
因为别人都这么干，所以我也这么干就对了

[likunyan]

需要，增加被攻击的成本。

[iseki]

只会增加开发成本，没必要

[fengw233]

https 是可以被劫持的，可以通过攻击请求方拿到请求数据向 api 发起重放，签名可以避免身份验证信息明文传输 以及防止重放攻击

[GeekGao]

如果接口已经使用了 HTTPS(HTTP over TLS/SSL),那么参数签名的必要性会降低一些:
HTTPS 本身就可以防止中间人攻击,数据传输在加密通道内,参数不易被篡改。
但 HTTPS 无法防止客户端篡改参数后再发送请求的情况。此时参数签名可以作为最后防线,检测参数是否被篡改。

一些特殊攻击如重放攻击,HTTPS 也无法直接识别和防护。参数签名可以识别非法重复请求。
如果应用很关注请求参数的完整性,并且接口对传入参数做进一步校验使用,那么签名依然可以作为辅助手段。
所以,如果仅仅考虑传输安全性,在使用 HTTPS 的前提下,参数签名的防护效果会受到一定程度的冲减。

但总的来说,参数签名作为一种应用层的安全机制,它的价值并不完全取决于传输层是否使用 HTTPS 。
如果成本允许,最稳妥的做法是:
- 使用 HTTPS 加密传输
- 加上参数签名的验证
- 合理限制接口调用频率
- 以获得最全面深度的防护效果。这种多层防护的合作也是 RESTful 接口安全设计的一个好习惯。

[me1onsoda]

@xmumiffy #116 "这个问题的关键在于 HTTPS 链路上可不可以明文传递 key"
key 加密有什么意义？加密方式都是公开的对称的，谁都能解开

[xmumiffy]

@me1onsoda 还是看下题目吧,这里说的是 api-key ,key 压根不用于加密,明文传递 key 用于确认身份的.

[xmumiffy]

@me1onsoda 你就当这个 key 是无法被列举出来的 user_id 就行

[rekulas]

@CRUD 大家讨论的都是应用层的啊,应用层重放跟 tls 没半毛钱关系,我能拿到你数据直接正常握手推修改的参数就行了

[xmumiffy]

@rekulas 你怎么拿得到？这里讨论的都不是客户端 API ，是服务器端的

[rekulas]

@xmumiffy 上面已经 n 个人说过 n 遍了 随便一个中间人攻击就拿到了

[xmumiffy]

@rekulas https 防的不就是中间人攻击，能攻破 PKI 的看的上我的接口那我也太成功了，市值怎么也得先超过苹果加谷歌之和吧。

[CRUD]

@rekulas #126 问题是你拿不到数据，这种情况下，中间人能拿到的顶多就是 HTTPS 的密文，密文拿到了你也没法修改，想要拿到明文数据，除非你入侵到本机，在发起端上添加对中间人证书的信任。

[rekulas]

@xmumiffy 我不知道你想表达什么，讨论的是签名有无意义莫名其妙扯到能不能劫持数据去了，如果你想讨论签名有无意义看帖子别 @我


@CRUD 说的当然就是中间人劫持，例如你做一个 app ，不做签名只需要小白中间人劫持就能拿到你通信方式，简简单单就可以模拟 app 请求服务端了，如果做了签名小白就搞不定了，得经验更丰富的开发者逆向分析代码才行，提高了攻击成本，如果签名后再加密，那攻击成本就更高了

签名和加密基本要选择一个，我逆向过的 app 也有数十款了，就没大公司 app 敢直接 https 推消息的，做了签名还要做加密的也不少（字节系的特别喜欢）

[xmumiffy]

#131
那看来我们是鸡同鸭讲了,他只了解他做的有关 APP 端的东西,对其他事务一点也不了解.
#127 中我就已经说了这里讨论的是服务器端的 API,并不是 APP 端的.

[CRUD]

@rekulas #131 我一开始就说了是服务器对服务器单向调用的情况下，回答的是题主说的 public API 的场景，你非要说其他场景，那签名也却有其存在的道理。

[rekulas]

@CRUD 抱歉看错了 没注意你说的是单纯服务器端通信

[hanyuwei70]

@cheetah 简单讲就是防篡改，为什么在 https 下还需要防篡改就要自己看原文了