情報管理技術士 学習ノート
← 一覧へ
セキュリティ・個人情報
#SSRF#클라우드메타데이터#IMDSv2#egress통제#OWASP
最終更新 · 2026-10-14

SSRF(Server-Side Request Forgery、サーバサイドリクエストフォージェリ)

1. 概要

定義: SSRF(Server-Side Request Forgery)とは、攻撃者がサーバアプリケーションが外部リソースを取得する際に用いるURL・アドレスパラメータを改ざんし、信頼されたサーバに攻撃者の代わりにリクエストを送信させて、攻撃者が指定した内部ネットワーク・クラウドメタデータ・外部エンドポイントへ到達させる脆弱性である。すなわちサーバを攻撃者の「代理リクエスト機(プロキシ)」に転落させる攻撃である。

現代のアプリケーションは、外部URLを入力として受け取りサーバがそのリソースを取得する機能を広範に用いている。Webhookの登録、リモート画像のサムネイル生成、URLプレビュー、PDFレンダリング、外部API連携、ファイルインポートが代表的である。このときサーバは利用者が渡したURLをそのまま信頼してリクエストを実行するが、問題はそのサーバがファイアウォール内側の信頼されたネットワーク位置にあることである。外部攻撃者が直接到達できない内部管理ポート、データベース、クラウドメタデータサービスへ、サーバは何の制約もなくアクセスできる。SSRFはまさにこの「サーバのネットワーク信頼位置」を攻撃者が借用する構造的な弱点を悪用する。

この「サーバが利用者の代わりに外部リソースを取得する」パターンは特定の分野に限定されず、事実上あらゆる現代サービスに遍在する。SNSのリンクカードプレビュー、ショッピングモールの外部画像登録、コラボツールのファイルインポート、CI/CDパイプラインの外部アーティファクトダウンロード、チャットボット・エージェントの外部URL照会がいずれも潜在的なSSRF地点である。機能が便利であるほど「利用者が指定したアドレスへサーバが出ていく」という動作が増えるため、SSRFは機能拡張と攻撃面拡大が比例する典型的なセキュリティ-利便性の緊張関係を示す。したがってSSRFは「なくすべき機能」ではなく「安全に設計すべき機能パターン」として扱うべきである。

この脅威が急浮上した背景には、クラウド・マイクロサービスアーキテクチャの普及がある。オンプレミスの単一サーバ時代には内部リソースが少なかったが、クラウドではすべてのインスタンスが169.254.169.254というリンクローカルメタデータエンドポイントを通じて一時認証情報(IAMロールトークン)を照会できる。SSRF一件がそのままクラウド全体の権限奪取へ波及しうるようになったのである。その深刻さゆえに、OWASPは2021年改訂版でSSRFをA10:2021 — Server-Side Request Forgeryという独立項目として初めて分離した。これは従来「インジェクション」や「アクセス制御の不備」に埋もれていた脅威を、コミュニティ調査で1位に挙げた結果を反映したものである。技術士の観点では、SSRFの本質は単なる入力検証バグではなく、信頼境界・ネットワーク分割・最小権限にまたがるアーキテクチャ設計の欠陥として捉えるべきである。

SSRFが他のWeb脆弱性と区別される特徴は三つある。第一に、権限の非対称的悪用である。攻撃者は何の権限も持たないが、サーバは内部網で広範な権限を持つため、攻撃者は自らの無権限状態をサーバの高権限状態へ「増幅」させる。第二に、連鎖性(chaining)である。SSRF自体は「リクエストを代わりに送らせる」ことにすぎないが、その先にメタデータ・内部Redis・管理APIが置かれると、認証情報の窃取、リモートコード実行(RCE)、横展開へとつながる。第三に、検知の死角である。サーバが送る内部リクエストは正常トラフィックと区別しづらく、特にBlind型は応答がないためログだけで攻撃を識別しにくい。この三つの特徴ゆえに、SSRFは単独脆弱性のCVSSスコアよりも実際のインシデント波及がはるかに大きい「増幅型」の脅威と評価される。

2. 攻撃構造と脅威モデル

SSRFを理解する核心は「誰がリクエストを送るか」の転換である。一般的な攻撃は攻撃者の端末が直接標的へパケットを投げるが、SSRFでは正当な権限を持つサーバが攻撃者の代わりにリクエストを発射する。その結果、外部からは閉じている内部リソースがサーバの目には開いており、ファイアウォール・ネットワークACLは「サーバが送った内部通信」と認識して通過させる。

伝統的な境界セキュリティ(perimeter security)は「外部は危険、内部は安全」という前提の上に築かれている。SSRFはまさにこの前提を崩す。外部攻撃者の意図が内部から出発した信頼されたリクエストに化けるからである。このためSSRFの防御は境界ファイアウォールだけでは不可能であり、後述するゼロトラスト的な思考——「内部から来るリクエストも検証し最小権限で制限する」——と自然につながる。

flowchart LR
    ATK(("攻撃者")) -->|"改ざんされたURL入力"| APP["Webアプリケーションサーバ<br/>(信頼されたネットワーク位置)"]
    APP -->|"正常な外部リクエスト"| EXT["正常な外部リソース"]
    APP -.->|"悪用された内部リクエスト"| META["クラウドメタデータ<br/>169.254.169.254"]
    APP -.->|"悪用された内部リクエスト"| INT["内部サービス<br/>(DB·管理コンソール·キャッシュ)"]
    APP -.->|"プロトコル転換"| FILE["file:// gopher://<br/>内部プロトコル"]
    META -.->|"IAM一時認証情報"| APP
    FW["ファイアウォール / ACL"] -. "外部→内部を遮断" .-x ATK

上の構造図の核心は、ファイアウォールが攻撃者の直接アクセス(点線の遮断線)は防ぐが、サーバが内部へ送るリクエストは信頼して許可することである。攻撃者は入力欄にhttp://169.254.169.254/...のような内部アドレスを入れるだけでこの信頼を横取りする。すなわちSSRFの被害の大きさは「サーバが何を入力として受け取るか」ではなく「サーバが内部的に何に到達できるか」に比例する。したがって脅威モデリングでは、アプリケーションの送信(egress)権限と隣接する内部リソースの機微度をまず評価しなければならない。

第二に、SSRFは応答の返却有無によって性格が大きく分かれる。サーバが取得した内容を画面へ返す場合(In-band SSRF)、攻撃者は内部リソースの内容を直接読み取れる。一方、応答が返らなくても(Blind SSRF)、応答時間の差、エラーメッセージ、DNS照会の発生有無といったサイドチャネルで内部リソースの存在を推論したり、内部APIの状態変更(書き込み)リクエストを放ったりできる。次の詳細シーケンスは、クラウドメタデータを狙った典型的な攻撃フローである。

sequenceDiagram
    participant ATK as 攻撃者
    participant SRV as アプリケーションサーバ
    participant IMDS as メタデータサービス(IMDSv1)
    participant S3 as クラウドストレージ
    ATK->>SRV: "image_url=http://169.254.169.254/latest/meta-data/iam/..."
    SRV->>IMDS: サーバが代わりにGETリクエスト
    IMDS-->>SRV: IAMロール一時認証情報を返す
    SRV-->>ATK: 応答本文に認証情報が露出
    Note over ATK: 窃取した鍵で直接認証
    ATK->>S3: 有効な認証情報でアクセス
    S3-->>ATK: 機微データを流出

このフローで注目すべきは、攻撃成立地点がアプリケーション入力一箇所であるが、最終的な被害はまったく別のサービス(ストレージ)で不可逆的に発生することである。単一の脆弱性が権限昇格・横展開へ連鎖する点で、SSRFは「侵入口(entry point)」脆弱性に分類される。

脅威モデルを定量的に扱うには「サーバが到達できる内部リソースの集合」を攻撃面として明示しなければならない。たとえば一つのアプリケーションサーバが同一VPC内のマイクロサービス30個、メタデータエンドポイント、内部キャッシュ、ログ収集器に到達できるなら、SSRF成功時に攻撃者はその34個のリソース全体を潜在的な標的として得る。逆に送信トラフィックを専用プロキシ一箇所にのみまとめ、それ以外のegressを遮断すれば、同じSSRFが発生しても攻撃者が到達できるリソースは「プロキシが許可した宛先」へ縮小する。すなわちSSRFの実質的なリスクはコードではなくネットワークトポロジが決定するという点が脅威モデリングの出発点である。

3. 攻撃の類型

SSRFは応答返却の方式、標的、プロトコルによっていくつかの類型に分かれる。各類型は検知難度と対応戦略が異なるため、区分が重要である。

A. In-band(基本)SSRF。 サーバが取得した外部リソースの内容を応答にそのまま含めて返す場合である。攻撃者は内部ポートスキャン結果、設定ファイル、メタデータ認証情報を直接目で確認できるため、最も即時的で危険である。URLプレビューや画像プロキシ機能でよく発生する。

B. Blind(盲目)SSRF。 サーバはリクエストを実行するが結果を応答に返さない場合である。攻撃者は外部に自らが制御する収集サーバ(例:Burp Collaborator、DNSロギングドメイン)を置き、サーバがそのドメインを照会・接続するかどうかで脆弱性の存在を確認する。直接データを読むことはできないが、状態変更APIの呼び出しや内部網のマッピングに悪用されうる。

C. 半盲目(Semi-blind)SSRF。 応答本文はないが、HTTPステータスコード・応答時間・エラーメッセージといった間接的な信号で内部サービスの存在や応答を推論する類型である。ポートが開いているか否かを応答遅延で区別する内部ポートスキャンが代表的である。

D. プロトコル転換型SSRF。 攻撃者がhttpではなくfile://、gopher://、dict://、ftp://スキームへ転換し、ローカルファイル読み取りや平文プロトコルベースの内部サービス(Redis·Memcached·SMTP)を直接操作する類型である。特にgopher://は任意のバイトストリームを送れるため、認証のない内部Redisへ書き込みコマンドを注入するなど最も破壊的である。この類型は単なる情報露出を超えて内部サービスの状態を変えたり、条件が合えばリモートコード実行(RCE)まで至ったりしうるため、許可スキームを厳格に制限していないシステムでは致命的な結果を招く。

類型 応答返却 主な悪用 検知難度
In-band あり(本文) メタデータ·内部ファイルの直接読み取り 低
Blind なし 状態変更API·外部コールバック誘導 高
半盲目 一部(ステータス·時間) 内部ポートスキャン·存在推論 中
プロトコル転換 場合による Redis·SMTP操作、ファイル読み取り 中

この分類が実務で重要な理由は、類型ごとに検知・対応戦略が変わるからである。In-bandは応答本文に機微情報が載るため出力フィルタリングと応答最小化が第一の防御線であるが、Blind·半盲目はそもそもサーバが内部へリクエストを送れないようにするegress制御が唯一確実な対策である。プロトコル転換型は許可スキームをhttp/httpsのみに制限し、リクエストライブラリの非標準スキーム対応を無効化する別の措置が必要である。したがって侵入テスト・コードレビュー時には「この機能がどのSSRF類型に脆弱か」をまず分類したうえで、それに合った防御をマッピングするアプローチが効率的である。

4. 主要な攻撃標的と回避技法

SSRFの標的は「サーバは到達できるが外部からは到達できない」すべてのリソースである。第一は先に見たクラウドメタデータサービスである。AWS·GCP·Azureはいずれも169.254.169.254を用い、ここからインスタンスに付与されたIAMロールの一時認証情報を照会できる。第二は内部管理インターフェースで、外部に公開していない管理コンソール、Kubernetes APIサーバ、アクチュエータ(actuator)エンドポイント、サービスディスカバリなどが対象となる。第三は認証のない内部データストア(Redis·Elasticsearch·Memcached)で、平文プロトコルを用いる場合はプロトコル転換型SSRFに特に脆弱である。

防御側が単純な遮断だけでは防ぎにくい理由は、回避技法が多様だからである。攻撃者はhttp://127.0.0.1をhttp://127.1、8進・16進・整数表記(http://2130706433)、IPv6短縮(http://[::1])へ変形してブラックリストを回避する。また、攻撃者が制御するドメインのDNS応答を検証直後に内部IPへ変えるDNSリバインディング(DNS Rebinding)、正常な外部URLで検証を通過させた後に3xxリダイレクトで内部アドレスへ誘導する技法、URLパーサとリクエストライブラリが@·#·空白を異なって解釈するパーサ不一致(parser confusion)攻撃がある。このように「文字列レベルのブラックリスト」は根本対策になりえず、後述するネットワーク層の制御が必要である。

標的 代表アドレス/プロトコル 狙うもの
クラウドメタデータ 169.254.169.254 IAM一時認証情報
内部管理API 10.0.0.0/8, k8s API 権限昇格·構成の窃取
内部データストア redis://, gopher:// データ操作·RCE
ローカルファイル file:// 設定·秘密鍵の読み取り

たとえば金融系モバイルバックエンドで「プロフィール画像URL」入力をそのままサーバがダウンロードする機能があったなら、攻撃者はそのフィールドにメタデータアドレスを入れて数秒以内にクラウド認証情報を得られる。実際にこのパターンは後述の事例で大規模流出につながった。

別の産業適用例として、電子商取引プラットフォームの商品登録機能でサーバが「外部商品画像の取得」を実行する場合を挙げられる。攻撃者は数千件のダミー商品を登録しながら、各画像URLに内部IP帯域(http://10.0.0.1~10.0.255.254)を順次代入し、応答時間の差だけで内部網の生きているホストと開いたポートを地図化(mapping)できる。これはBlind SSRFを内部偵察(reconnaissance)ツールとして使う典型であり、外部スキャンでは見えなかった内部構造がアプリケーション一機能を通じて露出する点で危険である。バグバウンティのエコシステムでもSSRFはメタデータ認証情報の窃取につながりうるため、通常は高等級(High~Critical)で報奨される脆弱性類型に属する。

5. 比較 — SSRFとCSRF

名前の似たCSRF(Cross-Site Request Forgery)と混同しやすいが、両者は「偽造されたリクエストを誰が送るか」で本質的に異なる。CSRFは被害者(利用者)のブラウザが被害者の認証クッキーを載せて攻撃者が望むリクエストを送らせる攻撃で、クライアント側の信頼(セッション)を悪用する。一方SSRFはサーバ自体が攻撃者の代わりにリクエストを送るため、サーバのネットワーク位置と権限を悪用する。したがってCSRFの防御はCSRFトークン·SameSiteクッキーのように「リクエスト出所の検証」に集中するが、SSRFの防御は「サーバの送信先の制限」に集中する。この違いを理解しないと、見当違いの対策(例:SSRFにCSRFトークンを適用)を立ててしまう。

この違いが実務で重要な理由は、防御責任の所在が異なるからである。CSRFは主にアプリケーションフレームワーク層(トークンミドルウェア·クッキー属性)で解決される一方、SSRFはアプリケーション入力検証だけでは不完全であり、ネットワーク·インフラ層のegress制御が並行されて初めて根本的に遮断される。すなわちCSRFが開発チームの宿題であるなら、SSRFは開発·セキュリティ·インフラが共に責任を負う「交差領域」の脅威であるという点が、二つの攻撃の組織的な含意を分ける。

また被害の方向性も対比される。CSRFは被害者個人の権限範囲内で行為を盗用するため、被害が個別利用者アカウントのレベルにとどまる場合が多い。一方SSRFはサーバの権限を悪用してインフラ全般(認証情報·内部サービス)へ波及するため、単一利用者ではなくシステム·組織全体の機密性の崩壊につながりうる。まさにこの波及力の差が、OWASPがSSRFを独立項目へ昇格して扱うに至った核心的な理由である。

区分 SSRF CSRF
リクエスト主体 サーバ 被害者のブラウザ
悪用する信頼 サーバのネットワーク位置·権限 利用者セッション·クッキー
主な被害 内部リソースアクセス·認証情報の窃取 利用者権限の盗用行為
中核の防御 送信(egress)制御·allowlist CSRFトークン·SameSite

6. 深化 — 代表事例と防御アーキテクチャ

最も広く引用される事例は2019年のCapital Oneデータ流出である。公開された分析によれば、攻撃者は誤設定されたWAF(プロキシ)インスタンスを通じてEC2のメタデータサービス(当時IMDSv1)にアクセスし、インスタンスに付与されたIAMロールの一時認証情報を得てS3バケットの約1億件(米国約1億·カナダ約600万)規模の顧客情報へアクセスした。この事件でCapital Oneは2020年に米国通貨監督庁(OCC)から約8千万ドルの制裁金を科された。ただし一部の学術分析はこれをSSRFではなく開放型リバースプロキシの悪用とみなすため、「SSRFの代表事例として広く引用されるが、根本原因はプロキシ·権限構成の欠陥にある」とバランスよく記述するのが正確である。

この事件は防御アーキテクチャを根本的に変える契機となった。AWSは2019年11月にIMDSv2を導入したが、メタデータ照会の前にPUTリクエストでセッショントークンを先に発行し、以後のリクエストにカスタムヘッダ(X-aws-ec2-metadata-token)で載せるように変えた。単純なGETだけを投げる典型的なSSRFは、このPUT先行段階を実行できず遮断される。またメタデータ応答のネットワークホップ数制限(デフォルト1)を設け、コンテナ·プロキシを経たリクエストがメタデータに到達できないようにした。これは「アプリケーションのパッチ」ではなく「インフラのデフォルト値強化」で問題を解決した模範事例である。

他のクラウドも類似の緩和策を持つ。GCPとAzureはメタデータ照会時にそれぞれMetadata-Flavor: Google、Metadata: trueといったカスタムリクエストヘッダを必須で要求する。単純なURL置換型SSRFはこうしたヘッダを任意に付けにくく一部遮断されるが、攻撃者がヘッダまで制御できる場合(例:リクエストを丸ごと偽造できる高度化したSSRF)には回避が可能であるため、ヘッダ要求は補助的な制御にすぎず、根本対策であるegress遮断を代替しないという点を設計時に明確に認識しなければならない。このようにクラウドごとに詳細が異なるため、マルチクラウド環境では共通のegress制御ポリシーを中央から一貫して適用することが重要である。

実務の防御は単一の対策ではなく多層防御(defense-in-depth)として構成し、アプリケーション層とインフラ層を必ず並行する。主要な制御は次のとおりである。

  • allowlistベースの入力検証: ブラックリストは先に見た表記変形·エンコーディング回避で無力化されるため、許可されたドメイン·IP·スキーム(http/https)のみを通すallowlistで設計する。URLをパースした後に実際に接続するIPを解決(resolve)し、プライベート·リンクローカル帯域(RFC 1918の10/8·172.16/12·192.168/16、169.254.0.0/16)を明示的に拒否する。
  • ネットワーク層のegress制御(最も強力): アプリケーションの外部送信を専用フォワードプロキシにのみ送り、メタデータ·内部帯域への直接egressをファイアウォール·セキュリティグループ·NetworkPolicyで遮断する。この制御はコード回避技法と無関係に動作するため、根本対策に近い。
  • クラウドメタデータの強化: IMDSv2の強制、メタデータのホップ数制限(デフォルト1)、不要なインスタンスのメタデータ無効化で、認証情報照会の経路そのものを遮断する。
  • 最小権限(least privilege): IAMロール·サービスアカウントの権限を機能に必要な最小へ狭め、認証情報が窃取されても攻撃者が得る権限と被害範囲を制限する。
  • リダイレクト·DNSリバインディングへの備え: 外部リクエストの3xxリダイレクトの自動追跡をオフにするか再検証し、検証時点と接続時点でIPが異なるTOCTOU(リバインディング)を防ぐため、解決したIPを固定(pin)して接続する。
  • 応答の最小化: 取得した外部リソースの原文·エラーメッセージを利用者へそのまま露出せず、In-band流出と半盲目推論を減らす。

検知·対応の観点も設計に含めなければならない。SSRFはBlind型のように応答がないとログだけで識別しにくいため、「アプリケーションサーバが内部帯域·メタデータエンドポイントへ異常な送信を試みたイベント」をegressプロキシ·ファイアウォールのログから相関分析(correlation)し、SIEMで警報化することが効果的である。特に169.254.169.254へのアクセス試行は正常なアプリケーショントラフィックではほとんど発生しないため、高信頼の検知シグネチャとして活用できる。侵入テスト時には外部コールバック収集サーバを用いてBlind SSRFまで能動的に検証すべきである。

標準·フレームワークの面では、SSRFはCWE-918(Server-Side Request Forgery)に分類され、OWASPはテストガイドとチートシートを通じてallowlist·IP検証·スキーム制限などの具体的な点検項目を提示する。組織はこれらを自社のセキュアコーディング標準とコードレビューチェックリストに反映し、新規機能の設計段階の脅威モデリングで「外部URLをサーバが取得するか」を必須の質問とし、事後パッチではなく事前設計でリスクを制御することが望ましい。

7. 考慮事項および示唆(技術士の観点)

「一行の入力検証バグ」に縮小して見るとSSRFは何度も再発する一方、信頼境界とネットワークトポロジの問題へ格上げして見れば体系的に制御できる。技術士の観点では次の五つをバランスよく考慮しなければならない。

  • 適用戦略: SSRFは単一のコード修正ではなく信頼境界の再設計として取り組むべきである。外部URLをサーバが取得するすべての機能(Webhook·インポータ·プレビュー)を資産として識別し、各機能にallowlistと専用egressプロキシを適用する「セキュア by default」体系を樹立する。
  • トレードオフ: 厳格なallowlist·egress遮断はセキュリティを高めるが、正当な外部連携の柔軟性を下げる。逆に利便のために任意のURLを許可すると攻撃面が大きくなる。組織は機能ごとのリスク度に応じて「許可範囲対運用の俊敏性」の均衡点をポリシーとして明文化しなければならない。
  • 展望: サーバレス·コンテナ·サービスメッシュの普及で内部通信が指数関数的に増え、SSRFの攻撃面も大きくなる。クラウド提供者のメタデータデフォルト値の強化(IMDSv2の強制)に加え、ワークロードアイデンティティ(ワークロードごとの短命トークン)とゼロトラストベースの送信制御が標準になる見込みである。
  • 関連技術: SSRFの防御はゼロトラスト(ZTNA)、ネットワーク分割(マイクロセグメンテーション)、ワークロードアイデンティティ(SPIFFE/SPIRE)、クラウドセキュリティ態勢管理(CSPM)と緊密に連携する。特にegress制御はデータ流出防止(DLP)と共に設計するとき効果が最大化される。
  • ガバナンス: SSRFは開発·セキュリティ·インフラの責任が交差する領域であるため、SSDLC上の脅威モデリングとコードレビューチェックリストに「外部URL取得機能」の項目を常時含め、侵入テストのシナリオにBlind SSRFの検知を必ず入れるべきである。
  • サプライチェーン·サードパーティの考慮: 直接記述したコードだけでなく、画像処理ライブラリ、PDF生成器、文書変換器、ヘッドレスブラウザといったサードパーティコンポーネントも内部的にURLを取得すればSSRF経路となりうる。したがって依存関係インベントリ(SBOM)に「外部リクエストを実行するコンポーネント」を識別し、これらもegress制御の対象の中に置くべきである。
  • 測定と改善: SSRF対応の成熟度は「allowlist適用機能の比率」「egress遮断のカバレッジ」「IMDSv2強制率」といった定量指標で管理し、レッドチーム訓練の結果をフィードバックして継続的に制御を補強するPDCA体系を備えることが望ましい。

参考資料

一言まとめ: SSRFは信頼されたサーバを攻撃者の代理リクエスト機にして内部網·クラウドメタデータへ到達させるアーキテクチャの欠陥であり、ブラックリストではなくallowlist·egress制御·最小権限·IMDSv2のような多層·インフラデフォルトの防御で対応すべきである。