API 接口已经有 HTTPS 的前提下，为什么还需要签名机制？

[dzdh]

注意场景：

• 服务端对服务端的接口，不是客户端对服务端的接口
• 防止中间人可以 PINNED Pub Key，因此中间人攻击不在考虑范围内
• 极端条件可以使用客户端证书

综合以上三点。为什么在 Https 的保护下，还要额外做签名验证？

主要疑问，如 stripe 的退款接口

curl https://api.stripe.com/v1/refunds -u "$密钥:" -d charge=$charge_id

就可以发起一笔订单的退款或者扣款。按照某些论述的话，没有签名的 Stripe 岂不是非常危险？

[crab]

防中间人也要防客户

[skull]

瞎回答一下，服务端对服务端是理论场景，放出去的 api 不敢保证对方也是服务端

[ferock]

防御的场景不同

[wanguorui123]

AppKey 安全的前提下，签名的过期时间戳有一定防止重放的功能，HTTP 下可以额外防止数据篡改，HTTPS 下除了对过期时间的验证好像没什么用

[dzdh]

@Vegetable 签名机制完全没必要，安全及重放等攻击的防止是靠接口逻辑设计的，不是靠签名的。

[dzdh]

@crab Pinned Pub Key 还怎么中间人呢？防止客户的什么呢？

[dzdh]

@skull 对方不是服务端能怎样呢？

[dzdh]

@ferock 比如？

[dzdh]

@wanguorui123

参见 18 楼。

如 http://domain/path?order_id=x&sign=n 。是的没错，这个请求无法被篡改。

我可以直接不停的直接请求，这就是重放攻击对吧？那就单单是『签名』是怎么防止重放攻击的呢？难道不是 API 的露酒设计来检测 order_id 的请求次数么？或者 sign 的请求次数么？无论是否是签名都需要做这一步啊？

[dzdh]

@dzdh 漏酒 => 逻辑。

我一直怀疑我的键盘坏了 ...

[ferock]

@dzdh #28

楼上不是很多人都说了吗？
ssl 防御的是中间人攻击
而签名是防御：非授权客户的额外请求

不是一个场景

[wanguorui123]

@dzdh xxx&timestarp=xxx，timestarp 就是时间戳，通过判断过期时间和上次请求的时间戳过滤请求

[yukiww233]

1 签名会把时间戳签进去;
2 签名不能完全避免, 只是增加了一层破解客户端的难度
3 没看懂你那段"业务逻辑"是怎么防止重放的, key 是 server 返回的, 那直接重放 server 返回 key 的请求呢?

[pkoukk]

提高伪造消息的门槛啊。
作为码农肯定都干过 F12 查 api 地址参数，然后假冒浏览器调用 api 的行为。
有了签名就得逆向代码找到签名逻辑，如果没有签名就直接拿来用了

[dzdh]

@yukiww233 33
@wanguorui123 32
我接受请求啊，因为你的 KEY 是合法的啊（ stripe 的 user)。

但是针对某一个资源的操作如 x_id=N，只要我接口保持幂等，无所谓重放不重放吧？对实际业务 0 损失啊？即便有签名，也只是根据 timestamp 和当前服务器时间的差值决定是否拒绝请求，但是请求依然进来了啊。

[dzdh]

@ferock

这个『授权』是怎么定义呢？签名怎么体现『授权』呢？客户端证书是否也能实现呢？

[dzdh]

@pkoukk
注意场景 Server 端到 Server 端。没有浏览器。
即便有客户端的场景，哪个浏览器端的接口设计是有签名的请赐教

[dzdh]

@yukiww233 32

key 是 被调用方 分配 /颁发给 调用方，或调用方主动在被调用方处登记注册的。如帐号密码

[wanguorui123]

@dzdh 1 、有些时候需要防止重复下单，通过 timestarp 验证是否和上次相同来避免、2 、有些时候防止文件被盗链，这时候通过 timestarp 的过期时间来验证是否是过期资源，防止迅雷等工具盗刷流量

[dzdh]

@wanguorui123 39
理解。但是：

> 注意场景是 Server To Server

1. API 的接口设计的逻辑是否可以要求下单的时候带上一个发起方的 ID 呢？这个 ID 不就是个 nonce 么？根据这个 ID 也可以防止某个内部服务重复下单啊（注意场景是 Server 端到 Server 端，如 stripe 、paypal 、支付宝、微信的预下单接口）

2. 是否可以直接生成一个加密 token 在 token 里直接绑定 ip 、时间戳，然后这个 token 一次有效呢？只能由 openssl 解密（是的，没有仅仅只依靠 HTTPS ）

我指的签名仅仅指的是：按照规则排序然后拼字符串使用 shaX/mdX 的形式