2026.05.01 2026.05.14

【SSTI編】テンプレートに混ざる悪意とRCEへの道｜CTF思考フレームワーク #14

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　Web脆弱性編　#11 / 公開中 10記事　→　シリーズ一覧を見る →

SSRF（サーバサイドリクエストフォージェリ）とLFI（ローカルファイルインクルード）は、「サーバ自身に内側を覗かせる」攻撃。クラウド時代になってから、SSRFは特にエグい威力を発揮するようになりました。AWSのメタデータエンドポイントから一発でクレデンシャル取れたCapital One事件、覚えてる人もいるはず🌩️

URLを引数に取る機能、ファイルパスを引数に取る機能。両方とも「サーバが代わりに何かを取りに行く」処理が裏にあります。そこが急所です。

SSRFはクラウドメタデータAPIを狙ってきて、たった1リクエストで認証情報を抜けることもあるんだ💀

この記事の難易度

難易度：★★★（上級）　／　所要：10〜12分　／　前提：CTF思考フレームワーク #10

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：CTFで見る典型パターン
🛡️ 防御フェーズ：どう守る？
🔑 あわせて見直したい基本対策
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
⚖️ 大事なお約束
📚 次に読みたい
🧪 自分で検証してみる

👀 観察フェーズ：まず何を見る？

まずアプリが外部URLを取りに行く処理がないか観察！プレビュー機能・Webhook・OGP取得などが要注意🔍

SSRFとLFIは「便利機能」とセット。プレビュー、変換、インポートのような「サーバが代わりに動く」機能が攻撃面です。

画像URL指定欄・PDF生成・URL短縮・Webhook URL設定はSSRFの温床。ファイル名指定欄(?file=...)はLFIの入り口です👀

クラウド環境では、サーバー自身からしか到達できないメタデータサービスが狙われることがある。そこに到達されるとインスタンスのロール認証情報が漏れる恐れがあるんだ…😱

🤔 仮説フェーズ：攻撃者は何を考える？

SSRF/LFI系の典型的な穴は4つ。

☁️ 仮説①：クラウドメタデータAPIへのSSRF

クラウド環境では、サーバーからしか届かないメタデータサービスが狙われます。到達できるとインスタンスに付与されたIAMロールの一時認証情報が漏れる恐れがあり、ロール権限が広すぎる場合は重要データへの横展開に繋がります。

🔁 仮説②：内部ネットワークへのピボット

外部から直接到達できないローカルホストや内部ネットワーク上のサービス（キャッシュ・DB・管理画面等）に対して、認証なしで動いているサービスを叩くパターン。

📁 仮説③：パストラバーサル・LFI

LFIは「アプリがローカルファイルをincludeする」文脈、パストラバーサルは「許可ディレクトリ外のファイルへアクセスする」文脈です。CTFでは両方がセットで出ることが多く、本記事では「サーバー上の想定外ファイルへアクセスされるリスク」として合わせて扱います。相対パスを使ったディレクトリ外への参照で、設定ファイルや認証情報が標的になります。

⚙️ 仮説④：LFI→RCEへの昇格

アプリが読み込むファイルを書き換えられる経路や特殊なスキームが許可されている場合、単純な読み込みが任意コード実行に化けるケースがあります。

SSRFは「サーバを踏み台」に内部ネットワークを覗く攻撃。クラウド環境では特に致命的です。

クラウドだとSSRF1つで、ロール権限の範囲にある重要データへアクセスされることもあるんだね…💧

🔬 検証フェーズ：どうやって確かめる？

CTFやローカル検証環境では、外部URL・ローカルホスト・内部ネットワーク・ローカルファイル指定などを入力したときの、エラー内容・応答時間・ステータスコードの違いを観察！

タイムアウトの長さやエラーメッセージの違いから「どこまで到達できたか」を逆算するんだね🧪

⚔️ 攻撃フェーズ：CTFで見る典型パターン

ここでは実サービスに対して試せる手順ではなく、CTFやローカル検証環境でよく出る「考え方」だけを整理するよ🧠

具体的な検証は、必ず自分のDocker環境・CTF問題・許可されたラボ内で行ってください。以下は「何を確認するか」という思考パターンです。

① クラウドメタデータ型

サーバーからしか見えないメタデータサービスへアクセスできないかを確認するパターン。インスタンスに付与されたIAMロールの一時認証情報へアクセスされる恐れがあり、権限設定が広すぎる場合はクラウド上の重要データへ横展開される入口になります。

② 内部サービス型

外部からは見えない社内API・管理画面・DB管理ポートへ到達できないかを確認するパターン。認証なしで動いている内部サービスが射程に入ります。

③ ローカルファイル参照型

ファイル名を受け取る機能で、許可されたディレクトリ外のファイルを読めないかを確認するパターン。設定ファイルや認証情報が標的になります。

④ LFIからの昇格型

アプリが読み込むファイル（ログ・一時ファイル等）を経由して挙動が変わらないかを見るパターン。単純な読み込みがコード実行に化けるケースがあります。

CTF{ssrf_to_metadata_to_full_cloud_compromise}

SSRFの怖さは「外部からは見えない内部資産」が射程に入ること。クラウドメタデータ、内部DB、社内サービス…全部対象になります。

🛡️ 防御フェーズ：どう守る？

SSRF/LFIは「許可リスト方式」で守るのが鉄則！🛡️

🔒 SSRF: URL検証は許可リスト方式

取得を許すホスト名・スキームを明示的にホワイトリスト化。http://とhttps://以外、プライベートIP帯・メタデータIPは全部弾く。

☁️ クラウドメタデータはIMDSv2必須

AWSならIMDSv2を強制(トークン必須)に。SSRFで単純GETしても認証情報が引けない構成へ。IMDSv2は重要ですが、それだけでSSRF対策が完了するわけではありません。IAMロールの最小権限設定、メタデータIPへの到達をネットワーク層で遮断する、外向き通信を制限するといった多層防御が必要です。

📁 LFI: パスは正規化＆ベースディレクトリ固定

ファイル名を直接パスとして受け取らず、IDや固定キーからサーバー側でファイルを引く設計が安全です。やむを得ずパスを扱う場合は、realpath()で正規化後に許可ディレクトリ配下か検証し、URLエンコード・二重エンコード・シンボリックリンク経由のトラバーサルも考慮します。

🌐 SSRF: リダイレクト後も再検証

最初のURLだけでなく、リダイレクト先のURL・IP・スキームも再検証します。外部URLから内部IPへリダイレクトされるパターン（DNS rebindingを含む）に注意。

🚧 SSRF: 外向き通信をネットワーク層で制限

アプリの入力検証だけに頼らず、ファイアウォール・プロキシ・VPC設計でも内部IPやメタデータサービスへの到達を防ぎます（OWASP推奨）。

クラウド時代のSSRFは「認証情報が漏れる入口」。本気で守ろう💪

🔑 あわせて見直したい基本対策

SSRF/LFIの直接対策ではありませんが、セキュリティ全体を見直す際に、パスワードの使い回しも同時に改善しておくと安心です。パスワード管理ツールを使って、サービスごとに異なるパスワードを管理しましょう。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

「http:// だけブロック」で安心。gopher:// や file:// は素通し。
URLのホスト部だけ見て、DNSが内部IPに解決される可能性を忘れる。
AWS/GCPでメタデータサービスのトークン保護を有効化していない。
LFI対策で「.. を除去」だけ実装。….// で復活する。
php://filter や data:// など特殊スキームを許可したまま。
PDF生成エンジン（wkhtmltopdf、Headless Chrome等）にURL/HTMLをそのまま渡す。

🧰 ツール早見表

ツール	用途	ひと言
Burp Collaborator / Interactsh	外部コールバック確認	CTF・許可された診断で到達確認に使う
OWASP SSRF Prevention Cheat Sheet	防御設計	まず読むべき防御資料（cheatsheetseries.owasp.org）
ffuf	パラメータ・パス調査	許可された範囲でのみ使用
CyberChef	スキーム変換・URLエンコード	ペイロード加工に便利