【保護機構と回避編】Canary・PIE・ASLR・RELROの戦い方｜CTF思考フレームワーク #65
安全に生きたい編集部
安全に生きたい
【SSRF編】サーバに意図しない接続をさせる攻撃と守り方｜CTF思考フレームワーク #28
安全に生きたい編集部
URLを入力して画像を取得する機能が、なぜサーバ侵入につながるの？
利用者の代わりにサーバが通信する機能だから、接続先の制限が甘いと内部向けの場所まで読みに行かされるんだ。
SSRF（Server-Side Request Forgery）は、URL取得やWebhook、プレビュー生成など、サーバーが別の場所へ通信する機能で起きる問題です。
攻撃者はサーバー自身の到達権限を利用して、外部から直接見えない内部サービスやクラウドメタデータへ到達させようとします。
📚 CTF思考フレームワーク シリーズ
#28 【SSRF編】サーバに意図しない接続をさせる攻撃と守り方 ／ 全86記事。全シリーズ記事はこちら。
この記事の難易度
難易度：中級 ／ 読了目安：10分 ／ 学習順：#28
この記事で分かること
- SSRFが発生しやすい機能を見分ける
- 外向きURL取得が内部アクセスへ変わる理由を理解する
- 接続先制限とネットワーク側の防御を知る
この記事で出てくる言葉
- SSRF：サーバーに意図しない宛先へリクエストを送らせる脆弱性です。
- メタデータサービス：クラウド環境がインスタンスへ情報を提供する内部サービスです。
- Egress制御：サーバーから外へ出る通信を制限する考え方です。
Contents
🔍 観察フェーズ：まず何を見る？
最初から攻撃方法を探すのではなく、どの機能や設定が外から見えているかを整理するところから始めるよ。
いきなり試すんじゃなくて、まず「どこが入口になり得るか」を整理するんだね。
💡 仮説フェーズ：なぜ危険になり得る？
観察した内容から、被害につながる条件を仮説として並べるよ。
仮説1
サーバーは利用者のブラウザより広いネットワークへ到達できる場合があります。
仮説2
「最初のURLだけ確認」しても、リダイレクト先や名前解決後の宛先が変われば制限を回避されることがあります。
仮説3
内部サービスが認証なしでサーバーを信頼していると、SSRFの影響が大きくなります。
🔬 検証フェーズ：安全に確かめる
検証の目的は、実在サービスを攻撃することではなく、自分のラボで仕組みと防御の効き方を理解することだよ。
CTFや自作ラボで、URL取得機能がどの宛先への通信を許しているかを観察します。実運用のクラウド環境や第三者サービスへの接続試行は行わないでください。
許可された環境で、結果だけじゃなく「なぜそうなったか」まで確認するんだね。
⚔️ 攻撃フェーズ：成立すると何が起きる？
ここでは実サービスへの手順ではなく、成立した場合の影響を押さえよう。
影響1
攻撃者にとって利用価値のある入口や情報が増え、次の侵害につながる可能性があります。
影響2
設定や権限の範囲によっては、情報漏えい・改ざん・業務停止などへ影響が広がります。
影響3
検知や記録が不足していると、侵害の発見や原因調査が遅れます。
🛡️ 防御フェーズ：守る側はどうするか
守りは「気をつける」では終わらせず、設定・実装・監視に落とし込もう。
対策1
許可する宛先・スキームを必要最小限に絞り、名前解決後とリダイレクト後も検査する
対策2
サーバーの外向き通信を制限し、内部管理サービスを認証なしで公開しない
対策3
クラウドメタデータ保護機構と最小権限の資格情報を使う
🤝 大事なお約束
必ず守ってね
この記事で扱う確認・検証は、自分の環境、CTF、または明示的に許可された演習環境だけで行ってください。他人のサービスや端末に無断で試す行為は、不正アクセス等に該当するおそれがあります。学んだ知識は守る側で活用しましょう。
📝 まとめ
SSRFの本質は「サーバーが持つ接続権限を借りられる」ことです。入力チェックだけでなく、ネットワークと権限の両面で被害を限定します。
