Webhook 如何验签？怎样防止伪造请求和重放攻击？

知识点详解：从收到请求到产生业务效果

为什么要保留原始请求体？

发送方计算签名时，通常使用的是一串确定的字节。接收方必须按相同协议处理这些字节。

假设原始 JSON 是 {"a":1,"b":2}。解析后重新序列化，可能变成带空格、不同键顺序或不同转义形式的内容。业务含义没变，参与签名的字节却变了。

因此入口的中间件顺序很重要。不能先让通用 JSON 解析器丢掉原始字节，再期望凭对象还原出完全一致的请求体。

不同平台的算法、签名字段和密钥形式可能不同，优先使用发送方提供的可信 SDK，不要把自定义 HMAC 代码当作所有 Webhook 的通用实现。

时间戳必须受到签名保护

以 Stripe 的签名协议为例，时间戳和请求体共同参与签名。这样攻击者不能只改时间戳，让一份旧请求看起来刚刚发送。

接收端还要检查时间与容忍窗口，并维护合理准确的服务器时钟。Stripe SDK 的默认窗口是该平台的实现约定，不是所有 Webhook 都必须采用的统一标准。Stripe 签名说明

时间窗口也不是“只允许请求一次”。窗口内的同一份合法请求，仍然可能被重复发送。

合法重试也会重复

假设我们已经处理了事件，但返回响应途中网络断开。发送方不知道结果，会再次投递。这不是伪造，验签应该通过，但业务不能再做一遍。

可以为可靠收件记录设置事件唯一键，用持久化约束处理并发重复，而不是先查“有没有”再无保护地插入。

不过，“先登记已处理，再执行业务”会在崩溃时漏处理；“先执行业务，再登记”又可能重复。若两者在同一数据库内，应考虑同事务提交；跨系统效果则需要业务幂等键、状态机或可恢复的处理流程。

不同事件 ID 也可能指向同一个业务效果，所以事件去重不能完全替代业务幂等。Stripe 重复事件说明

为什么不能先回成功，再慢慢保存？

成功响应通常表示发送方可以认为这次投递已被接收。如果消息还只在内存里，回完成功进程就崩溃，发送方未必再重试。

更稳妥的入口是：验证请求，可靠保存事件或成功交给具有相应持久性保证的队列，再返回成功。长耗时业务放到后续处理。

还要区分“接收成功”和“业务完成”。收件记录可以有待处理、处理中、完成、失败等状态，失败任务才能被发现和恢复，而不是因为入口回了 200 就消失。

同一个对象的事件可能乱序

“创建”“更新”“取消”不一定按期望顺序到达。接收时间也不一定代表业务发生时间。

处理时要结合平台的版本、事件语义和业务状态约束。必要时查询可信来源的当前状态，不能简单采用“最后收到的通知覆盖一切”。

面试官继续追问

有 HTTPS 就不用验签了吗？

HTTPS 保护传输通道，不会自动证明发到你这个公开入口的请求来自指定平台。来源认证仍需要相应机制。

签名密钥轮换怎么办？

按平台协议支持新旧密钥的受控过渡，分清测试与生产密钥，不把密钥或完整敏感载荷写进日志。轮换过渡期结束后及时撤销旧密钥。

怎么验证处理链路？

分别测试请求体篡改、过期签名、同事件并发投递、提交后响应丢失和乱序事件。每个测试要检查最终业务状态，不能只看 HTTP 返回码。

面试速记卡

• 验签：按平台协议验证原始字节，防伪造与篡改。
• 时间窗口：时间戳也要纳入签名，限制旧请求重放。
• 幂等：合法重试与窗口内重复同样要防止重复效果。
• 可靠接收：持久化成功后再返回成功响应。
• 处理边界：事件去重不等于跨系统业务恰好执行一次。