任意のwebhookのURLへの投稿を許可するのはどのくらい危険ですか？
私はRuby on Rails APIが作成できるWebhookに投稿するAPIを作成しています。APIが管理するリソースが作成、更新、または破棄されるたびに、 HTTParty gem を使用すると、これが私に考えさせられました。WebhookのURLが実際に有効なURLであることを検証していますが、それだけです。
たとえば、APIが永久にリダイレクトするWebhookに投稿した場合はどうなりますか？または、さらに悪いことに、APIと通信し、より多くのWebhookをトリガーするWebhookがあり、最終的にAPIが無制限のWebhookを処理する必要がありますか？
これらは2つの例にすぎませんが、さらに多くのことが発生する可能性があります。
私が思いついたのは、誰かがDOS攻撃を試みた場合に備えて、少なくともワークロードがワーカーに分散されるように、バックグラウンドタスクですべての投稿をWebhookに配置することです（しかし、もう一度、それが適切に保護されているかどうかはわかりません） DOS攻撃から私）。
Webhookを使用する場合、他に一般的な脅威/落とし穴はありますか？有害なWebhookを防ぐにはどうすればよいですか？
「Webhook URLの検証」に加えて、APIエンドポイントにレート制限を実装したり、Webhookを呼び出したりします。
ユーザーにカスタムコールバックURLを許可していなくても、十分に大きく人気のあるサービスがある場合は、これを使用する必要があります。最終的に誰かが、リソース集約的な（あなたにとって）APIエンドポイントに対して100万回のリクエストを行おうとします。本当に保護が必要です。
つまり、「悪意のある」URLを徹底的に検出する必要はありません。単一のアカウントがY分以内にXリクエストを行うとアクセスを遮断するロジックを用意するだけです（必要に応じてより複雑なロジックを追加します）。
-
もちろん、次のことも行う必要があります。
- webhookを非同期で（バックグラウンドで）実行するため、API速度はサードパーティに依存しません。
- 無限のリダイレクトループを防止する基本的なチェックを実行し、（たとえば）独自のドメインをブラックリストに登録します（リダイレクトターゲットごとに個別にブラックリストを必ずチェックしてください）。
これらの懸念はすべて非常に有効であり、 PubSubHubbub spec を作成するときに考慮する必要がありました。 Webhookを実行し、そこから特定の回答を期待することを含む検証ステップを行うことで、それらのほとんどを「解決」しました。基本的に、新しいフックが追加されると、GETリクエストと追加の「hub.challenge」パラメーターで呼び出されます。次に、Webhookは[〜＃〜] must [〜＃〜]で200で応答し、本体のhub.challengeをエコーします。
一般的に、私はwebhook "API"を実装するときにPubSubHubbubを確認することをお勧めします。それはそれが何であるかです:)最初はRSS/Atom用に設計されましたが、現在はanyJSONを含むリソースのタイプ。また、安全な配信のためのメカニズムを提供します（秘密およびHMAC署名を使用）。
重要なので、コメントからこれを下げる。
同様に対処する懸念は内部目標です。たとえば、攻撃者はネットワークの内部にあるアドレスを渡す可能性があり、通常はファイアウォールで保護されていないか、NATの背後に隠れています。この影響は、アプリケーションによって大きく異なります。
AWS S3バケット、Dynamo DBデータベース、SQSキューなどのインフラストラクチャリソースにアクセスする可能性も考慮してください。構成によっては、これらのリソースへの任意の書き込みを許可している可能性があります。設定によっては、攻撃者がこれらのサービスの1つにデータを読み書きし、そのデータを再生Webhook経由で引き出して（このデータをエコーする別のWebhookをトリガーして）自分のデータに戻す可能性がありますサーバ！
これは、WebhookのURLを検証するときに考慮する必要があります。
私がこのスレッドで見たことのないもう1つのことは、Webhookの呼び出しが意図的に遅く、スレッドが使い果たされることです。これにより、phpベースのアプリケーションで問題となり、非常に少ないリクエストでアプリケーションを停止できます。