SSRF対策のURL検証方法｜サーバーサイドリクエストフォージェリ防止

2019年、大手クラウドサービスで発生したSSRF脆弱性により、数千社の顧客情報が漏洩する事件が発生しました。攻撃者は外部から送信したURLを経由して、本来アクセスできないはずの内部サーバーに侵入したのです。このような攻撃は大企業だけでなく、画像取得機能やPDF生成機能を持つ中小企業のWebアプリケーションでも起こりうるリスクです。この記事では、SSRF（サーバーサイドリクエストフォージェリ）の仕組みから具体的な対策方法まで、技術に詳しくない方にもわかりやすく解説します。

SSRFとは？サーバー側で起きる深刻な脆弱性

SSRF（Server-Side Request Forgery）は、攻撃者がWebアプリケーションのサーバーを踏み台にして、本来アクセスできない内部システムやクラウド環境にアクセスする攻撃手法です。一般的なサイバー攻撃とは異なり、サーバー自身が攻撃の実行者となってしまう点が特徴的です。

SSRFの仕組み｜攻撃者が外部から内部リソースにアクセス

通常、企業の内部ネットワークはファイアウォールで保護されており、外部から直接アクセスすることはできません。しかしSSRF攻撃では、以下のような流れで防御を突破します。

• 攻撃者が、画像URL入力欄などに内部サーバーのアドレス（http://192.168.1.100など）を入力
• Webアプリケーションが入力されたURLに対してリクエストを送信
• サーバー自身が内部ネットワーク内にいるため、ファイアウォールを通過してしまう
• 本来外部からアクセスできない情報が攻撃者に返される

この仕組みにより、外部からは見えない内部システムの情報が盗まれるリスクが発生します。IPA（情報処理推進機構）が公開する「安全なウェブサイトの作り方」でも、SSRF対策の重要性が強調されています。

実際の被害事例｜クラウドメタデータ窃取と内部DB情報漏洩

SSRF脆弱性による実際の被害事例として、以下のようなケースが報告されています。

事例1：クラウドメタデータAPIからの認証情報窃取

AWSやAzureなどのクラウド環境では、サーバーが自身の設定情報を取得するためのメタデータAPIが用意されています。攻撃者がSSRFを利用してこのAPIにアクセスすることで、アクセスキーやパスワードなどの機密認証情報を窃取される事件が複数発生しています。

事例2：内部データベースからの顧客情報漏洩

ECサイトの画像アップロード機能を悪用し、内部データベースサーバーに直接アクセスして顧客の個人情報を取得された事例があります。外部からは接続できないはずのDBサーバーに、Webアプリケーションを経由してアクセスされてしまったのです。

中小企業で狙われやすいケース｜画像取得・PDF生成・外部API連携機能

SSRF脆弱性は大企業だけの問題ではありません。以下のような機能を持つWebアプリケーションでは、中小企業でも被害に遭う可能性があります。

• 画像取得機能：ユーザーがURLを入力して外部画像を表示する機能
• PDF生成機能：WebページをPDF化する際に外部リソースを読み込む機能
• 外部API連携：他社サービスのAPIにアクセスするためにURLを指定する機能
• RSS取得機能：外部サイトのRSSフィードを読み込んで表示する機能

これらの機能は便利である一方、適切な対策を行わないと攻撃の入口となってしまいます。特に外注で開発したシステムの場合、開発時にSSRF対策が考慮されていないケースも多く見られます。

SSRF攻撃で狙われる4つの標的

SSRF攻撃では、通常は外部からアクセスできない以下のような標的が狙われます。自社のシステムにこれらの要素がある場合、特に注意が必要です。

内部ネットワークのサーバー｜192.168.x.xや127.0.0.1への攻撃

企業の内部ネットワークで使用されるプライベートIPアドレス（192.168.x.x、10.x.x.x、172.16.x.xなど）や、サーバー自身を指すローカルアドレス（127.0.0.1、localhost）が主要な攻撃対象となります。

攻撃者は画像URL欄に「http://192.168.1.100:8080/admin」のようなアドレスを入力し、**社内の管理画面や開発サーバーにアクセス**を試みます。外部からは接続できないはずのこれらのサーバーも、Webアプリケーションを経由することでアクセス可能になってしまうのです。

クラウドメタデータAPI｜AWS・Azure・GCPの認証情報窃取

クラウド環境特有の脆弱性として、メタデータAPIへの攻撃があります。代表的な例として、AWSでは「http://169.254.169.254/latest/meta-data/」というアドレスから、サーバーの設定情報や一時的な認証情報を取得できます。

SSRF脆弱性を利用してこのAPIにアクセスされると、以下のような情報が漏洩するリスクがあります。

• IAMロールの一時的なアクセスキー
• セキュリティグループの設定情報
• サーバーの詳細な構成情報
• 環境変数に保存されたパスワードやAPIキー

これらの情報を取得されることで、クラウド環境全体が乗っ取られる可能性もあります。Azure（http://169.254.169.254/metadata/instance）やGCP（http://metadata.google.internal/）も同様のリスクを抱えています。

社内システムやDB｜ファイアウォール内の業務システム

多くの企業では、顧客情報を保存するデータベースや基幹業務システムを、外部からアクセスできない内部ネットワークに配置しています。しかしSSRF攻撃では、Webアプリケーションがファイアウォールの内側にいることを利用して、これらのシステムに不正アクセスします。

特に危険なのは、以下のようなケースです。

• データベースサーバーが認証なしでアクセスできる設定になっている
• 管理用のWeb画面がBasic認証のみで保護されている
• 社内システムが「内部からのアクセスは安全」という前提で設計されている

OWASP Top 10でもSSRFは重要な脆弱性として位置づけられており、内部システムへの多層防御の必要性が指摘されています。

管理画面や開発環境｜非公開の管理ツールへの侵入

開発中のテスト環境や、社内専用の管理画面なども攻撃の対象となります。これらのシステムは「外部に公開していないから安全」と考えられがちですが、SSRF経由でアクセスされるリスクがあります。

実際の事例として、以下のような被害が報告されています。

• 開発環境のデバッグ情報から本番環境の構成が推測される
• 管理画面から顧客データの一括ダウンロードが実行される
• Jenkins等のCI/CDツールを経由してソースコードが窃取される

これらの被害を防ぐためには、内部システムであっても適切なアクセス制御と認証を実装する必要があります。

効果的なSSRF対策｜URL検証の実装方法

SSRF攻撃を防ぐためには、ユーザーから入力されたURLを適切に検証することが重要です。ここでは、実装すべき4つの主要な対策方法を解説します。

ホワイトリスト方式｜許可ドメインのみ通信を許可

最も確実なSSRF対策は、アクセスを許可するドメインをあらかじめ限定するホワイトリスト方式です。画像取得機能であれば、信頼できる画像ホスティングサービスのドメインのみを許可します。

ホワイトリスト方式の実装ポイントは以下の通りです。

• 許可するドメインのリストを設定ファイルやデータベースで管理
• 入力されたURLのドメイン部分を抽出して、リストと照合
• 一致しない場合はエラーを返し、リクエストを送信しない
• サブドメインの扱いを明確にする（example.comを許可した場合、sub.example.comも許可するか）

この方法は制限が厳しい分、セキュリティレベルが最も高くなります。ただし、ユーザーが任意のURLを指定したい機能には適用できないため、用途に応じて他の対策と組み合わせる必要があります。

IPアドレスのブロック｜プライベートIP範囲を拒否

内部ネットワークへのアクセスを防ぐため、プライベートIPアドレス範囲へのリクエストをブロックします。具体的には、以下のIP範囲を拒否リストに登録します。

• 127.0.0.0/8（ローカルホスト）
• 10.0.0.0/8（クラスA プライベートネットワーク）
• 172.16.0.0/12（クラスB プライベートネットワーク）
• 192.168.0.0/16（クラスC プライベートネットワーク）
• 169.254.0.0/16（リンクローカルアドレス、クラウドメタデータAPI含む）

実装時の注意点として、ドメイン名だけでなくIPアドレスも確認する必要があります。攻撃者が「example.com」というドメインを登録し、そのDNS設定で192.168.1.1を返すように設定している場合、ドメイン名のチェックだけでは防げません。

そのため、以下の手順で検証することが推奨されます。

1. 入力されたURLからドメイン名を抽出
2. DNS解決を行ってIPアドレスを取得
3. 取得したIPアドレスがプライベート範囲に含まれないか確認
4. 問題なければリクエストを送信

URLスキームの制限｜http・https以外を禁止

URLにはhttp://やhttps://以外にも、file://、ftp://、gopher://など、様々なスキーム（プロトコル）が存在します。これらの中には、ローカルファイルへのアクセスや内部システムへの予期しない接続を引き起こすものがあります。

SSRF対策として、**http://とhttps://のみを許可**し、それ以外のスキームは拒否する設定を行います。特に以下のスキームは危険性が高いため、明示的にブロックする必要があります。

• file://：サーバー上のローカルファイルを読み取られる
• gopher://：内部サービスへの任意のコマンド送信に悪用される
• dict://：辞書サーバープロトコルを悪用した情報取得
• ftp://：内部FTPサーバーへの不正アクセス

実装時は、URLの先頭部分を正規表現などで検証し、許可されたスキーム以外はエラーとして処理します。

リダイレクト追跡の制御｜301・302による迂回攻撃を防止

SSRF対策を実装していても、HTTPリダイレクト（301や302レスポンス）を利用した迂回攻撃によって防御を突破される可能性があります。

攻撃の流れは以下の通りです。

1. 攻撃者が自身のサーバー（例：evil.com）のURLを入力
2. Webアプリケーションが検証を行い、外部ドメインとして許可
3. evil.comにリクエストを送ると、301リダイレクトで内部サーバー（http://192.168.1.100）へ転送される
4. Webアプリケーションが自動的にリダイレクト先にアクセスしてしまう

この攻撃を防ぐためには、以下の対策が有効です。

• リダイレクトを追跡しない設定にする（自動リダイレクト機能をオフ）
• リダイレクトを許可する場合は、リダイレクト先のURLも再度検証する
• リダイレクト回数に上限を設定する（3回程度）
• 異なるドメインへのリダイレクトは拒否する

これらの対策により、リダイレクトを利用した迂回攻撃を防ぐことができます。

SSRF対策で陥りがちな落とし穴

SSRF対策を実装しても、以下のような見落としによって脆弱性が残存するケースがあります。実装時には特に注意が必要なポイントを解説します。

バリデーション後の再解決｜DNS rebinding攻撃への注意

DNS rebinding攻撃とは、検証時と実際のアクセス時でDNSの解決結果を変える巧妙な手法です。

攻撃の流れは以下の通りです。

1. 検証時：攻撃者のドメイン（evil.com）が正常な外部IPアドレス（例：203.0.113.1）を返す
2. Webアプリケーションが検証を通過
3. 実際のアクセス時：同じドメインが内部IPアドレス（192.168.1.100）を返すように切り替わる
4. 短いTTL（Time To Live）設定により、数秒でDNS結果が変更される

この攻撃を防ぐためには、以下の対策が有効です。

• DNS解決結果をキャッシュし、検証時と同じIPアドレスに接続する
• 検証からアクセスまでの時間を最小化する
• 必要に応じて、アクセス直前に再度IPアドレスを検証する

IPAの調査によると、DNS rebinding攻撃は高度な技術を要するため頻度は低いものの、完全に防御するためには考慮すべき脅威とされています。

短縮URLサービス｜bit.lyなどを経由した迂回

bit.lyやTinyURLなどの短縮URLサービスを経由することで、SSRF対策を迂回される可能性があります。短縮URLは最終的にどこにリダイレクトされるか事前に判断できないため、以下のようなリスクがあります。

• 検証時には正当なURLに見えるが、実際には内部IPアドレスにリダイレクトされる
• 短縮URL作成後に転送先を変更される可能性がある
• 複数段階のリダイレクトで検証をすり抜ける

対策としては、以下の方法が考えられます。

• 既知の短縮URLサービスのドメインを拒否リストに登録
• 短縮URLを展開してから最終的な転送先を検証
• ホワイトリスト方式を採用し、短縮URL自体を使用不可にする

複数のチェック漏れ｜IPアドレスとホスト名の両方を検証

SSRF対策でよくある失敗として、ホスト名のみを検証してIPアドレスを確認しないケースや、その逆のパターンがあります。攻撃者は検証の隙を突いて、様々な方法で対策を回避しようとします。

包括的な検証を行うためには、以下のすべてをチェックする必要があります。

• URLスキームが許可されたものか
• ホスト名が許可リストに含まれるか（ホワイトリスト方式の場合）
• DNS解決後のIPアドレスがプライベート範囲に含まれないか
• リダイレクト先のURLも同様に検証されるか
• ポート番号が想定外のものでないか（80、443以外を拒否する場合）

これらの検証を段階的に実施することで、多層防御を実現できます。

エラーメッセージの情報漏洩｜内部構成を推測される危険性

SSRF対策でリクエストをブロックした際、詳細すぎるエラーメッセージを返すと、内部ネットワークの構成情報が推測されるリスクがあります。

避けるべきエラーメッセージの例は以下の通りです。

• 「192.168.1.100へのアクセスは許可されていません」→ 内部IPの存在を確認される
• 「ポート8080は使用できません」→ 使用されているポート番号が推測される
• 「データベースサーバーへの接続に失敗しました」→ 内部システムの種類が特定される

適切なエラーメッセージは、具体的な情報を含まない一般的な表現にすべきです。

• 「指定されたURLにはアクセスできません」
• 「無効なURLが入力されました」
• 「セキュリティポリシーにより、このリクエストは拒否されました」

詳細なエラー情報は、管理者用のログにのみ記録し、一般ユーザーには表示しないようにすることが重要です。

まとめ

この記事では、SSRF（サーバーサイドリクエストフォージェリ）対策について、仕組みから具体的な実装方法まで解説しました。重要なポイントは以下の3つです。

• ホワイトリスト方式とIPブロックの併用：許可するドメインを限定しつつ、プライベートIP範囲へのアクセスを拒否することで、多層防御を実現できます
• リダイレクト追跡の適切な制御：自動リダイレクト機能をオフにするか、リダイレクト先も再検証することで、迂回攻撃を防止できます
• DNS rebindingや短縮URLへの対策：検証後の再解決や、複数段階のリダイレクトに注意し、包括的なチェックを行うことが重要です

SSRF対策は、単一の方法だけでは不十分であり、複数の防御策を組み合わせることが効果的です。開発ベンダーと連携して適切な対策を実装し、定期的な脆弱性診断で確認することをおすすめします。自社での対応が難しい場合は、セキュリティの専門家に相談することも検討してください。次のステップとして、OWASP Top 10で指摘されている他の脆弱性についても確認し、Webアプリケーション全体のセキュリティレベルを向上させましょう。