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

UnsplashのKaur Kristjanが撮影した写真   

SSRF（Server-Side Request Forgery）は、Webアプリケーションが持つ「サーバー側から外部へ通信する機能」を悪用し、攻撃者の意図する宛先へリクエストを送らせる脆弱性です。内部ネットワークへの到達、クラウドのメタデータ情報の取得、社内向け管理画面の不正操作、外部サービスへの攻撃の踏み台など、影響は広範囲に及びます。この記事では、SSRFの仕組み・典型パターン・被害シナリオ・診断観点・実務的な対策を整理し、「どこが危ないのか」「どう塞ぐのか」を判断できる状態を目指します。

SSRFとは何か？

SSRFは、Server-Side Request Forgery（サーバーサイドリクエストフォージェリ）の略称で、攻撃者が細工した入力を通じて、サーバーに“本来想定していない宛先”へリクエストを送らせる攻撃（または脆弱性）を指します。ポイントは「被害がサーバー側で発生する」ことです。クライアント（ブラウザ）では到達できない内部宛て通信を、サーバーが代わりに実行してしまうことで問題が起こります。

SSRFの定義と概要

Webアプリケーションには、外部URLの取得、画像のプロキシ、Webhookの送信、SSOやAPI連携など、サーバー側からHTTPリクエストを送る機能が数多く存在します。SSRFは、この“送信先”や“送信条件”をユーザー入力でコントロールできてしまう状態から発生します。

SSRFの特徴は、次の3点に集約できます。

1. 攻撃者が指定した宛先へ、サーバーがリクエストを送ってしまう
2. 宛先はインターネット上だけでなく、内部ネットワークやローカル環境も含み得る
3. 到達後の挙動（情報取得・操作・踏み台化）は、サーバーのネットワーク権限に依存する

SSRFが起きる典型的な入口

SSRFは「URLを入力できる機能」だけの話ではありません。実務では、次のような機能が入口になりやすいです。

• 外部URLから画像やPDFを取得して表示する（画像プロキシ、OGP取得など）
• URLを指定して内容を取り込む（RSS/フィード、インポート機能）
• Webhookの送信先URLをユーザーが設定できる（通知、連携）
• SSO/外部API連携のエンドポイントが可変になっている
• サーバーサイドでリダイレクトを追従し、最終到達先を制御できてしまう

「ユーザー入力が宛先（ホスト/ポート/プロトコル）に影響するか」という観点で棚卸しすると、見落としが減ります。

SSRFの発生メカニズム

SSRFは、概ね次の流れで成立します。

1. 攻撃者が、サーバー側通信を発生させる機能（URL取得、プロキシ等）を見つける
2. 攻撃者が、内部宛てや管理系宛てなど“狙った宛先”を含む入力を与える
3. アプリケーションが入力を十分に検証せず、そのままサーバーからリクエストを送る
4. 攻撃者はレスポンス内容やエラーメッセージ、処理時間などから到達可否や情報を得る

根本原因は、「送信先を信頼できない入力で組み立てている」ことです。加えて、DNS解決、リダイレクト追従、IP表記の揺らぎ（10進/16進/8進、短縮表記など）を適切に扱えないと、対策しているつもりでもすり抜けられることがあります。

SSRFの影響範囲

SSRFの影響は「到達できる宛先」と「その宛先が何を許すか」で決まります。代表的な被害は次のとおりです。

• 内部ネットワークへの不正到達（社内向けAPI、管理画面、監視系、メッセージングなど）
• クラウド環境のメタデータ取得（インスタンス情報や一時クレデンシャル取得につながる場合がある）
• ポートスキャンの足がかり（到達可否や応答時間の差から内部構成を推測される）
• 外部サービスへの攻撃の踏み台（第三者への不正アクセスやDoSの中継）
• 機密情報の漏えい（レスポンスが画面に表示されたり、ログに残ったりする設計だと危険）

なお「SSRF＝必ず情報が抜かれる」ではありません。しかし、内部到達が成立すると、二次被害（認証回避、権限拡大、秘密情報の取得）に連鎖しやすいため、入口段階で止めることが重要です。

SSRFとクリプトジャッキングの関連性

クリプトジャッキングは、攻撃者が不正に計算資源を使って暗号資産のマイニング等を行う行為です。SSRFそのものが直接マイニングを実行するわけではありませんが、SSRFがあると「内部管理用のエンドポイントに到達してジョブを起動する」「クラウド権限情報の取得を足がかりに別の侵害へ進む」など、侵害の入口として利用される可能性があります。

つまり、SSRFを放置すると、単発の情報漏えいだけでなく、侵害後の不正利用（計算資源の悪用を含む）に発展する余地が生まれます。SSRFは“入口の穴”として評価し、早期に塞ぐべき脆弱性です。

SSRFの脆弱性について

SSRFは「Webアプリにありがちな便利機能」から生まれやすく、しかもネットワーク境界（内部/外部）をまたぐため影響が大きくなりがちです。ここでは、発生要因と実装パターン、診断の観点を具体化します。

SSRFが発生する要因

SSRFが発生しやすい要因は、次のように整理できます。

• 送信先の決定にユーザー入力を使っている（URL、ホスト名、ポート、スキームなど）
• 入力検証が形式チェック止まり（「httpで始まる」程度で許可してしまう）
• リダイレクト追従を無条件に許可（最終到達先が内部宛てに変わる）
• DNS解決やIP判定が不十分（プライベートIP・ループバック・リンクローカル等の扱い漏れ）
• 外向き通信が広く許可されている（サーバーの出口制御が弱い）

「アプリの入力検証」だけでなく「ネットワークの出口制御」まで含めて設計することが、SSRF対策では特に重要になります。

SSRFを引き起こすコーディングパターン

SSRFを招きやすい実装パターンには、次のようなものがあります。

1. ユーザーが指定したURLを、そのままサーバーサイドHTTPクライアントに渡す
2. ユーザー入力を結合してURLを生成する（ホスト部分やパス部分が可変）
3. 「ブラックリスト方式」で禁止ワードだけ弾く（表記揺らぎで回避されやすい）
4. リダイレクトを追従し、最終URLの検証をしていない
5. レスポンス本文をそのまま返す/表示する（内部情報が漏れる経路になる）

「URLを取得する機能」は分かりやすい入口ですが、Webhookや外部連携のように“設定画面で一度登録される”タイプも危険です。運用上は、登録後に悪用されるため気づきにくい点に注意が必要です。

SSRFの脆弱性診断方法

SSRF診断は、入力点の特定と「どこへ到達できるか」の確認が中心になります。代表的な観点を表にまとめます。

実務では、レスポンス本文が見えなくても「応答時間」や「ステータス差」「エラーメッセージの違い」から内部到達を推測されることがあります。表示の有無だけで安全と判断しないことが大切です。

SSRFの脆弱性を見つけるためのポイント

見つけるためのコツは、「サーバーが外へ出る理由」をアプリ内で探すことです。

• 外部URL取得、画像/ファイルの取り込み、プレビュー機能がないか
• Webhookや通知連携など、送信先を登録できる画面がないか
• SSO/連携先APIなど、環境ごとにエンドポイントが可変になっていないか
• リダイレクトやDNSの扱いが“ライブラリ任せ”になっていないか
• エラーハンドリングが詳しすぎないか（内部情報がにじむ）

「URL入力欄」だけを見て終わらず、連携・取り込み・通知の機能全体を対象にすることで、SSRFの見落としは大きく減ります。

SSRFへの対策

SSRF対策は、アプリケーション側の入力検証だけで完結しません。サーバーのネットワーク権限が強いほど被害が大きくなるため、「アプリ」「実行環境（ネットワーク/権限）」「運用（監視/検査）」の多層で考えるのが現実的です。

SSRFを防ぐためのセキュリティ設計

アプリケーション設計としては、次の原則が効果的です。

• 送信先は原則として固定し、可変が必要なら許可リスト（Allowlist）方式で限定する
• URL形式のチェックだけでなく、DNS解決後のIPに対してプライベート/ループバック/リンクローカル等を拒否する
• リダイレクト追従を制限し、追従する場合は“最終到達先”も再検証する
• HTTP以外のスキームや意図しないポートを拒否し、必要なプロトコル・ポートに限定する
• レスポンスをそのまま返さない、または返す情報を最小化し、内部情報が露出しないようにする

ブラックリストは回避されやすいため、「許可できるものを限定する」方が堅牢です。特にWebhookなどは、許可ドメイン・証明書・署名検証など、用途に応じた制約を設計段階で入れておくと安全性が上がります。

ファイアウォールなどのインフラによるSSRF対策

SSRFは“サーバーが送る通信”なので、インフラ側の制御が有効です。代表的には次の対策があります。

• 出口（Egress）制御：アプリサーバーから到達できる宛先（IP/ポート）を業務上必要な範囲に絞る
• 内部ネットワーク分離：アプリサーバーから管理系ネットワークへ直接到達できない設計にする
• WAF/IDSによる検知：不審なURLパターンや大量の外向き通信を監視し、早期発見につなげる
• クラウド環境の防御：メタデータ到達の抑止（環境に応じた推奨設定）や、最小権限のIAM設計を徹底する

アプリが万一すり抜けても、ネットワークで止めるという発想が、SSRFでは特に効きます。

SSRFの脆弱性検査の自動化

SSRFは実装変更や連携追加で混入しやすいため、検査を継続運用に組み込むことが重要です。主に次のアプローチが取られます。

SSRF対策は単発対応で終わりにせず、追加機能や連携のたびに“同じ穴”が開かないよう、開発プロセスに埋め込むのが現実的です。

まとめ

SSRFは、サーバー側通信機能を悪用し、攻撃者の意図した宛先へリクエストを送らせる脆弱性です。内部ネットワーク到達やクラウド環境での情報取得、踏み台化など、影響はサーバーのネットワーク権限に比例して大きくなります。対策の要点は、送信先の許可リスト化、DNS解決後のIP判定、リダイレクト制御、返却情報の最小化に加え、出口制御やネットワーク分離などインフラ側の多層防御を組み合わせることです。SSRFは“便利機能”に紛れて混入しやすいため、検査とレビューを継続運用に組み込み、設計段階から塞ぐことが求められます。

SSRFに関するよくある質問（FAQ）