SSRFの深淵：クラウドの「神の権限」を奪うパケットの操縦術
SSRF（Server-Side Request Forgery）を単なる「URL入力欄の脆弱性」と捉えているなら、君のアーキテクチャは既に危うい。現代のクラウドネイティブな環境において、SSRFは単なる情報漏洩のトリガーではなく、クラウドインフラの制御権を奪う「キーストーン」だ。
今日は、IMDS（Instance Metadata Service）を狙った攻撃の解剖と、小手先のバリデーションを無力化する現代の攻撃トレンド、そして「ゼロトラスト」を体現する防御アーキテクチャについて語ろう。
—
1. 攻撃者が狙う「盲点」：メタデータサービスという特権階級
AWSの 169.254.169.254 や GCPの metadata.google.internal。これらはクラウドインフラがインスタンスに対してIAMロールや設定情報を渡すための、いわば「神のインターフェース」だ。
攻撃者は、アプリケーションサーバーが外部リソースを取得する機能（URLプレビューやWebhook送信など）を悪用し、このローカルIPにパケットをねじ込む。ここで重要なのは、「サーバー自身からのリクエスト」であるため、IAMロールの権限が付与された状態で実行されるという点だ。
攻撃シーケンスの真髄
1. プロトコル・スマグリング: http:// だけでなく、gopher:// や dict:// をサポートする古いライブラリを使っていれば、攻撃者はパケットレベルで任意のペイロードを構成し、内部のRedisやMemcachedを操作してリモートコード実行（RCE）まで持ち込む。
2. DNS Rebinding: 最初の検証フェーズでは無害なIP（例: 8.8.8.8）を返し、キャッシュが切れた瞬間に 169.254.169.254 に切り替える。この「時間差攻撃」を防ぐには、DNS解決結果をキャッシュせず、即時に検証するロジックが必要だ。
—
2. 「許可リスト」の幻想と、正しい防御アーキテクチャ
多くのエンジニアが陥る罠は、「ブラックリスト（ローカルIPを拒否）」による防御だ。しかし、http://[::1]/ や http://169.254.169.254.nip.io/ のようなバイパス手法は掃いて捨てるほどある。
防御の鉄則は「名前解決後のIPアドレスによる許可リスト」だ。これ以外にSSRFを完全に封じ込める道はない。
実装例：Goによるセキュアなリクエストクライアント
以下は、名前解決を行い、返ってきたIPがプライベートIP空間に含まれていないかを検証する堅牢な実装モデルだ。
package securenet
import (
“context”
“net”
“net/http”
“time”
)
// IsPublicIP は、指定されたIPがプライベートネットワークに属していないか検証する
func IsPublicIP(ip net.IP) bool {
if ip.IsLoopback() || ip.IsLinkLocalUnicast() || ip.IsLinkLocalMulticast() || ip.IsInterfaceLocalMulticast() {
return false
}
// RFC 1918 プライベートIP帯域のチェック
privateBlocks := []string{“10.0.0.0/8”, “172.16.0.0/12”, “192.168.0.0/16”}
for _, b := range privateBlocks {
_, network, _ := net.ParseCIDR(b)
if network.Contains(ip) {
return false
}
}
return true
}
// SecureTransport は、SSRFを防ぐためのカスタムTransport
func SecureTransport() http.Transport {
return &http.Transport{
DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
host, _, _ := net.SplitHostPort(addr)
ips, _ := net.LookupIP(host) // 悪用を防ぐため、DNS解決後のIPを検証
for _, ip := range ips {
if !IsPublicIP(ip) {
return nil, fmt.Errorf(“SSRF検出: 許可されていない宛先です”)
}
}
return (&net.Dialer{Timeout: 5 time.Second}).DialContext(ctx, network, addr)
},
}
}
—
3. 生成AI時代のガードレイル：プロンプトインジェクションとの融合
現在、我々が直面している新たな脅威は、LLMの関数呼び出し（Tool Use）におけるSSRFだ。LLMに「Webサイトの内容を要約せよ」と命じた際、攻撃者が巧妙なプロンプトでLLMを操作し、内部APIを叩かせるケースが増えている。
この場合、アプリ層のバリデーションだけでは足りない。「ネットワーク分離（Egress Control）」が最終防衛線となる。
- Egress Gatewayの設置: アプリケーションサーバーが直接インターネットへ出ることを禁止し、特定のホワイトリストドメインのみを通すプロキシ（Envoy等）を挟む。
- メタデータサービスのIMDSv2強制: AWSであれば、セッション指向の認証を強制する
IMDSv2を有効化し、単なるIPアクセスだけではトークンを取得できないように設定すること。これは最低限の義務だ。
—
最後に：セキュリティは「諦めない」ことの連続
SSRFの防御において「完璧」は存在しない。ライブラリのバージョンアップ一つで、新たなプロトコルハンドラーが脆弱性を生むこともある。
だからこそ、我々アーキテクトは「多層防御」と「可観測性」に投資する。
「誰が、どこへ、何のプロトコルで通信しようとしたか」というログをSIEM（SplunkやDatadog等）に流し込み、異常な宛先への試行を即座に検知する。この「泥臭い検知態勢」こそが、最新の攻撃手法を跳ね返すための最強の盾になるんだ。
技術は常にアップデートされる。君たちが構築するシステムが、次の脆弱性トレンドの「実験台」にならないことを切に願っている。
コメント