SSRFの深淵：クラウドメタデータという「パンドラの箱」をどう閉じるか
SSRF（Server-Side Request Forgery）を単なる「URL入力値のバリデーション漏れ」と定義しているうちは、君のインフラはまだ無防備だ。
現実のインシデントにおいて、SSRFは「攻撃者が君のサーバーをプロキシ（踏み台）として使い、本来到達不可能な内部ネットワークの深部へ潜入する」ための極めて洗練された戦術だ。特にAWSやGCPのようなクラウド環境において、メタデータサービス（IMDS）へのアクセスは、しばしばインフラ全体の権限奪取、すなわち「ゲームオーバー」を意味する。
今日は、教科書的な「URLをブラックリスト化しろ」といった無意味なアドバイスは捨てよう。アーキテクトとして、物理層からアプリケーション層に至るまで、どのようにこの脅威を封じ込めるべきか、その泥臭い現実を語る。
—
1. プロトコル仕様の裏をかく「リダイレクト」と「解析の不一致」
攻撃者は、君が書いたバリデーターを嘲笑う。最も危険なのは、curlやurllibのようなライブラリが抱える「URL解析の解釈の差異」だ。
例えば、バリデーターはhttp://safe.comを許可するが、背後のライブラリがhttp://169.254.169.254（AWSメタデータ）へリダイレクトを追従（Follow Redirects）してしまったらどうなるか。あるいは、@や#を用いたURLエンコードの妙技で、バリデーターをバイパスされる例は枚挙に暇がない。
防御の鉄則：名前解決を委譲しない
アプリケーション層でURLをバリデーションするのではなく、名前解決そのものを制御するのがプロのやり方だ。
import socket
import ipaddress
def is_safe_url(url):
# 1. URLを解析してホスト名を取得
# 2. 名前解決を自前で行い、そのIPがプライベートIP空間ではないかチェック
hostname = extract_hostname(url)
ip = socket.gethostbyname(hostname)
# 3. 内部ネットワーク空間（RFC 1918など）へのアクセスを厳格に拒否
if ipaddress.ip_address(ip).is_private:
raise SecurityException(“Internal network access blocked.”)
return True
※注：これでもDNS Rebinding攻撃には脆弱だ。真の対策は、名前解決の結果をキャッシュせず、解決と接続をアトミックに行うか、プロキシ環境下での隔離が必要になる。
—
2. IMDSv2への強制移行と「TTL」の活用
クラウド環境でSSRFを食い止めるための最大の防衛線は、IMDS（Instance Metadata Service）のバージョン管理だ。IMDSv1は単なるHTTPリクエストでメタデータを晒すが、IMDSv2はセッション指向であり、事前にトークンを取得するプロセスが必要になる。
攻撃者は「トークンを取得するリクエスト」を飛ばす必要があるが、SSRFの多くはGETメソッド単発であることが多い。この「ひと手間」を強制するだけで、単純なSSRFの多くは無力化される。
さらに、メタデータサービスへのリクエストパケットのTTL（Time To Live）を強制的に1に制限するカーネルパラメータを設定するのも有効だ。
iptablesを用いて、メタデータサービス宛のパケットのTTLを制限する
攻撃者が外部から注入したリクエストが、ルーターを介して到達することを防ぐ
iptables -t mangle -A OUTPUT -d 169.254.169.254 -j TTL –ttl-set 1
—
3. 生成AI時代の新たな脅威：プロンプトインジェクションとSSRFの結合
現在、我々が直面している最大の変化は、LLM（大規模言語モデル）を組み込んだアプリケーションだ。ユーザーからの入力を受け取り、外部のAPIを叩いて回答を生成する際、プロンプトインジェクションによって「内部のAPIキーを読み取って外部に送信しろ」と指示されるケースが増えている。
この「ガードレイル」設計において重要なのは、「信頼できない出力」と「ネットワーク境界」の分断だ。
- サンドボックス実行: LLMが生成したURLやコマンドを直接実行してはいけない。必ず「認可されたアクション」のみを許可するホワイトリスト形式のAPIゲートウェイを介在させること。
- ゼロトラストネットワーク: アプリケーションサーバーからメタデータサービスへの通信を、
iptablesやnftablesでデフォルト拒否（Drop）し、必要な時だけ特定のサービスアカウントにのみ許可する。
—
4. チーフホワイトハッカーの結論：防御とは「想定外を捨てる」こと
SSRF防御において、完璧なバリデーション関数を書こうと努力する時間は無駄だ。URLの仕様は複雑怪奇であり、ライブラリの更新一つで脆弱性が復活する。
真の対策は以下の3点に集約される。
1. ネットワーク分離: メタデータサービスへのアクセスは、IAMロールとネットワークポリシーで物理的に遮断せよ。
2. プロキシの強制: 外部へのリクエストは必ず「Egress Proxy」を通し、そこでホワイトリストベースのURLフィルタリングを適用せよ。アプリケーションサーバーに直接インターネットへ出させるな。
3. 観測性の確保: SSRFの兆候は、通常のアクセスログには現れない。内部ネットワークへの異常なポートスキャンや、メタデータサービスへの403エラーログをSIEMで相関分析し、自動遮断する仕組みを作れ。
エンジニアよ、コードの脆弱性を探すのも大切だが、「攻撃者が物理的にどこまで届くか」を常に想像せよ。 ネットワークの境界を制御できれば、アプリケーション側のミスすらも致命傷にはなり得ない。それが、我々プロの戦い方だ。
コメント