SSRFの深淵：許可リストとメタデータ遮断のその先にある「アーキテクチャの真実」
SSRF（Server-Side Request Forgery）を単なる「URLのバリデーション漏れ」と捉えているなら、君のアーキテクチャは既に突破されているかもしれない。
多くのエンジニアは「許可リスト（Allowlist）による検証」で満足するが、我々のような攻撃者側から見れば、それは「アプリケーション層での防御」に過ぎない。TCP/IPスタックの挙動、DNSの再帰的問い合わせ、そしてクラウド基盤のメタデータサービスが抱える「信頼の境界」を理解しなければ、真の防御は構築できないんだ。
今日は、教科書的な「URLチェック」の先にある、泥臭くも強固な防衛ロジックを解剖しよう。
—
1. アプリケーション層の「許可リスト」はなぜすり抜けられるのか？
よくある失敗例は、URLをパースして正規表現で弾くアプローチだ。だが、パーサーの不一致（Parser Differential）を突かれたら終わりだ。
例えば、アプリケーションは http://google.com を許可するが、背後のHTTPクライアントライブラリやOSのネットワークスタックが http://169.254.169.254 を解釈するタイミングで、DNSのTTLを無視した「DNS Rebinding」が発生する。あるいは、URLのプロトコルスキームに gopher:// や dict:// が混入し、バックエンドのライブラリがそれを処理してしまう。
根本的な防御アーキテクチャ：Network Isolation
アプリケーション層でURLをバリデーションするのではなく、ネットワークの物理的（論理的）隔離を強制する。
信頼できないURLを直接リクエストさせないための防御層設計
import requests
from urllib.parse import urlparse
def safe_request(url):
parsed = urlparse(url)
# 1. 許可されたスキームのみを強制（http/https以外は即時遮断）
if parsed.scheme not in [‘http’, ‘https’]:
raise ValueError(“Invalid Protocol”)
# 2. 内部ネットワーク/メタデータIPへの直接アクセスを即時遮断
# 169.254.169.254 (AWS/GCP/Azure) やプライベートIP帯域をフィルタリング
forbidden_ips = [‘169.254.169.254’, ‘127.0.0.1’, ‘10.0.0.0/8’]
# ここでDNS解決後のIPをチェックする（DNS Rebinding対策）
# ※socket.getaddrinfoで解決したIPが許可リスト内かを確認するフローを必ず挟む
…
—
2. メタデータサービス遮断：ハードウェアレベルの信頼
クラウド環境における最大の脅威は、メタデータサービス（IMDS）へのアクセスだ。攻撃者はここからIAMロールの認証トークンを盗み出し、クラウドリソースを掌握する。
これを防ぐには、アプリケーションのコードを修正するだけでなく、ネットワークポリシー（iptables / eBPF）による強制遮断が不可欠だ。
iptablesによる最強のガードレール
アプリケーションがコンテナ内で動いているなら、サイドカーやホスト側で以下のルールを適用せよ。アプリケーションがバグっても、OSレベルでメタデータへのパケットをDROPする。
169.254.169.254 への出力を完全に遮断する（アプリケーションからの通信を無効化）
iptables -A OUTPUT -d 169.254.169.254 -j DROP
必要であれば、ログを出力してインシデント検知に繋げる
iptables -A OUTPUT -d 169.254.169.254 -j LOG –log-prefix “SSRF_ATTEMPT_DETECTED: ”
今のモダンなスタックであれば、CiliumのようなeBPFベースのネットワークポリシーを採用し、IDベースで通信を制御するのが最適解だ。
—
3. 生成AI時代の新たな脅威：プロンプト・インジェクションとSSRFの融合
LLMを統合したアプリケーションでは、「ツール使用（Function Calling）」がSSRFの新たなベクターとなる。AIが生成したURLをツールがそのままリクエストしてしまうと、AIがプロンプトインジェクションによって外部から誘導されるリスクがある。
防御層：サンドボックス化されたプロキシ
AIの出力と外部ネットワークの間に、「検証専用のプロキシ」を配置するアーキテクチャを推奨する。
1. AIの出力: 外部サイトへのリクエストURLを生成。
2. プロキシ層: URLを受け取り、静的解析および動的サンドボックスで「安全なコンテンツか」を判定。
3. 実行層: プロキシを通過したもののみ、外部へリクエストを投げる。
ここで重要なのは、「AIが何をしたか」ではなく「AIを動かすインフラがどこまで許可されているか」というゼロトラストの原則だ。
—
結論：セキュリティは「諦め」から始まる
結局のところ、完璧なURLバリデーションなど存在しない。重要なのは「リクエストが成功したとしても、その先には何も盗むべきものがない」という防衛的設計（Defense in Depth）だ。
- 最小特権: メタデータサービスへのアクセス権限は、必要なリソースにしか付与しない。
- egressフィルタリング: サーバーからの外部通信は、許可されたドメイン以外へは全て拒否する。
- オブザーバビリティ: どのプロセスが、どのIPに通信を試みたかをSIEMでリアルタイム監視する。
技術は常に進化するが、攻撃者の目的は変わらない。君たちのアーキテクチャが「攻撃者が最も嫌がる環境」になっているか、今一度、パケットキャプチャとポリシー設定を見直してほしい。それが、プロのエンジニアに求められる責務だ。
コメント