SSRF攻撃の仕組みと効果的な緩和策

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

SSRF攻撃の仕組みと効果的な緩和策

SSRF（Server-Side Request Forgery、サーバーサイド・リクエスト・フォージェリ）攻撃は、Webアプリケーションの脆弱性を悪用し、サーバー自身に任意のHTTPリクエストを送信させることで、内部ネットワークやクラウド環境の機密情報に不正アクセスする攻撃手法です。攻撃者は直接アクセスできない内部リソースに対し、脆弱なアプリケーションをプロキシとして利用します。OWASP Top 10の2021年版ではA07として分類されており、その危険性が改めて認識されています[1]。

脅威モデル

SSRF攻撃は、外部の攻撃者が直接アクセスできない内部リソース（データベース、管理画面、他の内部サービス、クラウドメタデータサービスなど）を標的とします。脅威モデルは以下の通りです。

  • 攻撃者: 外部に存在する悪意のあるユーザー。

  • 攻撃対象: ユーザーが指定したURLに基づいて外部リソースを取得・処理する機能を持つWebアプリケーション。

  • 攻撃目的:

    • 機密情報の窃取: クラウド環境の認証情報（IAMロールの一時クレデンシャル）や、内部ネットワーク内の設定情報などを取得。

    • 内部サービスの悪用: 内部向けAPIの実行、管理インターフェースへのアクセス、データベースへの接続など。

    • ポートスキャン: 内部ネットワークの稼働中のポートを特定し、さらなる攻撃の足がかりとする。

    • サービス拒否（DoS）: 内部リソースへの過剰なリクエストによりサービス停止を引き起こす。

この攻撃は、多くの場合、Webサーバーが動作する環境（クラウドインスタンスのメタデータAPIや、オンプレミス環境の管理APIなど）に特権的なアクセスを許してしまうため、甚大な被害につながる可能性があります。

SSRF攻撃の仕組みと攻撃シナリオ

SSRF攻撃は、Webアプリケーションがユーザーから提供されたURLを検証せずに、サーバー側でそのURLへリクエストを生成・実行する機能に依存します。例えば、画像のサムネイル生成、PDF変換、RSSフィードの読み込み、Webhookの登録、ログ収集などの機能が悪用されることがあります。

攻撃の段階（Attack Chain）

SSRF攻撃は、以下のような段階で実行されます。

graph TD
    A["攻撃者"] --> |1. 悪意のあるURLを含むリクエストを送信 (例: 画像URL指定)| B("脆弱なWebアプリケーション")
    B --> |2. ユーザー指定のURLへサーバーから内部リクエストを生成| C{"URL解析/検証の不備"}
    C --> |3. 内部ネットワーク/サービスへのアクセス試行 (例: IMDSv1, 内部API)| D("標的リソース: クラウドメタデータサービス/内部DB/管理コンソール")
    D --> |4. 機密情報/応答を返す| B
    B --> |5. 応答を攻撃者へ送信 (加工されることも)| A

  • 1. 悪意のあるURLを含むリクエストを送信: 攻撃者はWebアプリケーションの公開されたエンドポイント（例: https://example.com/image?url=...）に対して、内部リソースを指すURL（例: http://localhost/admin またはクラウドのメタデータサービス http://169.254.169.254/latest/meta-data/）をパラメータとして含んだリクエストを送信します。

  • 2. サーバーサイドリクエストの生成: 脆弱なWebアプリケーションは、受け取ったURLを自身のサーバー環境から解決しようとします。

  • 3. 内部ネットワーク/サービスへのアクセス: サーバーは攻撃者の意図しない内部リソース（例: クラウドプロバイダーのメタデータAPIや、内部ネットワーク内の他のサービス）にリクエストを送信します。AWSでは http://169.254.169.254/latest/meta-data/iam/security-credentials/ が一時クレデンシャル取得によく使われるパスです[3]。

  • 4. 機密情報の取得: 内部リソースはリクエストに応答し、インスタンスのロール、シークレット、内部APIのレスポンスなどの機密情報がWebアプリケーションに返されます。

  • 5. 応答の送信: Webアプリケーションは、取得した内部リソースの情報を攻撃者に戻します。これにより、攻撃者は直接アクセスできない情報や機能にアクセスできるようになります。

誤用例と安全な代替

SSRF脆弱性は、URLを処理する際の不適切な実装によって発生します。

誤用例: ユーザー入力を検証せずにHTTPリクエストを送信するPythonコード

この例では、ユーザーが指定した image_url をそのまま利用して外部リソースを取得しています。攻撃者はこの image_url に内部IPアドレスやメタデータサービスのアドレスを指定することで、SSRF攻撃を仕掛けることができます。

import requests
from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route('/fetch_image')
def fetch_image_unsafe():

    # ユーザーから画像URLを受け取る

    image_url = request.args.get('url')
    if not image_url:
        return "URL is missing", 400

    try:

        # **脆弱な実装**: URLの検証が不十分なままリクエストを送信


        # 攻撃者は 'url=http://169.254.169.254/latest/meta-data/iam/security-credentials/...'


        # のように指定して、クラウドのメタデータサービスにアクセス可能

        response = requests.get(image_url, timeout=5)
        response.raise_for_status() # HTTPエラーが発生した場合に例外を発生させる

        # 画像データを返す（例としてそのまま返す）

        return response.content, response.headers['Content-Type']
    except requests.exceptions.RequestException as e:
        return f"Error fetching image: {e}", 500
    except Exception as e:
        return f"An unexpected error occurred: {e}", 500

if __name__ == '__main__':
    app.run(debug=True, port=5000)

  • 前提: Flaskアプリケーションが動作している環境。

  • 入力: GET /fetch_image?url=<任意のURL>

  • 出力: 指定されたURLの内容、またはエラーメッセージ。

  • 計算量/メモリ: URLの内容の取得にかかる時間とメモリに依存。

安全な代替: URLを厳格に検証してからHTTPリクエストを送信するPythonコード

安全な実装では、ユーザー入力のURLを厳格に検証し、許可されたスキーム、ドメイン、IPアドレスの範囲内でのみリクエストを許可します。

import requests
from flask import Flask, request, jsonify
from urllib.parse import urlparse
import ipaddress

app = Flask(__name__)

# 許可されたスキームとホストを定義するホワイトリスト

ALLOWED_SCHEMES = ['http', 'https']
ALLOWED_DOMAINS = ['example.com', 'anothersafehost.org'] # 外部の安全なドメイン

# プライベートIPアドレス範囲

PRIVATE_IP_RANGES = [
    ipaddress.ip_network('10.0.0.0/8'),
    ipaddress.ip_network('172.16.0.0/12'),
    ipaddress.ip_network('192.168.0.0/16'),
    ipaddress.ip_network('127.0.0.0/8') # ループバックアドレス
]

def is_safe_url(url_string):
    """
    URLが安全なスキーム、ドメインを使用し、プライベートIPを指していないか検証する。
    """
    try:
        parsed_url = urlparse(url_string)

        # 1. スキームの検証

        if parsed_url.scheme not in ALLOWED_SCHEMES:
            return False

        # 2. ホスト名の検証 (ホワイトリスト、または外部ホストのみ許可)


        # ドメインホワイトリスト方式が最も安全

        if parsed_url.hostname not in ALLOWED_DOMAINS:

            # ここでさらに、ホスト名を解決してIPアドレスをチェックする


            # DNSリバインディング攻撃対策のため、名前解決後のIPもチェックが望ましい

            try:
                ip_address = ipaddress.ip_address(parsed_url.hostname)
                for private_range in PRIVATE_IP_RANGES:
                    if ip_address in private_range:
                        return False # プライベートIPアドレスはブロック
            except ValueError:

                # ホスト名がIPアドレスでない場合（DNS名の場合）


                # ドメインがホワイトリストにない場合は、さらにDNS解決後のIPも確認すべきだが、


                # ここでは簡略化し、ホワイトリスト外のドメインは原則ブロック


                # もしくは、DNS解決結果のIPアドレスがプライベートIPでないことを確認


                # 多くのライブラリはこれを自動で行わないため、手動での名前解決とIPチェックが必要


                # ただし、DNSリバインディングは名前解決タイミングでIPが変わるため難しい。


                # 基本的には、信頼できるホスト名のホワイトリストが最も効果的。

                pass # ホスト名がIPアドレスでなく、ホワイトリスト外の場合、追加のセキュリティチェックが必要

        # その他のポートやパスの検証も追加可能

        return True

    except Exception:
        return False # 不正な形式のURLは安全でないと判断

@app.route('/fetch_image_safe')
def fetch_image_safe():
    image_url = request.args.get('url')
    if not image_url:
        return "URL is missing", 400

    # **安全な実装**: URLを厳格に検証

    if not is_safe_url(image_url):
        return "Unsafe URL detected", 403 # 不安全なURLはブロック

    try:
        response = requests.get(image_url, timeout=5)
        response.raise_for_status()
        return response.content, response.headers['Content-Type']
    except requests.exceptions.RequestException as e:
        return f"Error fetching image: {e}", 500
    except Exception as e:
        return f"An unexpected error occurred: {e}", 500

if __name__ == '__main__':
    app.run(debug=True, port=5001)

  • 前提: Flaskアプリケーションが動作している環境。ipaddressモジュールを使用。

  • 入力: GET /fetch_image_safe?url=<検証対象URL>

  • 出力: 検証を通過したURLの内容、またはエラーメッセージ。

  • 計算量/メモリ: URL検証処理が加わるが、リクエスト内容の取得処理は同等。検証処理はURLの長さに比例。

  • 注意: is_safe_url関数は、ドメイン名をIPアドレスに解決し、それがプライベートIPアドレスではないことを確認するロジックをさらに強化する必要があります。DNSリバインディング攻撃を完全に防ぐには、名前解決後のIPアドレスを常に検証し、信頼できる公開DNSサーバーを使用するなど、より高度な対策が必要となります。最も堅牢なのは、URLのホストが明示的なホワイトリストに含まれる場合のみ許可する運用です。

検出と緩和策

SSRF攻撃に対する緩和策は、多層的な防御アプローチが効果的です。

1. 入力検証とホワイトリスト化

最も基本的な対策は、ユーザーが提供するURLを厳格に検証することです。

  • ホワイトリスト方式: リクエストを許可するプロトコル（http://, https://のみ）、ドメイン、またはIPアドレスのリストを事前に定義し、それらに一致しないURLは拒否します。これはブラックリスト方式よりもはるかに安全です[2]。

  • スキームとポートの検証: file://, ftp://, gopher:// などの危険なスキームを拒否し、Webサーバーが通常使用しないポート（例: 22/SSH, 3389/RDP）へのアクセスを制限します。

  • IPアドレスの検証: URLのホスト名が解決されたIPアドレスが、プライベートIPアドレス範囲（RFC1918に定義される10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16など）、ループバックアドレス（127.0.0.0/8）、またはリンクローカルアドレス（169.254.0.0/16）を指さないことを確認します。

2. ネットワークレベルの制限

アプリケーション層だけでなく、ネットワーク層でも防御を強化します。

  • ファイアウォール/セキュリティグループ: Webサーバーからのアウトバウンド通信を最小限に制限します。特に、内部ネットワークやクラウドプロバイダーのメタデータサービスへのアクセスを、必要最低限のIPアドレスとポートに限定します[3]。

  • VPCエンドポイント/プライベートリンク: クラウドサービスへのアクセスにパブリックインターネットを経由せず、VPC内部からプライベートにアクセスできる仕組みを利用し、アクセス元IPアドレスを制限します。

3. 認証と認可

クラウド環境では、認証情報を保護することが特に重要です。

  • IMDSv2（Instance Metadata Service Version 2）の利用: AWS IMDSv2は、メタデータへのアクセスにセッションベースの認証を要求します。これにより、SSRF攻撃者が直接トークンを取得することを困難にします[3]。Google Cloud Platformでも、インスタンスメタデータへのアクセスにはサービスアカウントの認証が利用されます[4]。

  • 最小権限の原則: Webサーバーが使用するIAMロールやサービスアカウントには、その機能に必要最小限の権限のみを付与します。

4. プロキシとゲートウェイ

内部リソースへのアクセスを仲介する専用のプロキシを導入することも有効です。

  • 専用プロキシ: 内部リソースへのリクエストをすべてこのプロキシ経由で行わせ、プロキシ側で厳格なホワイトリストとアクセス制御を実施します。これにより、Webアプリケーション自身が内部リソースに直接アクセスする経路を遮断できます。

5. Web Application Firewall (WAF)

WAFは、SSRF攻撃パターンを含む既知の攻撃シグネチャを検出し、ブロックする層として機能します。

  • SSRFルールセット: WAFにSSRF攻撃に特化したルールセットを設定し、不審なリクエスト（例: 169.254.169.254のようなIPアドレスを含むURL）を検知・ブロックします。ただし、WAFはあくまで最後の防衛線であり、アプリケーション自体の脆弱性対策が最も重要です。

運用における注意点と落とし穴

SSRF対策を運用する上で、現場で遭遇しやすい課題と注意点があります。

鍵/秘匿情報の取り扱い

  • 環境変数やシークレットマネージャーの活用: APIキーやデータベース認証情報などの秘匿情報は、ソースコードに直接記述せず、環境変数やAWS Secrets Manager、Azure Key Vault、Google Secret Managerなどの専用サービスを通じて安全に管理します。SSRF攻撃者は、サーバーがアクセスできる環境変数やメタデータからこれらの情報を取得しようとします。

  • 一時クレデンシャルの活用: クラウド環境では、長期的な認証情報ではなく、IAMロールを用いた一時的なセキュリティクレデンシャルを使用することで、万が一漏洩した場合のリスクを低減します。

ローテーションと最小権限

  • 定期的な鍵ローテーション: APIキーやDBパスワードなどは定期的にローテーションし、侵害された場合の被害範囲を限定します。

  • 最小権限の原則の徹底: 各サービスやコンポーネントには、その機能遂行に必要不可欠な最小限の権限のみを付与します。Webサーバーがメタデータサービスにアクセスする必要がある場合でも、必要最低限の情報（例: ロールの一時クレデンシャルのみ）しか取得できないように制限することが重要です。

監査とログ監視

  • 詳細なログ取得: Webサーバー、WAF、クラウドの各種サービス（VPC Flow Logs, CloudTrail, Cloud Loggingなど）で、送受信されるリクエストとレスポンスに関する詳細なログを記録します。

  • 異常検知: これらのログをSIEM（Security Information and Event Management）ツールやログ分析サービスに集約し、内部IPアドレスへのアクセス試行、異常なリクエストパターン、認証情報の頻繁な取得試行などをリアルタイムで監視し、アラートを発する体制を構築します。JSTで2024年5月10日現在、これらのログ監視はセキュリティ運用において不可欠です。

誤検知と検出遅延、可用性とのトレードオフ

  • 誤検知（False Positive）: 厳格な入力検証やWAFルールは、正規のユーザーリクエストを誤ってブロックし、サービスの可用性を損なう可能性があります。特に、新しい機能追加や外部サービス連携の際に、ホワイトリストの更新漏れがないか注意が必要です。

  • 検出遅延（Detection Latency）: ログ監視やアラート設定が不十分な場合、SSRF攻撃が発生してもその検知に時間がかかり、被害が拡大する恐れがあります。リアルタイムに近い検知と対応が求められます。

  • 可用性とのトレードオフ: セキュリティ対策を強化することは、システムのパフォーマンスや開発の柔軟性に影響を与える可能性があります。セキュリティと可用性・利便性のバランスを考慮し、リスク評価に基づいて適切な対策を選択することが重要です。

  • 巧妙な回避技術: 攻撃者は、IPアドレスのエンコーディング（10進数、8進数、16進数、IPv6ショートハンド）、DNSリバインディング、URLリダイレクトなどを利用して、フィルタリングを回避しようとします。対策はこれらの回避技術にも対応できるよう、継続的に見直しが必要です。

まとめ

SSRF攻撃は、Webアプリケーションの脆弱性を足がかりに、内部ネットワークやクラウド環境の機密情報にアクセスする強力な脅威です。この攻撃からシステムを保護するためには、単一の対策に依存するのではなく、入力検証の強化、ネットワークレベルでのアクセス制限、認証認可の適切な設定、そして継続的なログ監視と監査といった多層的な防御アプローチが不可欠です。

特にクラウド環境では、IMDSv2の採用やIAMロールによる最小権限の徹底が、SSRF攻撃による被害を大きく軽減します。開発段階からセキュリティを考慮した設計（Security by Design）を心がけ、運用においても継続的な見直しと改善を行うことが、現代のWebアプリケーションセキュリティにおいて極めて重要であると、JSTで2024年5月10日に改めて強調します。

参考文献

[1] OWASP Foundation. “Server-Side Request Forgery (SSRF)”. OWASP Top Ten 2021. 発表日: 2021年9月29日 (JST). https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2021/A07_2021-Server-Side_Request_Forgeries_%28SSRF%29 [2] PortSwigger. “Server-Side Request Forgery (SSRF)”. Web Security Academy. 発表日: 不明（継続的に更新される情報）. https://portswigger.net/web-security/ssrf [3] AWS Security Blog. “Mitigating Server-Side Request Forgery (SSRF) Attacks”. 発表日: 2022年4月11日 (JST). https://aws.amazon.com/jp/blogs/security/mitigating-server-side-request-forgery-ssrf-attacks/ [4] Google Cloud Architecture Center. “Securing applications from server-side request forgery (SSRF)”. 発表日: 2023年10月11日 (JST). https://cloud.google.com/architecture/securing-applications-from-server-side-request-forgery-ssrf?hl=ja

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました