SSRFとは？
SSRF（Server-Side Request Forgery）とは、Webアプリケーションを騙して、攻撃者の代わりにサーバー側から内部ネットワークやクラウドサービスにアクセスさせる攻撃手法です。Webサイト・APIの弱点を悪用し、通常は外部からアクセスできない内部システムやクラウドのメタデータサービスに不正にアクセスします。画像取得やURL検証などの機能を悪用して、サーバーを「踏み台」として使い、ファイアウォールの内側にある機密情報を盗み出したり、内部サービスを攻撃したりすることが可能になります。
SSRFを簡単に言うと？
会社の受付に例えると、外部の人が「社長への伝言をお願いします」と受付に頼み、受付が善意で社長室に行って伝言を伝えるようなものです。しかし実は、その「伝言」は社長室の金庫の暗証番号を聞き出す内容で、受付が知らずに攻撃の手伝いをしてしまいます。SSRFも同じで、Webサーバーに「この画像を取ってきて」とお願いすると、サーバーが素直に内部ネットワークにアクセスして情報を取ってきてしまいます。外部の人は入れない社内（内部ネットワーク）に、受付（Webサーバー）を通じて間接的にアクセスできてしまう、信頼を悪用した巧妙な攻撃なのです。
SSRFで発生する被害は？
SSRFにより、内部ネットワークの機密情報流出、クラウド環境の認証情報窃取、内部サービスの破壊などの深刻な被害が発生します。Webサイト・APIの弱点を突かれることで、本来は強固に守られているはずの内部システムが外部から操作可能になり、企業の中枢システムが危険にさらされます。特にクラウド環境では、メタデータサービスから認証情報を盗まれると、クラウド環境全体が乗っ取られる可能性があります。
SSRFで発生する直接的被害
- 内部システムの情報漏洩
外部からアクセスできない社内データベースや管理画面にSSRF経由でアクセスされ、顧客情報、財務データ、ソースコードなどの機密情報が大量に流出する
- クラウド認証情報の窃取
AWS、Azure、GCPなどのメタデータサービスにアクセスされ、IAMロールの認証情報やAPIキーが盗まれて、クラウド環境全体が乗っ取られる
- 内部サービスの破壊・改ざん
ファイアウォールで保護された内部APIやデータベースに対して、削除や改ざんのリクエストを送信され、重要なデータが破壊される
SSRFで発生する間接的被害
- ネットワーク全体の侵害
SSRF経由で内部ネットワークをスキャンされ、脆弱なシステムが発見されて、そこから横展開されて企業ネットワーク全体が侵害される
- コンプライアンス違反と信頼失墜
内部システムから個人情報が漏洩し、データ保護規制違反で巨額の制裁金を科され、顧客からの信頼を完全に失う
- サービス妨害と可用性の低下
内部サービスに大量のリクエストを送信されてシステムがダウンし、業務が長時間停止して事業継続性が脅かされる
SSRFの対策方法
SSRFへの対策は、入力値の厳格な検証、ホワイトリスト方式の採用、ネットワークセグメンテーションが基本となります。Webサイト・APIの弱点を補強するために、内部IPアドレスへのアクセス禁止、URLスキーマの制限、DNSの検証が重要です。また、最小権限の原則に基づいたアクセス制御、メタデータサービスへのアクセス遮断、定期的なセキュリティ監査により、SSRFのリスクを大幅に低減できます。
SSRFの対策を簡単に言うと？
子供のお使いに例えると、まず「行っていい場所のリスト」（ホワイトリスト）を作り、それ以外の場所には絶対に行かせません。「隣の家に行って」と言われても、「それはリストにないからダメ」と断ります。また、お金を扱う場所（重要システム）には子供を一人で行かせず、必ず大人が同行します（アクセス制御）。さらに、お使いの内容を細かくチェックし（入力検証）、怪しい依頼は断る勇気を持ちます。家の中の大事な部屋（メタデータ）には鍵をかけて、たとえ家族でも勝手に入れないようにします。このように、「誰に」「何を」「どこまで」許可するかを明確にすることで、悪用を防ぐことができます。
SSRFに関連した攻撃手法
Webサイト・APIの弱点において、SSRFと密接に関連する3つの攻撃手法を解説します。
- XXE（XML External Entity）
SSRFと同様に、サーバー側でファイルや外部リソースにアクセスさせる攻撃です。XXEはXML処理の脆弱性を、SSRFはURL処理の脆弱性を悪用しますが、両者とも内部リソースへの不正アクセスという同じ目的を持ち、組み合わせて使われることもあります。
- オープンリダイレクト
SSRFの攻撃経路として悪用されることがあります。オープンリダイレクトの脆弱性を利用して内部URLにリダイレクトさせ、SSRFを成功させる連鎖攻撃が可能です。また、SSRFで取得した内部情報を外部に送信する際の経路としても使用されます。
- APIの不適切な認可（BOLA等）
SSRFと組み合わせることで、より深刻な被害をもたらします。SSRFで内部APIにアクセスした後、BOLAの脆弱性を悪用して他のユーザーのデータにアクセスするなど、複合的な攻撃により被害が拡大します。
SSRFのよくある質問
画像のURL取得、WebhookのURL設定、PDFジェネレーター、URLの存在確認、RSSフィード取得など、外部URLにアクセスする機能全般が危険です。特にユーザー入力をそのまま使用する場合は要注意です。
はい、非常に危険です。AWS（169.254.169.254）、Azure、GCPなどのメタデータサービスにアクセスされると、IAMロールの認証情報が盗まれ、クラウド環境全体が乗っ取られる可能性があります。
はい、必ず防ぐべきです。localhostには管理画面やデバッグ情報など、重要な内部サービスが動作していることが多く、SSRF攻撃の主要なターゲットとなります。
URLの検証は重要ですが、それだけでは不十分です。DNSリバインディング攻撃やリダイレクトを使った回避手法があるため、ネットワークレベルの対策も併用する必要があります。
内部IPアドレスへの異常なアクセス、メタデータエンドポイントへのリクエスト、通常とは異なるポートへの接続試行などをログで監視します。WAFやIDS/IPSの導入も効果的です。
更新履歴
- 初稿公開
