security - Webhook 安全性 - HMAC 与回调 URL 中的令牌

Question

谈到 Webhook 安全性，我看到标准是使用 HMAC。每一方都有一个相同的共享秘密。发布者使用共享密钥加密他的请求正文，并将加密的哈希放在其 webhook 通知的标头中。然后，订阅者使用共享密钥加密正文，并确认他的哈希与发布者提供的哈希匹配。通过阅读，我了解到这样做是为了让订阅者确信“身体没有被篡改”。

我的问题是，身体怎么可能被篡改？假设我们都在使用 HTTPS，黑客不需要破解 SSL 加密来修改正文吗？Twilio使用帐户身份验证令牌作为共享机密。但是，如果黑客能够打开请求正文并对其进行篡改，他们难道不能在发送授权时获取 Auth Token 吗？然后他们可以用他们抓住的秘密来欺骗加密。

那么，为什么要经历另一层安全性的麻烦，而不是让订阅者使用在 URL 路径中具有令牌的回调 URL。URL 将与正文一起加密。我看不出攻击者如何滥用这种方法。

谢谢！

标签： securitywebhookshmac

Answer 1

身体怎么可能被篡改？

它不需要。您的服务器接受来自任何人的传入 HTTP(S) 请求。HTTPS 不能保证发送者的真实性或身份，它只保证发送者和接收者可以在没有第三方拦截的情况下交换消息。

_{*除了服务器证书，还可以使用客户端证书，因此HTTPS可以相互验证两端的身份；不幸的是，它在实践中很少使用，并且正确设置可能有些棘手。这就是为什么通常首选这种替代方案的原因，因为它在实践中更容易实施。}

因此，webhook 标头中的 HMAC 试图解决的问题是验证发送者的身份，因为大概只有真实的发送者（Twilio 等）会知道创建 HMAC 的秘密。它允许接收者完全无视发送任意消息的随机第三方。

如果第 3 方拦截了请求，他们可以篡改正文，但他们无法生成新的正确 HMAC，因为他们无权访问密钥，因为密钥不是请求的一部分。

当然，另一种方法是将您希望从中接收 webhook 的一堆 IP 地址列入白名单；但这对于发送服务来说很不方便，因为他们无法根据需要自由分配 IP。它也有轻微的机会受到各种问题的影响，攻击者可能能够（部分）控制 IP，而不会导致密钥的安全漏洞。