ユーザーが送信したリソースに対してHTTPリクエストを実行する場合、どのようなリスクがありますか？
コンテキスト
私は、機能の1つがHTTP/HTTPS経由で利用可能なリソースからメタデータを取得する必要があるアプリケーションに取り組んでいます。これらのリソースはURLの形式でエンドユーザーによって送信され、次にリソースへのHTTPリクエストを呼び出して応答本文を解析し、HTML応答から関連するメタデータ（タイトル、メタタグなど）を引き出します。送信されたすべてのURLのプロトコルとしてHTTP/HTTPSを適用します。
質問/懸念
ユーザーが送信したリソースへのHTTPリクエストが、リモートでのコード実行、ファイルシステムへのアクセス、または外部に公開されていないネットワークインターフェースへのアクセスを許可する可能性のある攻撃ベクトルはありますか？
私の懸念は、ボックスから要求されたときに、アプリケーションが機密データを取得してユーザーに表示する可能性のあるネットワークインターフェイス（ループバック、ローカルホストなど）が存在する可能性があることです。
私がすでに試した/検討したこと
- サーバー側の検証では、HTTP/HTTPSリソースの送信のみが許可されます
- リダイレクトは制限まで追跡されるため、ユーザーが送信した最初のリソースのみをサニタイズするだけでは不十分です。
- プロトコルなしで送信されたリソースはすべてHTTPSに強制されます
- ユーザーが送信したリソースがSQLインジェクションを引き起こせず、HTTPリソースから破棄された値がSQLインジェクションを引き起こさないようにするために、適切な対策が講じられています
- 以下の無限リダイレクトループによって促進されるDOS攻撃を防止/軽減するための対策が講じられています
- Localhost、127.0.0.1、または完全修飾ドメインにない他のリソースへのリクエストをブロック/防止する必要がある場合があります。
- ユーザーがボックス上のDockerネットワークまたは他の同様のネットワークインターフェイスに対してリクエストを呼び出す可能性がありますか？
- ここで私が目にするリスクの1つは、悪意のあるユーザーがlocalhostまたはオンボックスネットワークにリダイレクトするリダイレクトホストを設定することです。 localhostなどへの最初の接続は許可しませんが、それらのインターフェースへのリダイレクト要求も禁止しないと問題になる可能性があります。
- ある種のサンドボックス/コンテナは攻撃経路を緩和するのに役立つかもしれませんが、現時点では設定は少し禁止されます
概念的にはそうです。これにより、外部ソースがアプリケーションで最終的に何が発生するかを何らかの方法で操作する（かなり明白な）方法が開かれます。それが脆弱性に変換されるかどうかは、情報をどう処理するかに完全に依存します。
持ち込むものをすべてフィルタリングすることが重要です。フィルタリングするフィールドに応じて、文字のホワイトリストまたは複数のホワイトリストを適用することを検討してください。返されたものを解釈しないことは役に立ちます-応答をプレーンテキストのみとして解析します。
リモートURL（およびプロトコル、http：//またはhttps：//であることを確認）を確実に制御し、ローカルホストやRFC1918アドレスなどをリダイレクトして拒否し、独自のネットワークを保護します。また、リモートリソースにアクセスする速度を制限します。理想的には、これらのリクエストをバッチ処理し、別のプロセスまたは別のサーバーで実行するように計画します。
引き込まれた情報の一部のみを表示すると想定して、自分のデータベースから戻ってきた場合でも、すべてを慎重にフィルタリングしてエスケープするようにしてください（途中で適切にフィルタリングされなかったことは不可能ではないため）データベースに）。最悪だと思います。
アプリケーションに必要な機能にもかかわらず、このタイプのアクティビティにはかなりのリスクが伴います。