ユーザーが任意のURLをWebフックとして設定できる可能性のある問題
私はまだ計画段階にあるので、これは完全に具体化されない可能性がありますが、SaaS=プロジェクトに取り組んでいます。その一部により、ユーザー（私のSaaSの顧客）がイベントを監視し、事前構成された方法で応答するAPI。1つの応答は、API（PHPで構築）がPOST設定中に指定されたパラメーターを使用して提供されたURLへのHTTPリクエストを開始することです。ユーザーがこれらのリクエストを自分のサーバーまたは他の内部システムにポイントし、これらのリクエストをリッスンして、独自の内部メール/追跡/支払いシステムと統合できるようにすることを目的としています。
ただし、これらのユーザーが私のサーバーにPOSTリクエストを送信するユーザーを自由に統治できるようにすることについては、少し心配です。 URL入力とパラメーターをサニタイズし、送信できるリクエストの数を制限すると仮定すると、ユーザーがAPIからPOSTをトリガーすることに起因する潜在的な悪意のあるユースケースはありますか？
ユーザーに任意のエンドポイント構成を与えることを心配します。
事前にドメインを検証しておくとよいでしょう。
例：goodguy.comがサインアップし、admin @ goodguy.comにメールを送信してドメインの検証を実行するか、クエリを実行してドメインの所有権を検証できるtxt DNSレコードを設定してもらいます。
他のすべての対策も必須であり、レート制限、サニタイズなどですが、ユーザーがドメインに自動リクエストを送信する権利を持っていることを確認する必要があります。
ユーザーが私のAPIからPOSTをトリガーすることに起因する潜在的な悪意のあるユースケースはありますか？
私の頭の上のいくつか：
- 非常に遅いブルートフォース攻撃、レート制限はこれをキャッチしません
- 複数のアカウントのサインアップ、DOS攻撃、つまり1000人の偽のユーザーがサインアップし、すべてがどこかで複雑な投稿リクエストを発行する
- サービスを悪意のあるリクエストのマスクとして使用します。つまり、私が制御するサーバーから悪意のあるペイロードの束を送信すると同時に、サーバーから同じターゲットにスパムを送信します。これにより、サーバーIPが被害者のログに記録されます
はい、これは危険です。 Server Side Request Forgery （SSRF）まで自分を解放します。
ネットワーク内から任意のURI：sにPOSTリクエストを送信する機能をユーザーに与える場合、ユーザーは到達することが想定されていないものに到達する可能性があります。ある種の機密HTTPがあるとどうなるでしょうかネットワーク上で実行されているサーバーで、誰かがこれを使用してリクエストを送信した場合、リクエストの内容をどの程度制御できるかに応じて、移行に問題が生じることもありますが、一般的にはお勧めできません。
それで、それをどのように軽減しますか？ URIをフィルターにかけることもできますが、これは見かけよりもはるかに難しく、信頼できるかどうかはわかりません。いくつかの挑戦についての議論は this を参照してください。別のアプローチは、あなた自身のネットワークの外のサーバーを通してリクエストを単にプロキシすることです。