SSRFとは何か。サーバーを踏み台にする脆弱性の仕組みと許可リスト方式の防御を解説

SSRF（Server-Side Request Forgery、サーバーサイドリクエストフォージェリ）は、利用者が指定したURLをサーバーが取得する処理を悪用し、サーバー自身に「本来アクセスさせたくない宛先」へリクエストを送らせる脆弱性です。攻撃者が直接届かない内部ネットワークやクラウドの管理用エンドポイントに対して、サーバーを踏み台にして到達できてしまう点に怖さがあります。OWASP Top 10では2021年版でA10:2021 Server-Side Request Forgeryとして独立した項目になり、Webアプリケーションの代表的なリスクとして位置づけられています。

この記事では、なぜSSRFが成立するのかという原理から、内部資産やクラウドメタデータへ到達されうる危険性、典型的な発生箇所、そして許可リスト方式の宛先検証やDNSリバインディング対策、クラウドでのIMDSv2の利用といった防御策までを、実務で判断できる形に整理します。攻撃の再現手順や動作するペイロードの列挙はせず、仕組みの理解と防御に絞って解説します。検証は自分が管理する環境、または明示的に許可を得た対象に対してのみ行ってください。

なぜSSRFは成立するのか#

問題の核心は、サーバーが「利用者から渡されたURLを、宛先を十分に確かめないまま取得してしまう」ことにあります。たとえば「URLを入力すると、その先の画像やページをサーバーが取りに行って表示する」ような機能を考えます。利用者が正しい外部URLを入れている限りは便利な機能ですが、サーバーは渡された文字列を信じてリクエストを送るだけなので、宛先が外部か内部かを区別していなければ、内部向けのアドレスを入れられてもそのまま取りに行ってしまいます。

ここで押さえておきたいのは、リクエストを送る主体がブラウザではなくサーバーだという点です。サーバーは多くの場合、外部からは直接アクセスできない内部ネットワークの中に置かれ、内部のデータベースや管理用APIと通信できる位置にいます。攻撃者の手元からは内部資産へ届きませんが、SSRFを突けば、その内部に居るサーバーを代理にして内部宛てのリクエストを送らせられます。リクエストはサーバーの権限とネットワーク位置から飛ぶため、ファイアウォールやアクセス制御の内側に入り込めてしまうわけです。

MITREのCWE-918は、SSRFを「サーバーが上流から受け取ったURLの内容を取得する際に、宛先が想定どおりかを十分に保証していない」弱点として定義しています。命令そのものは正規の取得処理であり、ただ宛先を攻撃者がすり替えられる、という一点が問題の本質です。

MITRE CWE-918は、攻撃者が細工した入力によって、サーバー自身や、サーバーの内部ネットワーク上のサービス、外部の第三者のいずれかへリクエストを強制でき、そのリクエストがサーバーの権限で行われる結果、認証制御を回り込んで機微な情報へアクセスされうると説明しています。

何に到達されうるのか#

SSRFが危険なのは、サーバーが到達できる範囲がそのまま攻撃面になるからです。OWASPはA10:2021のページで、代表的な悪用シナリオとして次のようなものを挙げています。

特に注意したいのがクラウドのインスタンスメタデータです。多くのクラウドでは、インスタンスからhttp://169.254.169.254/というリンクローカルアドレスにアクセスすると、そのインスタンスの設定や、紐づくロールの一時的な認証情報を取得できます。これはインスタンス内部から使う前提の仕組みですが、SSRFでサーバーにこの宛先へアクセスさせられると、攻撃者がクラウドの認証情報を手に入れる入口になりかねません。実際に、過去にはSSRFを足がかりとしてクラウド上の機微なデータが大規模に流出した事例が報じられています。

SSRFが生まれやすい場所#

SSRFは「サーバーが外部のURLを取りに行く」あらゆる機能に潜みます。実務で見落とされやすい典型的な発生箇所を整理します。

ここで見落としやすいのが、URLそのものを直接入力させていない場合です。PortSwiggerの解説でも指摘されているとおり、ホスト名やパスの一部だけを受け取り、サーバー側でそれを組み立てて完全なURLにする実装でもSSRFは起こりえます。「フルURLを受け取っていないから安全」とは言えず、最終的にサーバーがどの宛先へリクエストするかで判断する必要があります。

また、応答が画面に返らない「ブラインドSSRF」もあります。取得結果が表示されないため気づきにくいのですが、宛先へリクエストが飛ぶこと自体は変わらず、内部ポートの探索などに悪用されうるため、表示の有無で安全性を判断してはいけません。

WebアプリだけでなくAPIでも、外部URLを受け取る項目があれば同じリスクが生じます。APIの設計と検証の基本については、別記事で整理しています。

あわせて読みたい

APIセキュリティの基本。認証認可・レート制限・入力検証とOWASP API Top 10で守る

許可リスト方式で宛先を検証する#

防御の基本は、サーバーがリクエストを送る宛先を厳しく制御することです。OWASPのSSRF Prevention Cheat Sheetは、URLを検証するときに、拒否リスト（ブロックリスト）ではなく許可リスト（アローリスト）方式を推奨しています。「危険な宛先を列挙して弾く」発想は、表記の揺れや迂回手段を取りこぼしやすく、抜け道が残りやすいためです。

許可リスト方式では、業務上アクセスを許す宛先のドメインやIPの範囲をあらかじめ定義し、それ以外への送信をすべて拒否します。検証の際は次の点を押さえます。

• スキームを限定する: httpとhttpsなど必要なものだけを許可し、fileやgopherのような不要なスキームは拒否します。
• ホストを許可リストと照合する: 受け取ったURLのホストが、許可した宛先に含まれるかを確認します。
• 内部や予約アドレスを遮断する: ループバック（127.0.0.0/8）、プライベートIP、リンクローカル（169.254.0.0/16、メタデータの169.254.169.254を含む）など、内部や予約された範囲への送信を既定で拒否します。

OWASPのCheat Sheetは、宛先をあらかじめ特定できる場合と、Webhookのように利用者が任意の外部URLを指定する場合とを分けて考えます。前者では許可リストが第一の選択肢になります。後者では宛先を列挙できないため許可リストは使えず、入力されたURLが解決するすべてのIPアドレスを確認して、内部や予約された範囲を指していないかを検査する方針が中心になります。任意の宛先を許す機能ほど、内部範囲の遮断とIPの検査を丁寧に重ねる必要があります。

加えて、サーバーから外部への通信そのものを絞ることも有効です。OWASPのA10:2021は、ネットワーク層の対策として、外部リソース取得の機能を別ネットワークに分離することや、必要な通信以外を既定で遮断する「デフォルト拒否」のファイアウォール方針を挙げています。アプリ側の検証と、ネットワーク側での出口制御を重ねるほど、SSRFが成立しても被害を抑えやすくなります。SSRFは入力されたURLという「入力」を信頼しすぎることで起きるため、入力検証の基本的な考え方も併せて押さえると理解が深まります。

あわせて読みたい

入力バリデーションと出力エスケープの原則。入口で検証し、出口で文脈別にエスケープする

DNSリバインディングとリダイレクトへの対策#

許可リストでホストを検証していても、検証のすり抜けを狙う手口があります。代表的なのがDNSリバインディングです。これは、検証の段階では許可された外部IPを返しておき、実際にサーバーが接続する段階では内部IPを返すように、同じドメインの名前解決結果を切り替える手口です。「検証したアドレス」と「実際に接続するアドレス」が食い違うことで、許可リストの判定をすり抜けようとします。

OWASPのCheat Sheetは、この対策として、URLのドメイン名をあらかじめ名前解決し、解決されたIPアドレスを許可リストの範囲に対して検証することを挙げています。検証に使ったIPと、実際に接続するIPを一致させる作りにすれば、解決結果の切り替えによるすり抜けを抑えられます。

もう一つの注意点がリダイレクトの追従です。最初に渡されたURLが安全な外部宛てでも、その応答が内部アドレスへのリダイレクトを返し、サーバーが素直に追従すると内部に到達してしまいます。OWASPは、HTTP応答内のリダイレクトを無効にすることや、追従する場合も転送先を同じ検証にかけることを勧めています。あわせて、取得した生のレスポンスをそのまま利用者へ返さないようにすることで、内部から得た情報の漏えいを抑えられます。

OWASPのSSRF Prevention Cheat Sheetは、許可リスト方式でのURL検証と、解決済みIPアドレスの照合によるDNSリバインディング対策を挙げています。リダイレクトを無効にすることや、取得した生のレスポンスをそのまま利用者へ返さないことは、OWASP Top 10のA10:2021がアプリケーション層の緩和策として挙げています。

クラウドではIMDSv2を利用する#

クラウド環境では、メタデータエンドポイントへの到達を難しくする仕組みを使うことが効果的です。AWSのEC2では、インスタンスメタデータサービスにセッション指向のIMDSv2が用意されています。IMDSv2は、まずPUTリクエストでセッショントークンを取得し、以降のGETリクエストにそのトークンを付ける二段構えになっています。

この設計がSSRFに対して効くのは、多くのSSRFがGETリクエストしか送らせられないためです。先にPUTでトークンを取得する手順が必要なIMDSv2では、単純なGETだけのSSRFではメタデータに到達しにくくなります。さらにAWSのドキュメントによれば、IMDSv2のトークンを返すPUT応答のホップ制限（応答パケットがIPのTTLで越えられるネットワークホップ数）は既定で1であり、インスタンスの外へ応答が転送されにくくなっています。コンテナのように経路が一つ増える構成では、互換性のためにより大きなホップ制限が必要になる場合があります。加えて、PUTリクエストにX-Forwarded-Forヘッダが含まれていると拒否される仕様で、リバースプロキシ経由の悪用を防ぐようになっています。

AWSのドキュメントによれば、IMDSv2はPUTで取得したセッショントークンを後続のGETに必須とし、PUT応答のホップ制限はIPのTTLで既定で1です。コンテナサービスとの互換性のためにより大きなホップ制限が必要になる場合があると説明されています。X-Forwarded-Forヘッダを含むPUTは拒否されます。インスタンスをIMDSv2のみ受け付けるよう設定でき、その場合は古いIMDSv1の呼び出しが失敗します。

ただし、IMDSv2はあくまで多層防御の一枚です。クラウド固有の緩和策に頼り切るのではなく、アプリ側の許可リスト検証やネットワークの出口制御と組み合わせることが前提です。クラウドの責任共有や設定の考え方そのものも、SSRF対策の土台として理解しておくと判断がぶれません。

多層で守るための手順#

ここまでの対策を、実装で重ねる順序として整理します。

これらは「どれか一つを選ぶ」ものではなく「重ねる」ものです。アプリ側の許可リスト検証で宛先を絞り、ネットワーク側で出口を絞り、クラウド側でメタデータを守る。単一の防御に依存せず多層で守るのが、SSRFに対する確実な構えです。OWASP Top 10全体の中での位置づけや、他の脆弱性との関係を押さえておくと、対策の優先順位を判断しやすくなります。

まとめ#

SSRFは、仕組みさえ理解すれば「サーバーが宛先を確かめずにURLを取りに行く」という一点に集約されます。攻撃者の手元から届かない内部資産やクラウドメタデータに、サーバーを代理にして到達されるからこそ危険であり、防御は宛先の制御に尽きます。許可リスト方式で送信先を絞り、内部や予約アドレスを遮断し、DNSリバインディングやリダイレクトのすり抜けに備え、クラウドではIMDSv2でメタデータを守る。この多層構成を土台に据えることが、A10:2021に位置づくこの普遍的なWeb脆弱性への、最も実務的な答えになります。