SSRF（Server-Side Request Forgery、サーバサイドリクエストフォージェリ）は、Webアプリケーションが「ユーザーから渡されたURLにサーバ側からアクセスする」処理を持つときに、そのURLを攻撃者が操作し、本来外部からは届かないはずの内部ネットワークやクラウドメタデータエンドポイントへサーバ自身に代理アクセスさせてしまう脆弱性です。2019年に発生した米Capital One事件でAWSメタデータエンドポイントが悪用され、約1億件の個人情報が漏洩したことで一気に注目を集め、OWASP Top 10の2021年版にも独立カテゴリ（A10）として追加されました。クラウド時代を象徴する脆弱性として、現代のセキュリティ設計に欠かせない論点になっています。
この記事の目次
- サーバが代理アクセスする隙
- Capital One事件と続く事例
- URL検証とネットワーク分離
- CSRF・LFI・RFIとの違い
- まとめ
サーバが代理アクセスする隙
SSRFの土台は、サーバが利用者から渡されたURLに対して何らかのアクセスを行う機能の存在です。「URLを入れるとそのページのプレビュー画像を出す」「外部画像URLをアップロードできる」「OAuth・WebhookのコールバックURLを登録する」「PDF生成や画像縮小をURLから行う」など、現代のWebアプリには無数のSSRF入口があります。攻撃者は、外向きURLの代わりに「http://127.0.0.1:6379/」「http://localhost/admin」「http://169.254.169.254/latest/meta-data/」のような内部向けURLを送り込み、サーバを踏み台にします。
クラウド環境では、AWS・GCP・Azureが提供する「インスタンスメタデータサービス（169.254.169.254）」が攻撃の主目的となります。ここにはインスタンスに割り当てられた一時的なクラウド資格情報（アクセスキー・シークレット・セッショントークン）が返ってくるため、SSRFでこのエンドポイントへ到達できると、攻撃者はそのサーバが持つクラウド権限を丸ごと窃取できます。またRedis、Elasticsearch、内部管理画面、社内DNS解決などへの到達も典型的な悪用シナリオで、「外からは届かないが社内からは届く」資源すべてが射程に入ってしまうのが恐ろしい点です。
Capital One事件と続く事例
SSRFが世界の注目を浴びる転換点となったのが、2019年に発覚した米Capital Oneの大規模情報漏洩事件です。元AWS従業員のPaige A. Thompson被告が、Capital OneのWAF設定に存在したSSRF的弱点を悪用し、AWSのインスタンスメタデータエンドポイントにアクセスしてEC2インスタンスのIAM資格情報を窃取しました。そのうえでS3バケットから1億件以上の個人情報・クレジット申込データを取得し、米国とカナダを揺るがす事件となりました。AWSはこの事件を機に新メタデータプロトコルIMDSv2の利用を強く推奨するようになりました。
Capital One事件以降もShopify、GitLab、Twitter（X）、Vimeoなどの大手サービスでSSRF脆弱性の修正報告が相次ぎ、バグバウンティの世界では「SSRFは高単価脆弱性の代表」という認知が確立しました。OWASP Top 10は2021年版でA10としてSSRFを独立カテゴリ化し、クラウド利用を前提とした現代Webアプリの主要リスクとして正式に位置付けました。URLを入力に取る全ての機能が攻撃面になり得る、というのが現代のセキュリティ設計の前提です。
URL検証とネットワーク分離
SSRF対策の基本は「アプリ層」と「ネットワーク層」の二段防御です。アプリ層では、利用者から受け取ったURLについて、スキーム・ホスト・ポート・パスを厳格に検証し、RFC1918のプライベートIPアドレス帯、169.254.0.0/16、127.0.0.0/8、IPv6のリンクローカルなどを明示的に拒否します。またDNS再解決の隙を狙うDNS Rebindingに備え、解決済みIPを使って実際の接続を行う実装にしておくことが重要です。URLが許可されたドメイン・パスの組み合わせに合致するかを、allowlist方式で最小化するのが王道です。
ネットワーク層では、外向きアクセスを専用Egressプロキシ経由に絞り、内部VPC内・クラウドメタデータ・他テナントへの直接到達を遮断します。AWSではIMDSv2を必須化することで、SSRF経由のメタデータ取得を大幅に難しくできます。他クラウドでも同様にメタデータエンドポイントのトークン認証や経路制限を有効化することが推奨されます。アプリは「URLに対する代理アクセス権を最小限しか持たない」、ネットワークは「危険な宛先には届かない」、という二重の壁を併用することで、SSRFの被害範囲を実用上ほぼゼロに近づけられます。
CSRF・LFI・RFIとの違い
SSRFと名前が似ているCSRFは別物です。CSRFはブラウザを介した攻撃で「被害者のブラウザに偽リクエストを送らせる」のに対し、SSRFは「サーバそのものに代理リクエストを送らせる」ものです。ブラウザではなくサーバが踏み台になるため、被害が及ぶ範囲がインターネット越しの利用者ではなく、サーバから見える内部ネットワーク全体になります。クラウド資格情報の窃取に直結し得る点で、影響が桁違いに大きい傾向があります。
LFI（Local File Inclusion）はサーバ上のローカルファイルを読み込む脆弱性、RFI（Remote File Inclusion）はリモートのコードをサーバに実行させる脆弱性で、いずれもPHPのinclude/requireやテンプレートに対するパス操作を起点にします。SSRFと同じく「サーバ側にやらせる」攻撃ですが、SSRFが任意の宛先へのネットワークアクセスを誘発するのに対し、LFI/RFIはファイル取り込みや実行に集中している点が異なります。Open Redirectは「ユーザーを別ドメインへリダイレクトさせる」軽めの脆弱性ですが、SSRFと組み合わさると悪用範囲が広がります。
まとめ
SSRFはクラウド時代に注目度が急上昇した重大脆弱性で、Capital One事件が決定打となりました。URLのallowlist検証、プライベートIPと内部メタデータ宛の拒否、Egressプロキシ経由化、IMDSv2の強制を組み合わせれば、サーバを踏み台にした内部侵入は実用的にほぼ抑え込めます。「URLを受け取る機能は全部SSRF入口候補」という意識を、設計初期から徹底することが鍵です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント