2、Webhook 安全问题：为什么需要签名校验

Webhook 本质上是一个“反向 API”——由服务端主动向第三方回调 URL 推送数据。这种架构将安全控制权从服务端转移到了回调接收方，导致攻击面显著扩大。如果没有签名校验机制，Webhook 系统几乎对所有常见网络攻击都处于“裸奔”状态。

2.1 核心安全威胁：为什么必须签名

Webhook 回调请求通常包含敏感的业务数据（订单状态、用户信息、支付结果），且接收方会依据这些数据执行关键操作（发货、改密、转账）。攻击者只需伪造一个看似合法的回调请求，就能触发不可逆的业务损失。签名校验是接收方验证请求来源真实性与数据完整性的唯一可靠手段。

2.2 三大常见 Webhook 安全风险

以下三种攻击手法是 Webhook 系统面临的最普遍、破坏力最强的安全威胁。理解它们的攻击原理，是设计签名校验方案的前提。

2.3 风险场景深度分析

2.3.1 伪造请求（Forgery Attack）

这是最直接的攻击方式。攻击者通过抓包、文档泄露或猜测，获知 Webhook 回调的 URL 和请求体结构，然后直接构造 HTTP POST 请求发送到接收方。由于接收方无法区分请求来源，会按照“合法请求”处理恶意数据。

• 攻击条件： 仅需知道回调 URL 和请求格式（通常公开或可猜测）。
• 签名校验作用： 接收方使用预共享密钥验证请求签名，没有密钥的攻击者无法生成合法签名，请求被直接拒绝。

2.3.2 重放攻击（Replay Attack）

攻击者不需要伪造数据，只需监听网络流量，截获一次合法的 Webhook 请求（包含有效签名），然后在任意时间点重新发送该请求。接收方验证签名通过，会再次执行相同的业务操作。

• 攻击条件： 能监听或窃取一次合法请求的完整报文。
• 签名校验作用： 签名本身无法防御重放，必须结合 时间戳（timestamp） 和 一次性随机数（nonce） 共同签名，接收方验证时间窗口和 nonce 唯一性。

2.3.3 中间人攻击（Man-in-the-Middle Attack, MITM）

攻击者位于服务端与接收方之间的网络路径上（如公共 Wi-Fi、被劫持的路由器），可以拦截、修改或窃听双向通信。即使使用 HTTPS，如果证书验证不严格或存在证书劫持，攻击者仍可能篡改请求体内容。

• 攻击条件： 网络路径可控，或接收方 HTTPS 证书验证存在缺陷。
• 签名校验作用： 签名基于请求体内容计算，任何字节级别的篡改都会导致签名验证失败。即使攻击者修改了数据，也无法重新生成合法签名（因为没有密钥）。

2.4 攻击链路全景图

下图展示了三种攻击在 Webhook 通信链路中的位置与攻击路径。签名校验在接收方入口处形成一道统一的防御屏障。

2.5 签名校验的防御价值总结

签名校验不是“可选项”，而是 Webhook 系统的安全基石。它同时解决三个核心安全问题：

1. 身份认证： 确认请求确实来自声称的服务端，而非第三方伪造。
2. 数据完整性： 确保请求体在传输过程中未被篡改，任何字节变化都会导致签名失效。
3. 抗重放（配合辅助机制）： 通过时间戳和 nonce 的签名绑定，防止同一请求被多次执行。

2.6 常见签名校验方案对比

业界主流的 Webhook 签名方案各有特点，下表对比了三种最常用的实现方式：