ssrf・とは？初心者にもわかる基本と対策共起語・同意語・対義語も併せて解説！

この記事を書いた人

高岡智則

年齢：33歳性別：男性職業：Webディレクター（兼ライティング・SNS運用担当）居住地：東京都杉並区・永福町の1LDKマンション出身地：神奈川県川崎市身長：176cm 体系：細身〜普通（最近ちょっとお腹が気になる）血液型：A型誕生日：1992年11月20日最終学歴：明治大学・情報コミュニケーション学部卒通勤：京王井の頭線で渋谷まで（通勤20分）家族構成：一人暮らし、実家には両親と2歳下の妹恋愛事情：独身。彼女は2年いない（本人は「忙しいだけ」と言い張る）

ssrf・とは？

SSRFは Server-Side Request Forgery の略です。日本語にすると「サーバーサイドの不正なリクエストを作らせる脆弱性」として説明されます。ウェブアプリが利用者から受け取った URL をサーバー自身で取得してしまうと、外部のリソースだけでなく内部ネットワークの資源にもアクセスさせてしまう危険があります。

基本的な仕組みを押さえよう

仕組みは単純です。ユーザーが入力した URL をサーバーがそのまま使って外部へリクエストを送信します。例えば「この画像を取得して表示してね」といった機能が、受け取った URL に基づいてサーバー自身がリクエストを出します。

どんな場面で危険が起きるのか

攻撃が成立するのは主に バックエンドでのリクエスト処理機能 がある場面です。通常は外部のサイトの情報を集めるために使われる機能ですが、不適切な入力検証があると内部資源やクラウドのメタデータサービスなどに到達してしまう可能性があります。

危険な影響のイメージ

内部システムへのアクセス、機密情報の取得、クラウドメタデータの読み出し、認証情報の暴露などが起こりえます。結果として、サービス停止や機密データの漏えいにつながることがあります。

対策の基本方針

1) 入力の検証とホワイトリストを徹底します。受け取る URL の形式を厳しく制限し、許可されたドメインだけを受け付けるようにします。

2) 内部アクセスの遮断を優先します。サーバーが社内リソースやメタデータサービスなど内部アドレスへ出荷する経路を塞ぎます。

3) 出力制御とリダイレクト対策として、外部へリダイレクトを追いすぎない、渡された URL が他の内部リソースへ移動しないよう制御します。

4) ネットワークと権限の分離を行います。サーバーが外部へアクセスする権限を必要最小限にし、必要なアクセス先だけを許可する設計にします。

具体的な実装の例としては次のような対策が挙げられます。

・リクエストのタイムアウトを短く設定する

・DNS リバインディング対策を講じる

・外部へ出す前に URL の正規化を行い https のみを許可する

・クラウド環境ではメタデータサービスへのアクセスを禁止または厳しく制限する

脆弱性のパターンと表形式の対策

脆弱性の典型例	対策
ユーザー入力をそのままサーバーがURLとして取得するケース	入力検証とホワイトリストの適用、代替処理の導入
サーバーが自動的にリダイレクトをたどるケース	リダイレクトのフォローを制限、停止
内部IPアドレスや Private DNS へのアクセスを許すケース	内部アドレスの拒否、出力先の制限

学習ポイントと実践のヒント

SSRF を防ぐうえでの基本は 入力の検証とネットワークの分離 です。開発時には「この URL が本当に外部の公開資源だけを指すのか」を常に意識し、内部ネットワークを想定したテストを組み込みましょう。

クラウド環境の特有の注意

クラウド環境ではインスタンスのメタデータサービスにアクセスできる場合があり、誤って認証情報が露出するリスクがあります。したがってクラウドのメタデータエンドポイントへのアクセスを禁止または強く制御することが重要です。

まとめと開発者へのメッセージ

SSRF は「サーバーが自分自身の権限で別の場所へリクエストを送る」ことで内部資源の情報やサービスへ影響を及ぼす脆弱性です。対策の基本は入力検証とネットワークの分離、そして外部とのやり取りを必要最小限に限定する設計です。開発者はこの脆弱性を想定したテストを組み込み、第三者のセキュリティ診断を受けることをおすすめします。

ssrfの同意語

SSRF: サーバーサイドで別の内部/外部リソースへ不正なリクエストを発生させる脆弱性・攻撃手法。
サーバーサイドリクエストフォージェリ: サーバーが代理で他のリソースへアクセスさせることを狙う脆弱性・攻撃。
サーバーサイド・リクエスト・フォージェリ: サーバーが代理で他のリソースへアクセスさせることを狙う脆弱性・攻撃の表記ゆれ。
SSRF攻撃: SSRFを用いて内部資源や外部資源へ不正リクエストを送る攻撃そのもの。
SSRF脆弱性: この脆弱性が存在する状態を指す表現。
Server-Side Request Forgery: 英語表現。意味はSSRFと同じ。
サーバー経由リクエスト不正: サーバーを経由して他のリソースへ不正にリクエストを送る行為を指す説明表現。
内部リソース不正参照: 内部のリソースへ不正にアクセス・参照する行為を説明する表現。

ssrfの対義語・反対語

SSRF対策済み: サーバーの外部リクエスト先を検査・制限する対策が実装され、SSRFの脆弱性が生じにくい状態。
SSRF防止設計: 設計自体にSSR Fを起こさせない方針と仕組みを組み込んだ状態。
外部リクエスト抑制設計: サーバーからの外部宛リクエストを抑制する設計で、不要な外部接続を防ぐ。
ホワイトリスト制御: 許可された外部宛先のみリクエスト可能とする防御手法。
リクエスト検証徹底: 送信前に必ず検証を行い、悪意ある宛先を排除する。
クライアントサイド完結設計: 外部リクエストをサーバー側で行わず、クライアント側で完結させる設計。
内部資源分離設計: 内部資源へのアクセスを分離し、外部からの影響を受けにくくする設計。
最小権限化の内部アクセス: 内部リソースへアクセスする権限を最小限に抑え、不要な内部接続を防ぐ。
ACL適用: アクセス制御リストを適用して許可・拒否の境界を明確にする。
ゲートウェイ監視付き外部通信: 外部通信はゲートウェイを経由して監視・制御される設計。
内部ネットワーク分離: 内部と外部のネットワークを分離して影響範囲を限定する。
サーバーリクエスト不要設計: サーバーが外部へ自発的にリクエストを出さない設計を目指す。

ssrfの共起語

SSRF: サーバーサイドリクエストフォージェリの略。攻撃者がサーバー側から任意のURLへリクエストを送らせる脆弱性の総称。
内部ネットワーク: 外部から直接アクセスできない社内ネットワークや機密セグメント。SSRFでこの領域のリソースへアクセスされるリスクがある。
外部URL: 外部に存在するウェブサービスのURL。SSRFの対象となり得る宛先。
ターゲットURL: 攻撃者がSSRFでリクエストを送信する宛先のURL。
プロキシ: リクエストを別のサーバへ中継する仕組み。SSRFではプロキシ経由で内部リソースへ到達するケースがある。
メタデータサーバ: クラウド環境で実行中のインスタンス情報を提供するサーバ。機密情報の取得元になることがある。
インスタンスメタデータサービス: クラウド上の仮想マシンが提供するメタデータサービス。SSRFの目的で参照されることがある。
IMDS: Instance Metadata Service の略。クラウド環境のメタデータ取得機能。
URLリクエスト: URLを指定して行うHTTPリクエストのこと。SSRFの基本動作として頻出。
HTTPリクエスト: HTTPプロトコルに基づくリクエスト。SSRFではこの形式のリクエストが送られることが多い。
リモートリソース: 外部のサーバーやサービス上のデータ・リソース。SSRFの対象となる対象物。
脆弱性: ソフトウェアの欠陥・弱点。SSRFはその一種として認識される。
脆弱性診断: 脆弱性を検出・評価する作業。SSRFを含むセキュリティ評価の重要要素。
セキュリティ対策: SSRFを防ぐための設計・実装上の対策全般。
入力検証: 入力データを検証して不正なリクエストを防ぐ防御手段。
入力サニタイズ: 入力データを安全な形に変換・無害化する処理。
許可リスト: 許可されたURLやリソースのみを許可する安全設計の考え方。
ホワイトリスト: 許可リストの別名。安全とみなすリソースのみを許可する考え方。
拒否リスト: 禁止するURLやリソースを列挙する手法。
ブラックリスト: 禁止リストの別名。危険なリソースを除外する考え方。
アクセス制御: 誰が何にアクセスできるかを決定する仕組み。
ファイアウォール: ネットワーク境界を守る防御機構。宛先制御の一環として使われることが多い。
WAF: Webアプリケーションファイアウォール。ウェブアプリの攻撃を検知・防御する防御機構。
ログ: 発生したイベントを記録するデータ。後からの解析・監査に役立つ。
監視: 異常を継続的に観測・検知する運用活動。
検出: 攻撃の兆候を特定して通知・対応を行う能力。
影響範囲: SSRFが及ぶ可能性のある領域や資産の範囲。
リスク: 潜在的な被害の大きさと発生可能性を合わせた評価。
CVE: Common Vulnerabilities and Exposures の識別番号。公開脆弱性の標準識別子。
OWASP: オープンウェブアプリケーションセキュリティプロジェクト。脆弱性情報やベストプラクティスを提供。
クラウド環境: クラウド上で動作する環境。SSRFは特にクラウド内の内部リソースで深刻化しやすい。
ペイロード: 攻撃時に使用される特定の文字列・コード片。概念としての説明に留めることが多い。
設定ミス: 設定の誤りによってSSRFリスクが高まる要因。例として不適切なURL許可設定など。
データ漏えい: 機密情報が外部へ漏れること。SSRFの重大な潜在影響の一つ。
内部サービス: 内部ネットワーク上にあるサービス。SSRFにより直接アクセスされる可能性がある対象。
DNS: ドメイン名解決の仕組み。URL解決やリソース探索の要素として関与することがある。
DNSリゾルバ: DNSクエリを解決する役割を持つ仕組み。SSRFの挙動と関連する場合がある。

ssrfの関連用語

SSRF（Server-Side Request Forgery）: サーバー側の処理で、ユーザーが入力した値を使ってサーバー自身が別のURLへリクエストを送る脆弱性。内部資源への横展開や外部資源の取得を悪用される可能性がある。
ブラインドSSRF: レスポンスを直接確認できない状況でも、内部資源へのアクセスや外部資源の取得を検知・悪用される脆弱性の一種。
内部資源: ファイアウォール内やプライベートネットワーク内の資源。SSRFにより内部ネットワークへアクセスされるリスクの対象。
外部資源: インターネット上のURLやリソース。SSRFでサーバーが外部へ不正なリクエストを送る対象となる。
クラウドインスタンスメタデータサービス（IMDS）: クラウド環境の仮想マシンが自身の設定情報を取得できる内部エンドポイント。SSRFの典型的なターゲットとなる。
IMDSv1とIMDSv2: IMDSの古い認証方式（IMDSv1）と、トークンベースの新方式（IMDSv2）の違い。対策の観点で重要。
アウトバウンドリクエスト: サーバーが外部へ送るリクエスト。SSRFの影響範囲を広げる可能性がある。
プロキシ経由のリクエスト: サーバーがプロキシを介して資源へアクセスするケース。内部資源への抜け道として悪用される可能性がある。
Out-of-Band SSRF（OOB-SSRF）: 攻撃者が直接レスポンスを確認できない場合でも、DNSログや外部サービスの挙動で検知・情報取得を狙う手法。
ホワイトリスト検証（Allowlist Validation）: 許可されたURLのみを呼び出せるよう厳密に検証する対策。SSRF対策の基本形。
ブラックリスト検証（Blocklist Validation）: 禁止リストで弾く対策だが、網羅性の不足から脆弱性が残る可能性がある。補助的に使われることが多い。
入力検証・サニタイズ: ユーザー入力をそのままURLなどに渡さず、検証・正規化を行う基本的なセキュリティ手法。
スキーム制限（URLスキームの制限）: 許可するURLスキームを限定して、http/httpsなど安全なプロトコルのみを受け付ける対策。
URL正規化・検証: URLを統一的な形式に揃え、悪意のある形態の入力を除外する手法。
ネットワーク分離・セグメンテーション: 内部資源と外部資源の境界を明確にし、SSRFの影響を局所化する設計思想。
アウトバウンド通信の制御（egressフィルタリング）: 組織のポリシーに沿って外部通信先を制限し、不要なリクエストを遮断する対策。