SSRF（サーバーサイドリクエストフォージェリ）

SSRF（Server-Side Request Forgery）は、攻撃者がサーバーに任意のURLへHTTPリクエストを送信させることで、外部から直接アクセスできない内部ネットワークやクラウドメタデータへアクセスさせる攻撃である。Webhookやサムネイル生成・URLプレビュー・PDF生成など、外部URLを入力として受け取る機能はSSRFの潜在的な入り口となる。2021年のOWASP Top 10でSSRFが新たに独立カテゴリとして追加されたのは、クラウド環境での普及と深刻度の高まりを反映している。

クラウド環境でのSSRFは特に危険であり、AWS・GCP・Azureのクラウドインスタンスメタデータサービスエンドポイント（http://169.254.169.254/等）へのアクセスに成功した場合、IAMクレデンシャルが取得され、そのインスタンスに付与された権限でクラウドリソース全体が操作される可能性がある。AWSはIMDSv2（Instance Metadata Service version 2）でトークンベースの認証を導入し、単純なGETリクエストによるメタデータ取得を防止している。

DNSリバインディング（DNS Rebinding）は、SSRF対策として許可リストにドメイン名を使っている場合に、攻撃者が制御するDNSサーバーを使ってドメインの解決先をIPアドレス検証後に内部IPに切り替える回避技術である。SSRFへの多層的な防御として、アプリケーションレベルの許可リスト・DNSレベルでの内部IPブロック・ネットワークレベルのアウトバウンド制限を組み合わせることが推奨される。

コードレビューで着目するポイント

ユーザー入力のURLに対してHTTPリクエストを発行する箇所に許可リストが設定されているか
リクエスト前にDNS解決後のIPアドレスを検証し、プライベートIPレンジ（10.0.0.0/8・172.16.0.0/12・192.168.0.0/16・169.254.0.0/16等）へのアクセスを拒否しているか
クラウド環境でIMDSv2が有効になっており、IMDSv1が無効化されているか
アウトバウンドネットワークポリシーで不要な内部サービスへのアクセスがブロックされているか
リダイレクトを追跡するHTTPクライアント設定で、リダイレクト先のURLも許可リストで検証されているか
Webhookエンドポイントなどの機能でSSRFの可能性が設計段階で検討されているか

典型的なアンチパターン

URLの形式チェックのみ: https://で始まるURLであることだけを確認し、https://192.168.1.1/internal-apiのようなプライベートIPへのアクセスを許可してしまう実装。URLのスキームチェックだけでは不十分であり、DNS解決後のIPアドレスレベルでのフィルタリングが必要。

ブラックリストによるIPフィルタリング: 127.0.0.1とlocalhostをブラックリストに追加するが、::1（IPv6のloopback）・0.0.0.0・127.0.0.2（loopbackレンジ）などの回避パターンを網羅しきれない実装。ホワイトリストで許可する外部ドメイン・IPレンジを明示的に定義し、それ以外を拒否することが安全。

HTTPリダイレクト追跡の無制限許可: SSRF対策で入力URLを検証したが、HTTPクライアントがLocationヘッダーで内部IPアドレスへリダイレクトを自動追跡する設定のまま。リダイレクト追跡を無効化するか、各リダイレクト先のURLを再検証するロジックが必要。

参考リソース

OWASP SSRF Prevention Cheat Sheet — SSRF対策の包括的な実装ガイド
OWASP Top 10: A10 SSRF — SSRFの定義・攻撃例・防御策の概要
AWS IMDSv2の有効化ガイド — AWSのインスタンスメタデータサービスv2設定ドキュメント
ssrf.py / SSRFmap — SSRF脆弱性の発見・エクスプロイトツール（ペネトレーションテスト用）
PortSwigger Web Security Academy: SSRF — 実際にSSRFを試せるインタラクティブな学習ラボ