何が起きるか

SSRFは、画像取得やURLプレビューなど、サーバーが指定URLへ接続する機能を使い、攻撃者が本来許されない宛先へサーバーから通信させる問題です。通信するのは攻撃者の端末ではなく、アプリのサーバーです。

説明用に、画像取得APIへ、画像のURLの代わりに内部の利用者一覧APIのURLを送る場合を考えます。アプリが宛先を制限せず接続すると、内部APIにはアプリのサーバーからリクエストが届きます。内部APIがその接続元を信頼して一覧を返し、画像取得APIが応答内容をそのまま利用者へ返すなら、攻撃者は自分の端末から一覧を取得できます。サーバーから内部APIへ接続でき、内部APIの認証条件を満たすことが必要です。

正常ならどう動くか

画像取得機能では、利用者が選んだ画像IDを、サーバーが管理する画像配信先へ対応付けて取得する設計が考えられます。URLを直接受ける場合も、サーバーが接続してよい配信先か確認してから通信し、画像を応答として返します。

画像取得サーバーから内部管理APIやクラウドのメタデータサービスへ接続できても、それらを利用者の入力で自由に呼べる機能にはしません。メタデータサービスは、環境によってインスタンスの設定や一時的な資格情報を返すため、サーバーからしか届かない宛先でも秘密情報を持つ場合があります。

不備と攻撃が成立する流れ

攻撃者が画像取得APIへ、画像ではなく内部管理APIのURLを取得先として送ります。アプリが接続先を制限せずそのURLへHTTPリクエストを送ると、内部APIにはアプリのサーバーから通信が届きます。内部APIが接続元だけを信頼すると、攻撃者が直接送っても拒否される操作を受け付ける場合があります。

許可したホスト名でもDNSの結果が内部IPになる場合や、外部のURLが内部のURLへリダイレクトする場合があります。文字列としてのURLの検査だけで終えず、名前解決後のIPとリダイレクト後の宛先を、実際に接続する各段階で確認します。 攻撃者がDNS応答を変えられるホストを受け付ける例では、検査用の名前解決には外部IPを返し、接続ライブラリがもう一度名前解決したときには内部IPを返すことがあります。検査したIPへ接続せず、ホスト名から再解決する隙間が原因です。

起こり得る被害と条件

情報取得の例では、内部APIが返す利用者一覧や設定を画像取得機能がそのままHTTPレスポンスへ含めます。攻撃者は自分の端末から取得APIの応答を読むことで、内部の情報を入手できます。サーバーからの到達性と内部APIの認証条件を満たす必要があります。

状態変更の例では、説明用に、取得するURLのクエリだけで監査ログを無効にしてしまう内部管理APIを仮定します。攻撃者が画像URLとしてその操作のURLを指定すると、取得機能はGETでも設定変更を起こせます。そのAPIがサーバーからの通信を許可して変更を保存すれば、取得結果を攻撃者へ表示しない機能でも、監査ログが記録されなくなる被害が発生します。取得機能で指定できるメソッド・本文・ヘッダーの範囲によって、可能な操作は変わります。

外部への漏えいの例では、取得先を攻撃者のサーバーへ変えた通信に、本来はアプリが正規の取得先へ接続するためにサーバー内で保持していた認証ヘッダーを引き継いでしまいます。攻撃者は自分のサーバーが受け取ったHTTPリクエストから、その資格情報を入手できます。別の宛先へ秘密を送る設定があることが追加条件です。

防ぎ方と、防げる理由

可能ならURLを自由入力させず、画像IDなどをサーバーが持つ固定した接続先へ対応付けます。URLが必要なら、パーサーでスキーム・ホスト・ポートを取り出して許可リストと比較し、DNSで解決したIPも内部宛てではないか確認します。リダイレクトを許す場合は転送後のURLにも同じ検査を行い、検査したIPと実際の接続先が変わらない方法で接続します。 DNSの検査で許可したIPへ実際の通信も接続させ、ライブラリに別のIPを再解決させないことを確認します。

さらに送信ネットワークを制限して、内部管理サービスなどへの接続を拒否します。取得先の変更や別ホストへのリダイレクト時には、元のサイト用の認証ヘッダーを付け直しません。宛先を制限することは不正な接続を止め、資格情報の引き継ぎを止めることは攻撃者の宛先へ秘密を送る経路を断ちます。

よくある誤解

localhostの文字だけを拒否しても、別のIP表記、DNS、転送などが残ります。「取得結果を表示しないから安全」ともいえません。接続や状態変更の副作用が起こるかも確認が必要です。

実装の確認点

画像プロキシ、Webhook試験、URLプレビュー、PDF生成などの外部通信を列挙します。URL解析からDNS解決・転送・実接続までを追い、内部IPへの接続制限と認証ヘッダーの送り先を調べます。

出典・確認範囲

  1. [1] Web Security Academy: SSRFPortSwigger / 確認日 2026-11-01