2026.05.01 2026.05.02

【SSRF・LFI編】サーバを内側から覗かせる手口と守り方｜CTF思考フレームワーク #11

安全に生きたい編集部

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

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

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

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

難易度：★★★（上級）

SSRFとLFIは「サーバを内側から触る」攻撃。クラウド時代に最も恐ろしい脆弱性のひとつです🚨

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

この記事の難易度

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

Contents

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

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

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

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

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

クラウドの169.254.169.254(IMDS)に飛ばせちゃうと、IAM credentialsまで抜けるって聞いた…😱

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

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

攻撃者の仮説。

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

AWS/GCPの169.254.169.254に到達できるとIAMロール認証情報が引けて、そのままクラウド乗っ取りに繋がる。

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

SSRFで127.0.0.1や10.0.0.0/8のRedis/Elasticsearch/管理画面にアクセスし、認証なしのサービスを叩く。

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

../../../../etc/passwdのような相対パスで、サーバー上の任意ファイルを読む。設定ファイルやkeyファイルが標的。

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

PHPならphp://filterやlog injection、Pythonならimport任意ファイルで単なる読込が任意コード実行に化ける。

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

クラウドだとSSRF1つでアカウント全体が落ちることもあるんだね…💧

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

http://localhost、http://169.254.169.254、file:///etc/passwdを順に投げて挙動の差を観察！

検証ステップ。

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

⚔️ 攻撃フェーズ：実際の手口

SSRF/LFIの代表的な攻撃はこの3つ。

実戦シナリオ。

① クラウドメタデータ窃取

SSRFでhttp://169.254.169.254/latest/meta-data/iam/security-credentials/を叩き、IAM一時認証情報を入手。AWS全体を乗っ取る入り口に。

② 内部サービスの横取り

http://127.0.0.1:6379のようなRedisや管理画面に到達できれば、認証なしでデータ操作・コード実行。

③ LFI→RCEパイプライン

Apacheログに悪意ペイロードを書き込み、それを?file=/var/log/apache2/access.logでinclude→PHPコードとして実行。

CTF{ssrf_to_metadata_to_full_cloud_compromise}

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

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

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

防御の3点セット。

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

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

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

AWSならIMDSv2を強制(トークン必須)に。SSRFで単純GETしても認証情報が引けない構成へ。

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

ファイル名を受け取ったらrealpath()で正規化し、許可ディレクトリ配下か検証。..を含む入力は即拒否。

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

🛡️ 今日からできる対策ツール

パスワードの使い回しや手動管理はどんなに気をつけても限界があります。🔑 パスワード管理ツール「ワンパス」なら、複雑なパスワードを安全に保管して「1つのマスターパスワード」だけ覚えられるので、今日から始める防御策としてしっくりきます。

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

⚠️ よくある落とし穴

よくあるミス。

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

🧰 ツール早見表

使う道具。

ツール	用途	ひと言
Burp Collaborator / Interactsh	外部コールバック確認	SSRF検出の決定打
SSRFmap	SSRF自動エクスプロイト	メタデータ・Redis等のペイロード集
ffuf	パラメータ・パス総当たり	LFI候補のファジングに
CyberChef	スキーム変換・URLエンコード	ペイロード加工に便利