V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  dzdh  ›  全部回复第 74 页 / 共 88 页
回复总数  1749
1 ... 70  71  72  73  74  75  76  77  78  79 ... 88  
2021-04-13 09:57:02 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@wanguorui123 39
理解。但是:

> 注意场景是 Server To Server

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

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

我指的签名仅仅指的是:按照规则排序然后拼字符串使用 shaX/mdX 的形式
2021-04-13 09:51:43 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@yukiww233 32

key 是 被调用方 分配 /颁发给 调用方,或调用方主动在被调用方处登记注册的。如帐号密码
2021-04-13 09:50:00 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@pkoukk
注意场景 Server 端到 Server 端。没有浏览器。
即便有客户端的场景,哪个浏览器端的接口设计是有签名的请赐教
2021-04-13 09:48:50 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@ferock

这个『授权』是怎么定义呢?签名怎么体现『授权』呢?客户端证书是否也能实现呢?
2021-04-13 09:48:05 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@yukiww233 33
@wanguorui123 32
我接受请求啊,因为你的 KEY 是合法的啊( stripe 的 user)。

但是针对某一个资源的操作如 x_id=N,只要我接口保持幂等,无所谓重放不重放吧?对实际业务 0 损失啊?即便有签名,也只是根据 timestamp 和当前服务器时间的差值决定是否拒绝请求,但是请求依然进来了啊。
2021-04-13 08:42:04 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh 漏酒 => 逻辑。

我一直怀疑我的键盘坏了 ...
2021-04-13 08:41:27 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@wanguorui123

参见 18 楼。

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

我可以直接不停的直接请求,这就是重放攻击对吧?那就单单是『签名』是怎么防止重放攻击的呢?难道不是 API 的露酒设计来检测 order_id 的请求次数么?或者 sign 的请求次数么?无论是否是签名都需要做这一步啊?
2021-04-13 08:39:34 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@ferock 比如?
2021-04-13 08:39:13 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@skull 对方不是服务端能怎样呢?
2021-04-13 08:38:41 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@crab Pinned Pub Key 还怎么中间人呢?防止客户的什么呢?
2021-04-13 08:38:17 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@Vegetable 签名机制完全没必要,安全及重放等攻击的防止是靠接口逻辑设计的,不是靠签名的。
2021-04-12 23:11:30 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@kejialiu

即便没有 nonce 。如 http://domain/path?order_id=x&sign=n 。是的没错,这个请求无法被篡改,但是我依然可以肆无忌惮的发起查询啊。

而且肯定是要有一个『某 ID 』的参数吧?如商户 ID 、用户 ID 等标记唯一应用的参数吧。那也就是说,只是某一个『用户』或『应用』能构造针对特性对象『 order_id=x 』的请求。

那相应的,HTTPS 的话直接作为 Authentication Header 参数放进来一样的哇。
2021-04-12 23:05:50 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@kejialiu

一次性的根本原因是因为有 nonce 。以此为目的达到防 Replay Attack 。

但是究其根本,HTTPS 本身被抓到已有也是个无法篡改的普通 TCP 数据包。重放攻击也只能将这个数据包无数次发送给对方服务器。也就是说,只要在普通的请求参数中加入任意一个具备 nonce 特性的参数如 timestamp,那这个数据包依然可以被直接拦截。

同时,如果说 HTTPS 不用构造直接可以无限次任意请求的话,签名模式难道就不是吗?
2021-04-12 21:49:45 +08:00
回复了 Zikinn 创建的主题 软件 你一个 PGP 和 S/MIME 都不支持的玩意要读 PGP?
:doge:
2021-04-12 20:58:55 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@wooyuntest 找密钥吧。这是客户端场景了,即便如此,仅使用 HTTPS 直接传递 ukey 的话也得逆向啊。
HOOK 方案的话无论任何方案都没辙吧。
2021-04-12 20:33:21 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@ihipop 不是老系统改造,是新系统
2021-04-12 20:33:02 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@ihipop 还好吧,客户端证书在网关直接验证好的,到后面的 HTTP 业务的时候直接带着 https_s|c_xx 的 header 头的哇而且还伪造不了
2021-04-12 20:08:58 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@des

1 理解
2 网关统一 HTTPS 不是更简单了么都不用再配置啥
3 emmmm 理解
2021-04-12 19:55:16 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@xmumiffy 国内大厂是出于什么样的考量呢?
2021-04-12 19:53:51 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@screen 如果 SSLPinning 无效的话,那客户端用『签名』也一样能截取啊
1 ... 70  71  72  73  74  75  76  77  78  79 ... 88  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5683 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 23ms · UTC 07:35 · PVG 15:35 · LAX 23:35 · JFK 02:35
Developed with CodeLauncher
♥ Do have faith in what you're doing.