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

[dayeye2006199]

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

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

我是安全小白。

[yin1999]

不了解这个产品，就举个例子吧，有时需要在客户端调用这些 API ，但鉴权的 key 不能下发给客户端（比如网盘服务，需要由客户端向对象存储服务上传图片），可以由服务端生成签名后的 URL ，下发给客户端，客户端直接根据 URL 发送请求，即完成了一次 API 调用，但又不会泄漏 key 。

[ZE3kr]

除了一楼说的，也不排除一些开发者配置有问题导致不验证证书的情况，以及某些操作系统过于陈旧证书缺失导致开发者为了省事不验证证书。但不管怎样不验证证书都是非常不专业的做法。也有可能是历史遗留问题，该系统曾今是 HTTP 的，后来升级 HTTPS 了但接口没变

微信支付的 Native API 也这样搞…实际上用了 HTTPS 就不需要再一次加密了。估计是为了兼容 HTTP 系统吧
https://pay.weixin.qq.com/wiki/doc/apiv3/apis/chapter3_4_5.shtml

[moen]

HTTPS 防的是传输过程中不会被监听，但是不防中间人攻击

假如中间人能获取到发送者的公钥，那中间人就能解密并篡改请求，所以要用额外的私钥签名防止内容被篡改；但只有签名也不行，因为中间人可以选择不解密原文重发，所以还要加上时间戳并参与签名防止重放攻击

[ZE3kr]

HTTPS 当然可以防御中间人攻击 https://datatracker.ietf.org/doc/html/rfc2818#section-3.1

[phpfpm]

我觉得这是几个维度的事情

ssl 解决的是你们之间的通信是不是安全，和业务无关

Authentication （ AuthN ）解决的是和你通信的是谁，毕竟不是想和每一个人打交道
Authorization （ AuthZ ）解决的是确定对方身份之后，他能做什么

[Daiwf]

https 有单向认证和双向认证的 我们一般用的是单向认证不需要本地证书。只是证明网站是官方的。双向认证需要你自己有服务端证书同一个 root 签发的证书。这样就可以认证你。当然你讲的这种方案。是业务层的认证。又是另一个维度。

[zed1018]

因为国内的好多乐色项目，把 https 当成 zz 任务来完成，自签证书还不双向验证，不 pin ssl/HSTS 。所以只能多做一些脱裤子放屁的事情来显得自己的安全防护做到位了。

[0o0O0o0O0o]

好像隔一段时间就能看到类似问题

/t/770172

[oneisall8955]

shopify 的 webhook 请求需要校验签名呢

[wanguorui123]

Pro 和 Pro Max 的区别

[dzdh]

好多回帖。就没人说说为啥列举的几个 server-side 的 api 他就是不用签名呢

[aguesuka]

虽然但是, 这个签名的功能和 https 没啥关系. appKey 是用户名, securetKey 是密码. 一般我们要登录拿到 session, 这个接口可以跳过登录.

[aguesuka]

github 用的是 Basic Authentication, 这个相当于密码明文传输, 而且每次携带密文. 尽管 https 下是安全的, 如果校验时间戳可以一定程度地防重攻击.

[lululau]

签名可以作为一种认证 (authentication) 的手段，除此之外，在 https 里又嵌一层签名的根本就不懂什么是签名什么是 https ，这种设计其实见得很多，很多金融相关的科技企业的产品都是瞎用加密技术的

[aguesuka]

不用 Basic Authentication 还是有意义的, 如果是服务器的 https 密钥泄露, 那么中间人最多只能看到明文. 如果是用户的密钥泄漏, 那只有当前用户受到影响. 相当于提高了鲁棒性.

[seth19960929]

都没说到点上. https 你被别人捉包了, 别人只是无法伪造数据, 可以无限请求.
比如说获取订单数据, 我现在获取 有 5 个订单, 一个小时后用户下单了, 我继续请求, 可以拿到 6 个订单了.

你用 sign, 你没发现 sign 参数基本都加了 ts 参数吗, 我服务端判断 ts 参数不在请求时间范围(比如说 5s 内的)直接不处理你的请求.
还有一些加了参数, 比如说你查询接口, 查询 手机, 你捉包之后可以随意查.
但是加 sign 参数, 我手机混入 sign, 你查电脑, sign 就会不一致.

[zed1018]

@seth19960929 那五秒内呢

[ZE3kr]

@seth19960929 HTTPS 不可被重放攻击，不存在你说的无限请求

[seth19960929]

@zed1018 5 s 内的通过业务代码解决. 这是一个类似中间件的解决方案

@ZE3kr https://help.aliyun.com/document_detail/50041.html

API 重放攻击（ Replay Attacks ）又称重播攻击、回放攻击，这种攻击会不断恶意或欺诈性地重复一个有效的 API 请求。攻击者利用网络监听或者其他方式盗取 API 请求，进行一定的处理后，再把它重新发给认证服务器，是黑客常用的攻击方式之一。

HTTPS 数据加密是否可以防止重放攻击？
否，加密可以有效防止明文数据被监听，但是却防止不了重放攻击。

[ZE3kr]

@seth19960929 显然他这里说的是错的
https://blog.cloudflare.com/tls-nonce-nse/