【実務・中級編】サーバーサイドリクエストフォージェリ(SSRF)の悪用とクラウドメタデータ保護 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

なぜSSRFは「クラウドの心臓部」を射抜くのか —— 現場のエンジニアが知るべきメタデータサービスの深淵

「ただURLを叩くだけの脆弱性だろう？バリデーションを厳しくすればいい」。もしそう思っているなら、今日の話は君のキャリアにとって転換点になるかもしれない。

SSRF（Server-Side Request Forgery）は、単なる「外部サーバーへのリクエスト代行」ではない。クラウド環境において、それは「クラウド基盤そのものに対する権限昇格の鍵」を意味する。特にAWSのIMDS（Instance Metadata Service）やGCPのメタデータサーバーは、開発者が軽視しがちな「穴」だ。今日は、理論的な話はそこそこに、攻撃者が何を見て、どう守るべきかという「実戦の作法」を叩き込む。

—

1. 攻撃者が狙う「見えない裏口」：IMDSv2の重要性

クラウドサーバー（EC2など）は、自分自身がどのIAMロールで動いているかを知るために、特別なIPアドレス 169.254.169.254 を参照する。ここには、一時的な認証トークンや環境変数が転がっている。

かつてのIMDSv1は、単純なGETリクエストだけでこれらの情報を引き出せた。しかし今はIMDSv2が標準だ。なぜか？それは「セッション指向」になったからだ。

攻撃シナリオ：メタデータ窃取のPoC

攻撃者は、SSRFの脆弱性を持つWebアプリケーションに対し、以下のようなリクエストを試みる。

# 1. セッション作成トークンを取得 (PUTリクエストが必要)
curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"

# 2. 取得したトークンを使ってIAMロールの認証情報を引き出す
curl -H "X-aws-ec2-metadata-token: <取得したトークン>" http://169.254.169.254/latest/meta-data/iam/security-credentials/<ロール名>

この「PUTリクエスト」が送れない、あるいはヘッダーを付与できない単純なSSRFであれば、IMDSv2は防波堤として機能する。しかし、アプリケーションが「プロキシ経由の通信」や「HTTPヘッダーの制御を許すライブラリ」を使っていたらどうなるか？簡単に突破される。

—

2. 堅牢な防御：実装レベルで「穴」を塞ぐ

「許可リスト（Allowlist）を使えばいい」とよく言われるが、DNSリバインディング攻撃を考慮していない実装はザルだ。ホスト名の解決結果をチェックする前に、IPアドレスを直接検証するフローを組み込む必要がある。

実装例：Pythonでのセキュアなリクエスト処理

外部からのURL入力を受け取ってコンテンツを取得する際、以下のように実装すべきだ。

import requests
import socket
from urllib.parse import urlparse

def get_safe_content(target_url):
    # 1. URLのパース
    parsed = urlparse(target_url)
    hostname = parsed.hostname
    
    # 2. IP解決してプライベート/リンクローカルを弾く
    ip = socket.gethostbyname(hostname)
    # 169.254.x.x や 10.x.x.x などの内部ネットワークIPを弾くリスト
    forbidden_networks = ["169.254.169.254", "127.0.0.1", "10.0.0.0/8"]
    
    if is_forbidden(ip):
        raise Exception("不正なホストへのアクセスです")

    # 3. タイムアウト設定とリダイレクト禁止（これ重要！）
    return requests.get(target_url, timeout=2, allow_redirects=False)

ポイント： allow_redirects=False を忘れるな。攻撃者はリダイレクト先をメタデータサーバーに指定することで、チェックをすり抜けるからだ。

—

3. インフラでの「完全防御」：IAMとメタデータ設定

アプリケーション側の脆弱性は、いつか必ず発生するものと考えておくべきだ。だからこそ、インフラ側で多重防御を敷く。

AWSの場合：IMDSv2の強制

EC2の起動設定で「メタデータオプション」を以下のように構成する。

Metadata response hop limit: 1 に設定（これにより、コンテナ内からのリクエストや、プロキシを経由したリクエストを制限できる）。
Metadata service: Required に設定（IMDSv1を無効化する）。

Nginxでの防御（プロキシとして使用する場合）

もしサーバーがリバースプロキシを兼ねているなら、設定ファイルでメタデータへのパスを明示的に遮断する。

# /etc/nginx/nginx.conf
location / {
    # メタデータIPへのアクセスを拒否
    deny 169.254.169.254;
    
    # 必要に応じて、特定のIP以外からのアクセスを制限
    allow 192.168.1.0/24;
    deny all;
}

—

最後に：セキュリティは「性悪説」で設計せよ

現場で多くのインシデントを見てきたが、SSRFを許す原因のほとんどは「便利なライブラリをそのまま使う」という思考停止にある。

1. 入力は信じるな： URL入力を受け取ったら、それが内部ネットワークを指していないか必ずチェックせよ。
2. 権限は最小化せよ： インスタンスに付与するIAMロールには、本当に必要な権限しか与えるな。メタデータが盗まれても、被害をS3の特定バケットへのアクセスだけに留めれば、全滅は免れる。
3. 出口を塞げ： サーバーから外部への通信を、セキュリティグループで厳格に制御せよ。

脆弱性を埋めるのはコードの修正だけではない。君が構築したインフラの「哲学」が、最後の砦になる。今日から、君のアプリケーションの通信経路を見直してみてほしい。それは無駄な作業ではない、システムを守るための誇り高きエンジニアリングだ。