IT用語集 2024/12/22

SSRFとは？ 10分でわかりやすく解説

コラム

SSRF（Server-Side Request Forgery）は、サーバー側の通信機能を悪用し、攻撃者が指定した宛先へサーバー自身にリクエストを送らせる脆弱性です。被害は、内部ネットワークへの到達、クラウドのメタデータ取得、管理画面や内部APIへの不正アクセス、外部への踏み台化まで広がります。特に、URLを取り込む機能、画像プロキシ、API連携、Webhookの送信先設定があるアプリケーションでは、送信先の制御方法を先に確認したほうが判断しやすくなります。

発生しやすい機能：外部URL取得、ファイル取り込み、Webhook、外部サービス連携、サーバー側プロキシ
被害が広がりやすい条件：サーバーから内部ネットワークへ到達できる、クラウドのメタデータへアクセスできる、リダイレクト追従やDNS判定が甘い
優先して実施する対策：送信先の許可リスト化、DNS解決後のIPアドレス判定、リダイレクト制御、出口制御、ネットワーク分離

SSRFとは何か

SSRFは、ユーザー入力がサーバー側の送信先や送信条件に影響し、その結果として本来許可していない宛先へ通信してしまう状態です。ブラウザからは届かない内部宛ての通信でも、サーバーが代理で実行すると到達できることがあります。問題の中心は、サーバーが持つネットワーク到達性や認証済みの立場を、攻撃者が横取りできる点にあります。

SSRFの定義と成立条件

Webアプリケーションには、外部URLからのデータ取得、画像やPDFのプレビュー、通知送信、外部認証連携など、サーバーから外へ通信する機能が少なくありません。SSRFは、こうした機能で送信先を信頼できない入力から組み立てていると発生します。URL全体を入力させる場合だけでなく、ホスト名、ポート、パス、クエリ文字列の一部を入力で変えられる設計でも起こります。

SSRFとクロスサイトリクエストフォージェリの違い

SSRF	サーバーが外部または内部の宛先へ通信します。被害は内部API、管理画面、クラウドメタデータ、他サービスへの踏み台化に及びます。
クロスサイトリクエストフォージェリ	クロスサイトリクエストフォージェリは、利用者のブラウザを使って意図しない操作を行わせる脆弱性です。通信主体と影響範囲がSSRFとは異なります。

名称が似ていても、SSRFは「サーバーの通信権限」を悪用し、クロスサイトリクエストフォージェリは「利用者のセッション」を悪用します。対策も別物として整理します。

SSRFが起きやすい発生箇所

外部URLから画像、PDF、OGP情報などを取得して表示する機能
外部サービスのエンドポイントやWebhook先を登録できる機能
RSSやデータフィードをサーバー側で取り込む機能
認証連携や外部API呼び出しで接続先の一部を可変にしている機能
サーバー側でリダイレクトを追従し、最終到達先を再検証していない実装

攻撃の流れ

攻撃者が、サーバー側通信を発生させる機能を見つける
入力を使って内部宛て、管理系宛て、クラウドメタデータ宛てなどの送信先を指定する
アプリケーションが十分な検証をしないままサーバーから通信する
レスポンス本文、エラーメッセージ、応答時間、ステータス差分から到達可否や内部情報を推測する

レスポンス本文を画面へ返さない実装でも、応答時間や失敗内容の違いから内部到達を推測されることがあります。いわゆるブラインドSSRFの形でも危険性は残ります。

SSRFで起こる被害

SSRFの被害は、到達できる宛先と、その宛先が何を許可しているかで決まります。アプリケーションだけで閉じる話ではなく、サーバーの配置先、IAM設定、内部ネットワーク構成まで影響します。

典型的な被害シナリオ

内部APIへの到達	外部公開していない管理APIや運用APIへ到達し、情報取得や状態変更につながることがあります。
管理画面への到達	社内向け管理画面や監視画面へアクセスし、設定変更や情報取得の足掛かりになることがあります。
クラウドメタデータ取得	クラウド環境によっては、メタデータから一時認証情報や構成情報の取得につながるおそれがあります。
内部調査の足掛かり	ポートスキャンのように到達可否を調べ、内部構成の推測材料を集める用途に使われることがあります。
踏み台化	第三者サービスへのアクセスにサーバーを悪用され、外部攻撃や調査の中継点になることがあります。

クラウド環境で注意したい点

クラウドでは、サーバーからリンクローカルアドレスやメタデータサービスへ到達できるかどうかが被害の分かれ目になります。たとえばメタデータから認証情報が取れる構成だと、SSRFが単発の情報取得で終わらず、権限拡大や横展開へつながることがあります。アプリケーション側だけでなく、クラウドのメタデータ保護設定、最小権限のIAM設計、クラウドサービスの責任共有モデルを踏まえた役割分担まで確認します。

二次被害へつながる例

SSRF自体が直接マルウェアを実行するわけではありませんが、内部エンドポイントや認証情報の取得を経由して、別の侵害工程へ進むことがあります。たとえば、ジョブ実行APIや管理系コンソールへ届けば、設定改変や資源の不正利用へ進む余地が生まれます。クリプトジャッキングのような不正利用も、こうした二次被害の延長線上で起こり得ます。

SSRFが生まれる実装パターン

発生しやすい実装

ユーザーが指定したURLを、そのままHTTPクライアントへ渡している
ホスト名やパスを入力値で連結し、接続先を組み立てている
「httpで始まる」程度の形式チェックしかしていない
リダイレクトを自動追従し、最終到達先を検証していない
取得したレスポンス本文やエラー内容を、そのまま画面やログへ出している

ブラックリスト方式が破られやすい理由

内部IPや特定ホスト名だけを禁止するブラックリスト方式は、表記揺らぎやDNS解決の扱いで回避されやすくなります。10進、8進、16進、短縮表記、ホスト名経由、リダイレクト経由など、見た目では分からないすり抜け方があるためです。許可する宛先だけを明示する許可リスト方式のほうが、設計の前提を固定しやすくなります。

診断で確認する観点

入力点	URL、ホスト、ポート、Webhook先、画像取得先、外部連携先など、サーバーが通信する箇所を洗い出します。
実到達先	DNS解決後のIPアドレスを見て、プライベートIP、ループバック、リンクローカル、管理系セグメントへの到達可否を確認します。
リダイレクト	初期URLだけでなく、追従後の最終URLと最終IPアドレスまで再検証しているかを確認します。
返却情報	レスポンス本文、ステータスコード、エラーメッセージ、応答時間が内部情報の推測材料にならないかを確認します。
出口制御	サーバーからの外向き通信が必要最小限に絞られているかを確認します。

診断では、画面に表示される情報だけで判定しないほうが安全です。エラーハンドリングやタイムアウト差分だけでも内部到達の有無が読めることがあります。

SSRFへの対策

SSRF対策は、アプリケーション、実行環境、監視の三層で組み立てると抜けが減ります。アプリだけで抑え込もうとすると、見落とした機能追加や設定変更で再発しやすくなります。

アプリケーション設計で行う対策

送信先は固定を原則とし、可変にする場合は許可リストで絞る
スキーム、ホスト、ポート、パスの許容範囲を明示し、不要なプロトコルを拒否する
DNS解決後のIPアドレスに対して、プライベートIP、ループバック、リンクローカルを拒否する
リダイレクト追従を既定で無効にし、必要時だけ最終到達先を再検証する
取得したレスポンス本文や内部エラーをそのまま返さない

サーバー側で外部URLを取得する必要がある場合でも、ユーザー入力をそのまま送信先にしない設計へ寄せたほうが安全です。たとえば、利用者が選ぶのはIDだけにし、実際の接続先URLはサーバー側の安全な設定テーブルから引く、という構成にすると制御しやすくなります。

インフラ側で行う対策

出口制御	サーバーから接続できる宛先を業務上必要なIPアドレス、ドメイン、ポートに限定します。
ネットワーク分離	アプリケーションサーバーから管理セグメントや監視系へ直接届かない構成にします。
境界監視	ファイアウォール、WAF、IDSで不審な外向き通信や異常な入力を監視します。
多層防御	多層防御として、アプリが誤って通信してもネットワークで遮断できる状態を維持します。

クラウドとコンテナ環境で追加確認する項目

メタデータサービスへの到達制限や保護機構が有効か
インスタンスやワークロードに過剰な権限が付いていないか
サービスメッシュ、プロキシ、サイドカー経由の通信経路が想定どおりに制御されているか
名前解決や内部サービスディスカバリ経由で思わぬ宛先へ出ていかないか

検査と監視の継続運用

SSRFは、外部連携や取り込み機能を追加したときに再混入しやすい脆弱性です。設計レビュー、SAST、DAST、ログ監視を開発プロセスへ組み込み、変更のたびに同じ観点で確認します。特にWebhook、画像取得、プレビュー、連携エンドポイント変更は、レビュー項目を固定しておくと見落としが減ります。

まとめ

SSRFは、サーバー側の通信権限を攻撃者に利用される脆弱性です。被害は内部ネットワーク到達、クラウドメタデータ取得、管理画面へのアクセス、外部への踏み台化まで広がります。対策では、送信先の許可リスト化、DNS解決後のIPアドレス判定、リダイレクト制御、返却情報の最小化をアプリ側で実施し、出口制御とネットワーク分離をインフラ側で重ねます。便利機能の追加時に再発しやすいため、設計レビューと継続検査を運用へ組み込む前提で扱います。