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

SSRFの深淵：クラウドの「鍵」を奪うIMDSv2攻撃と、現場で生き残る防御戦略

現場でシステムを守っていると、よく「バリデーションはちゃんとやっています」という言葉を耳にする。だが、多くのエンジニアが言う「バリデーション」は、多くの場合、URLの先頭が http で始まっているかを確認するだけの、あまりに脆い防壁に過ぎない。

今日話したいのは、クラウド環境におけるSSRF（Server-Side Request Forgery）の真の脅威、すなわち「クラウドメタデータサービス（IMDS）」の悪用についてだ。これは単なるデータ漏洩ではない。クラウドインフラの乗っ取りを意味する。

—

なぜ、SSRFは「致命的」なのか

SSRFは、攻撃者がサーバーを「踏み台」にして、本来アクセスできないはずの内部リソースにHTTPリクエストを投げさせる手法だ。

特にクラウド環境では、169.254.169.254 というマジックナンバーが存在する。これがAWSやGCP等の「インスタンスメタデータサービス（IMDS）」だ。ここを叩かれると、実行中のインスタンスに付与されているIAMロールの認証情報（アクセスキーやトークン）が平文で返ってくる。これさえ手に入れば、攻撃者は外からあなたのクラウド環境を操作し放題になる。

攻撃者が狙う「盲点」

攻撃者は、あなたが実装した脆弱なURLパーサーを以下のようにバイパスする。

DNSリバインディング: ドメインを localhost やメタデータサービスへ向ける。
URLエンコーディングの悪用: 169.254.169.254 を16進数や8進数で難読化し、単純なブラックリスト（169.で始まるかをチェックするようなもの）をすり抜ける。
リダイレクトの悪用: 指定したURLに302リダイレクトが含まれている場合、サーバー側で追従（Follow Redirect）設定がオンになっていると、最終的にメタデータサービスへ誘導される。

—

防御の鉄則：ブラックリストは「捨てろ」

「内部IPを拒否する」といったブラックリスト方式は、攻撃者の辞書にある難読化手法の前に無力だ。許可リスト（ホワイトリスト）こそが正義である。

1. アプリケーション層での防御（Python実装例）

URLのパースは正規表現で済ませず、信頼できるライブラリを使って「スキーム」「ホスト」「ポート」を厳密にチェックする。

from urllib.parse import urlparse
import requests

def secure_request(url):
    parsed = urlparse(url)
    
    # 許可されたスキームのみを許可
    if parsed.scheme not in ['http', 'https']:
        raise ValueError("不適切なプロトコルです")
        
    # 許可されたドメイン（ホワイトリスト）のみを許可
    allowed_domains = ['api.trusted-service.com', 'files.internal-storage.com']
    if parsed.hostname not in allowed_domains:
        raise ValueError("許可されていないホストです")

    # リクエスト実行時、リダイレクトを許可しないのが鉄則
    # タイムアウトも必ず設定する（DoS防止）
    response = requests.get(url, allow_redirects=False, timeout=2)
    return response.content

2. インフラ層での防御：IMDSv2の強制

AWSを使っているなら、IMDSv2（セッション指向型）への移行は必須だ。IMDSv1は単に叩くだけで情報が取れるが、v2は PUT リクエストでセッションヘッダーを取得しなければならないため、SSRFの脆弱性だけでは突破が極めて困難になる。

Terraformでインスタンス作成時に以下のように設定し、v1を無効化する。

# AWS EC2インスタンス設定例
resource "aws_instance" "app_server" {
  # ... 省略 ...
  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required" # これがIMDSv2の強制
    http_put_response_hop_limit = 1          # メタデータ取得のリクエスト回数を制限
  }
}

—

現場でやるべき「泥臭い」インシデント対策

コードを直すだけがセキュリティではない。以下の運用を徹底してほしい。

1. ネットワーク分離: アプリサーバーからメタデータサービスへの通信以外で、169.254.169.254 へのアウトバウンド通信をセキュリティグループやネットワークACLで遮断する。これは「多層防御」の基本だ。
2. IAMの最小権限: 万が一、メタデータが盗まれても被害を最小限にするため、インスタンスに付与するIAMロールは「S3の特定のバケットのみアクセス可能」といったレベルまで絞り込む。
3. WAFによる監視: 悪意のあるURLパラメータを検知するために、WAFで 169.254 などの文字列を含むリクエストをブロックするルールを追加する。これは完全な防御にはならないが、攻撃者の偵察（Probing）を検知するアラートとして非常に有効だ。

最後に

セキュリティエンジニアとして、多くの現場を見てきた。そこで気づくのは、「完璧な防御」を目指しすぎて複雑な実装をし、かえってバグを生むチームが少なくないということだ。

SSRFを防ぐ最大の秘訣は、「外部からの入力を、絶対に信頼しない」という基本姿勢と、クラウドベンダーが提供する最新の認証機能（IMDSv2等）を正しく設定することに尽きる。

「動けばいい」というコードに、セキュリティという名の「保険」をかけておくこと。それが、真のプロフェッショナルなエンジニアの仕事だ。皆さんのシステムが、今日も安全であることを願っている。