我正在构建一个 Ruby on Rails API，该 API 发布到 API 用户可以创建的 webhook，每当他管理的资源被创建、更新或销毁时，使用HTTParty gem。这让我想到：我正在验证 webhook url 确实是一个有效的 url，但仅此而已。
例如，如果 API 发布到永远重定向的 webhook 怎么办？或者，可能更糟糕的是，一个 webhook 又再次与 API 通信，触发更多 webhook，因此最终 API 必须处理无限数量的 webhook？
这只是两个例子，但我想可能会发生更多。
我想出的一件事是将所有帖子放在后台任务中的 webhook 中，以便至少将工作负载分配给工作人员，以防有人尝试 DOS 攻击（但话又说回来，我不确定这是否能正确保护我免受 DOS 攻击）。
使用 webhook 时是否还有其他常见的威胁/陷阱？我可以做些什么来防御有害的 webhook 以及如何检测它们？
除了“验证 webhook URL”之外，还可以对您的 API 端点和/或调用 webhook 实施速率限制。
如果您有一个足够大/足够受欢迎的服务，即使您不允许用户拥有自定义回调 URL，您也应该拥有它——最终有人会尝试针对资源密集型（对您而言）API 端点发出一百万个请求，而您确实应该有保护。
也就是说——您不必彻底尝试检测“恶意” URL——只要有逻辑，如果单个帐户在 Y 分钟内发出 X 个请求，就会切断访问（根据需要添加更复杂的逻辑）。
——
当然，您还应该：
这些担忧都是非常有效的，我们在编写PubSubHubbub 规范时必须考虑它们。我们通过验证步骤“解决”了大多数问题，其中涉及执行 webhook 并期望从中得到特定的答案。基本上，当添加一个新的钩子时，它会通过一个 GET 请求和一个额外的 'hub.challenge' 参数来调用。然后 webhook必须以 200 响应并在正文中回显 hub.challenge。
一般来说，我建议在实现 webhook “API”时查看 PubSubHubbub，因为它就是这样 :) 最初它是为 RSS/Atom 设计的，但现在可以与任何类型的资源一起使用，包括 JSON。它还提供了安全交付机制（使用秘密和 HMAC 签名）。
将其从评论中删除，因为它很重要。
还有一个需要解决的问题是内部目标。例如，攻击者可以传递您网络内部的地址，该地址通常会被防火墙关闭和/或隐藏在 NAT 后面。其含义因您的应用程序而异。
还要考虑访问基础设施资源的可能性，例如 AWS S3 存储桶、Dynamo DB 数据库或 SQS 队列。根据您的配置，您可能允许对这些资源进行任意写入。根据您的设置，攻击者可能会从这些服务之一读取/写入数据，然后通过再生 webhook（触发将回显此数据的另一个 webhook）将该数据泄露回他/她自己的服务器！
这是验证 webhook URL 时需要考虑的问题。
要注意的另一件事是我在这个线程中没有看到的是 webhook 调用故意变慢并且使用了线程，这对于基于 php 的应用程序来说是一个问题，这样你就可以通过发出很少的请求来关闭应用程序。