Server-Side Request Forgery

SSRF（Server-Side Request Forgery：サーバーサイドリクエストフォージェリ）とは、攻撃者がWebアプリケーションサーバーを踏み台にして、サーバー側から意図しないHTTPリクエストを発行させる攻撃手法です。外部からは直接アクセスできない内部ネットワークやクラウドメタデータエンドポイントに対して、サーバーの権限でリクエストを送信させることが可能になります。

SSRFは、Webアプリケーションがユーザーから提供されたURL（画像取得、Webhook通知、URLプレビュー機能など）に基づいてサーバーサイドでHTTPリクエストを発行する機能に存在します。攻撃者はこの機能を悪用し、内部サービスへのアクセスやクラウドインスタンスのメタデータ窃取を行います。

OWASP Top 10 2021においてSSRFは新たにカテゴリとして追加（A10:2021）されるなど、クラウド環境の普及に伴いその危険性が急速に高まっています。特にAWS、GCP、Azureなどのクラウド環境では、メタデータサービス（IMDS）を通じてIAMクレデンシャルが窃取される深刻なリスクがあります。

主な攻撃手法

• 内部ネットワークスキャン：サーバーから内部ネットワーク（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）に対してリクエストを送信し、稼働しているサービスやポートを探索する
• クラウドメタデータの取得：クラウドインスタンスのメタデータエンドポイント（169.254.169.254）にアクセスし、IAMロールの一時的な認証情報（アクセスキー・シークレットキー）を窃取する
• ローカルファイルの読み取り：file://プロトコルを利用してサーバー上のローカルファイル（/etc/passwd、設定ファイル、ソースコードなど）を読み取る
• 内部サービスの操作：Redis、Memcached、Elasticsearchなど、認証なしで利用可能な内部サービスに対してコマンドを実行し、データの読み取りや書き込みを行う

クラウドIMDS攻撃（169.254.169.254）

クラウド環境で最も深刻なSSRF攻撃が、IMDS（Instance Metadata Service）へのアクセスです。AWS EC2インスタンスでは、http://169.254.169.254/latest/meta-data/ にアクセスすることで、インスタンスのメタデータ（ホスト名、セキュリティグループ、ネットワーク設定など）を取得できます。

特に危険なのは、http://169.254.169.254/latest/meta-data/iam/security-credentials/ を通じてIAMロールの一時的な認証情報（AccessKeyId、SecretAccessKey、Token）が取得できる点です。これにより攻撃者はAWSの各種サービス（S3、DynamoDB、SQSなど）に不正アクセスが可能となります。

IMDSv2による対策

AWSはIMDSv2（Instance Metadata Service Version 2）を導入し、SSRFによるメタデータ窃取を困難にしました。IMDSv2ではメタデータへのアクセスにPUTリクエストによるトークン取得が必須となり、単純なGETリクエストでは情報を取得できなくなります。さらにTTL（Time To Live）ヘッダーの値を1に設定することで、プロキシを経由したリクエストがブロックされます。

DNS Rebinding経由のSSRF

DNS Rebindingは、SSRFのフィルタリング（URLのバリデーション）をバイパスする高度な手法です。攻撃者はDNSの応答を操作し、最初のDNS解決では正当な外部IPアドレスを返しますが、サーバーが実際にリクエストを送信する際の2回目のDNS解決では内部IPアドレス（127.0.0.1や169.254.169.254）を返します。これにより、ホスト名ベースのURLフィルタリングをバイパスできます。

Blind SSRF

Blind SSRFは、サーバーからのHTTPリクエストの応答内容が攻撃者に返されないケースのSSRFです。レスポンスの内容は確認できないものの、レスポンス時間の差異やステータスコードの違いから内部サービスの存在を推測したり、外部の攻撃者管理サーバーへのコールバックを利用してデータを窃取したりする手法が使われます。

• 01
  入力URLの厳格なバリデーション：ユーザーから受け取るURLに対して、許可されたプロトコル（https://のみ等）、ホスト名のホワイトリスト、プライベートIPアドレス範囲のブロックを実装してください。DNSの解決結果もバリデーションし、DNS Rebinding攻撃を防止しましょう。
• 02
  IMDSv2の強制適用：AWS環境ではIMDSv2を必須に設定し、IMDSv1を無効化してください。GCP、Azureでも同等のメタデータサービス保護機能を有効にしましょう。クラウドインスタンスのメタデータエンドポイントへのアクセスはネットワークレベルでも制限することを推奨します。
• 03
  ネットワークセグメンテーション：Webアプリケーションサーバーから内部ネットワークへのアクセスをファイアウォールやセキュリティグループで最小限に制限してください。特にメタデータエンドポイント（169.254.169.254）へのアクセスはiptablesやルーティングで遮断しましょう。
• 04
  リクエスト先のホワイトリスト方式の採用：サーバーサイドHTTPリクエストの宛先は、ブラックリスト方式ではなくホワイトリスト方式で管理してください。許可されたドメイン・IPアドレスのみにリクエストを送信するよう制限しましょう。
• 05
  レスポンスの制限とフィルタリング：サーバーサイドHTTPリクエストのレスポンスをそのままユーザーに返さないでください。必要最小限の情報のみを抽出し、エラーメッセージにも内部情報を含めないようにすることで、Blind SSRFの影響を軽減できます。
• 06
  WAFルールとモニタリングの実装：WAFにSSRF攻撃パターン（プライベートIP、メタデータURL、file://プロトコル等）の検知ルールを設定してください。内部ネットワークへの異常なアウトバウンド通信を監視し、アラートを設定しましょう。