導入

サーバー側リクエストフォージェリは、悪意のある攻撃者が被害者のサーバーを悪用して、攻撃者に代わって HTTP(S) リクエストを実行する脆弱性で。
通常、サーバーは内部ネットワークにアクセスできるため、この攻撃はファイアウォールと IP ホワイトリストをバイパスして、攻撃者がアクセスできないホストにアクセスするのに役立ち。

リクエストライブラリの脆弱性

SSRF 攻撃は、フィルターのバイパスがないことを前提として、アドレスフィルターで防止できて。
古典的な SSRF フィルタリングバイパス手法の 1 つはリダイレクト攻撃です。
これらの攻撃では、攻撃者は内部アドレスにリダイレクトするエンドポイントを提供する悪意のある Web サーバーをセットアップして。
被害者のサーバーは、外部サーバーへのリクエストの送信を適切に許可しますが、内部サービスへの悪意のあるリダイレクトに盲目的に従い。

もちろん、上記のどれも新しいものではなく。
これらの技術はすべて何年も前から存在しており、評判の良い抗 SSRF ライブラリはそのようなリスクを軽減し。
それなのに、私はそれを回避してしまい。

クライアントのコードは、統合のために作成された単純なエンドポイントで。
最初のエンゲージメントでは、フィルタリングはまったくなく。
テストの後、クライアントは反 SSRF ライブラリ ssrfFilter を適用して。
研究とコードの匿名性を目的として、ロジックをスタンドアロンの NodeJS スクリプトに抽出し。

リダイレクトバイパスを検証するために、PHP でオープンリダイレクトエンドポイントを備えたシンプルな Web サーバーを作成し、テストドメインを使用してインターネット上でホストし。 tellico.fun:

初期テストでは、脆弱性が修正されたことが実証されていて。

しかしその後、プロトコルを切り替えたところ、突然再び localhost サービスにアクセスできるようになり。
違いは最小限であるため、読者はペイロードを注意深く確認する必要があり。

どうしたの？攻撃者のサーバーはリクエストを別のプロトコル、つまり HTTPS から HTTP にリダイレクトし。
SSRF 対策保護をバイパスするために必要な作業はこれだけです。

何故ですか？ライブラリのコードベースを調べた結果人気のあるリクエスト、次の行を発見し。 lib/redirect.jsファイル：

上記のコードによれば、リダイレクトによってプロトコルの切り替えが発生するたびに、リクエストエージェントは削除され。
この回避策がなければ、サーバーがクロスプロトコルリダイレクトを引き起こすたびにクライアントは失敗します。これはネイティブ NodeJ なので必要で。
http(s).agent両方のプロトコルで使用することはできません。

残念ながら、このような動作では、エージェントに関連付けられたイベント処理も失われます。 SSRF の防止はエージェントの createConnectionイベントハンドラーの場合、この予期しない動作は、SSRF 軽減戦略の有効性に影響します。 request図書館。

ほなほな。