SSRFの深淵：メタデータサービスを「鍵」に変える攻撃の解剖と、アーキテクチャレベルでの防衛論
SSRF（Server-Side Request Forgery）。この脆弱性を単なる「URLを入力させる機能の不備」と捉えているなら、あなたのクラウドインフラはすでに半分陥落していると言っても過言ではない。
私はこれまで数多のインシデントを見てきたが、SSRFほど「開発者の意図しない挙動」を「クラウド管理者の特権」へ昇華させる脅威は稀だ。今日は、AWSのIMDS（Instance Metadata Service）を標的とした攻撃シーケンスを低レイヤから掘り下げ、なぜ「単なるブラックリスト」が敗北するのか、その構造的な欠陥を解き明かす。
—
1. 攻撃の解剖：パケットから見える「信頼の連鎖」の崩壊
攻撃者がSSRFで狙うのは、単なる外部サイトの閲覧ではない。彼らは「ホスト環境の特権コンテキスト」を窃取しようとしている。
特にAWSのIMDSv1は、HTTPのリクエストパスさえ知っていれば、IAMロールの一時クレデンシャルを無防備に吐き出す。攻撃シーケンスはこうだ。
1. プロトコル・スワッピング: 攻撃者は攻撃対象のWebアプリに対し、`http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name` をリクエストさせる。
2. プロキシの悪用: アプリが内部的なプロキシやcurlライブラリを介してリクエストを投げると、OSレベルのネットワークスタックが動き出す。ここで、パケットの送信元IPは「信頼されたEC2インスタンス自身」となる。
3. 信頼の悪用: メタデータサービスは、リクエスト元がEC2インスタンス内部であることだけを確認し、無条件にJSON形式のアクセスキーとシークレットキーを返却する。
この時、パケット構造には攻撃者の痕跡はほとんど残らない。すべては「正当なアプリケーション」の振る舞いとしてログに記録されるからだ。
—
2. 「許可リスト」という幻想を打ち破る
多くの現場では、URLのバリデーションに正規表現を用いたブラックリストや、甘い許可リストを採用している。しかし、以下の手法でこれらは容易にバイパスされる。
- DNS Rebinding: ドメインのTTLを極端に短くし、初回解決時（バリデーション時）には安全なIPを返し、二回目（リクエスト時）に169.254.169.254を指すようにDNSを操作する。
- パーセントエンコーディングとURLの曖昧性: `169.254.169.254` を `0xa9.0xfe.0xa9.0xfe` や `http://[::ffff:a9fe:a9fe]` といった別の表記に変換し、フィルタをすり抜ける。
防御の第一線で戦うアーキテクトがやるべきは、「フィルタリング」ではなく「ネットワークの分離と認証」である。
—
3. アーキテクチャによる防衛：ゼロトラストの適用
今すぐ実装すべきは、IMDSv2への強制移行と、ネットワークレイヤでの制御だ。
A. IMDSv2の強制（セッション認証）
IMDSv2では、`PUT`リクエストによってセッショントークンを取得し、それをヘッダーに含めなければメタデータにアクセスできない。SSRF単体ではヘッダーの注入が困難なケースが多く、攻撃の難易度を劇的に引き上げる。
Terraformによる強制設定の例
resource “aws_instance” “web_server” {
metadata_options {
http_endpoint = “enabled”
# トークン必須化（IMDSv2）
http_tokens = “required”
# ホップ数を制限（SSRFからの攻撃経路を物理的に制限）
http_put_response_hop_limit = 1
}
}
B. ネットワークレベルのガードレイル
アプリケーションコードに依存せず、OSやコンテナのネットワーク名前空間で通信を遮断する。
iptablesによるメタデータアクセスの一括遮断
アプリケーションがメタデータにアクセスする必要がない場合、即座にドロップさせる
iptables -A OUTPUT -d 169.254.169.254 -j DROP
—
4. 次世代の脅威への備え：AIと暗号化
これからのSSRF攻撃は、生成AIのプロンプトインジェクションと組み合わされるだろう。AIエージェントが「外部APIの情報を取得せよ」という指示を受けた際、巧妙に細工されたURLを生成させられ、内部基盤を探索されるリスクがある。
これに対する防御は、「エージェントの実行環境の分離」だ。AIが外部通信を行う際は、必ずプロキシを介し、そのプロキシ自体がホワイトリストベースの厳格なドメイン制限と、通信内容のディープパケットインスペクション（DPI）を行うアーキテクチャが必要になる。
また、将来的な耐量子暗号（PQC）への移行期においても、認証基盤が脆弱であれば意味をなさない。通信そのものの暗号化（TLS 1.3）以上に、「誰がそのリクエストを投げたのか」というアイデンティティの検証を、リクエストの全経路で徹底することが、我々が守るべき最後の砦だ。
結びとして
SSRFは、コードの脆弱性という枠を超え、インフラの設計思想を問う試金石である。チェックリストを埋めるだけのセキュリティはもう終わった。自分の書いているコードが、どのレイヤの特権を握り得るのか。その想像力こそが、最高の盾になる。
次にコードをレビューする時は、`http`というキーワードの裏側に、どれほどの「悪意ある通信」を忍ばせられるか、攻撃者の視点でコードを眺めてみてほしい。
コメント