SSRFとは？サーバーサイドリクエストフォージェリの仕組み・被害例・対策をわかりやすく解説

「外部からアクセスできないはずの社内システムに、なぜか不正アクセスされた」「クラウドのメタデータが漏れて、認証情報が盗まれた」――こうした事故の原因として近年急増しているのが、SSRF（サーバーサイドリクエストフォージェリ）という攻撃手法です。

SSRFは、Webアプリケーションのサーバーを踏み台にして、本来アクセスできない内部ネットワークやクラウドのメタデータAPIに不正なリクエストを送信させる攻撃です。2021年にはOWASP Top 10の新カテゴリとして追加され、クラウド環境が普及した現在、もっとも警戒すべき脆弱性の一つとされています。

この記事では、SSRFの仕組み・被害パターン・具体的な防御策について、サーバー設定やアプリケーション実装のレベルで解説します。

SSRFとは？なぜ今この脆弱性が注目されるのか

SSRF（Server-Side Request Forgery: サーバーサイドリクエストフォージェリ）とは、攻撃者が「サーバーに代わりにリクエストを送らせる」攻撃手法です。日本語に訳すと「サーバー側のリクエスト偽造」となります。

通常のWebアプリケーションでは、サーバーがユーザーの指定したURLにHTTPリクエストを送信する機能があります。外部APIの呼び出し、画像のプレビュー取得、URLの存在確認、Webhook通知など、正当な用途は多岐にわたります。SSRFはこの「サーバーが外部にリクエストを送る機能」を悪用します。

SSRFが注目される背景には3つの要因があります。

・クラウド環境のメタデータAPI: AWS・GCP・Azureなど主要クラウドには、インスタンスのメタデータを返す内部APIエンドポイント（例: 169.254.169.254）がある。SSRFでこのAPIにアクセスされると、IAMの一時的な認証情報が漏洩する
・マイクロサービスの普及: 内部のマイクロサービス同士はファイアウォールの内側で通信するため認証が省略されていることが多い。SSRFで内部サービスに直接アクセスされると、認証なしで操作が実行される
・OWASP Top 10 2021で新規追加: SSRFはOWASP Top 10:2021のA10に新規カテゴリとして追加された。従来は他の脆弱性と比べて軽視されがちだったが、クラウド環境での被害拡大を受けて独立項目となった

CSRFが「ユーザーのブラウザを騙して、ユーザーの権限でリクエストを送らせる攻撃」であるのに対し、SSRFは「サーバーを騙して、サーバーの権限でリクエストを送らせる攻撃」です。サーバーは内部ネットワークにアクセスできる立場にあるため、攻撃が成功した際の被害範囲はCSRFよりも広くなりがちです。

攻撃の仕組み ― SSRFはどのように成立するのか

SSRFの攻撃フローを具体的に見ていきましょう。

1. 外部リソースを取得する機能を特定する

攻撃者は、Webアプリケーションの中で「ユーザーが指定したURLにサーバーがリクエストを送る機能」を探します。代表的な対象はこのような機能です。

・URLプレビュー: チャットやSNSでURLを貼り付けるとOGP情報やサムネイルを取得する機能
・画像取得: 外部URLから画像をダウンロードしてサーバーに保存する機能
・Webhook設定: ユーザーが指定したURLにイベント通知を送信する機能
・PDF生成: HTMLやURLを指定するとPDFに変換する機能
・API連携: ユーザーが入力したAPIエンドポイントにリクエストを送る機能

2. 内部向けURLを入力する

攻撃者は、本来外部に公開されていない内部向けURLをパラメータに指定します。たとえば以下のようなリクエストを送ります。

# 正常なリクエスト（外部の画像URL）
GET /api/fetch?url=https://example.com/image.png

# SSRFを狙ったリクエスト（内部のメタデータAPI）
GET /api/fetch?url=http://169.254.169.254/latest/meta-data/

# SSRFを狙ったリクエスト（内部サービスへのアクセス）
GET /api/fetch?url=http://localhost:8080/admin/

3. サーバーが内部リソースにアクセスしてしまう

Webアプリケーション側でURLの検証が不十分だと、サーバーは指定されたURLに対してそのままリクエストを送信します。サーバーは内部ネットワーク上に存在するため、ファイアウォールの内側にあるリソースにもアクセスできてしまいます。

クラウド環境では、メタデータAPIから取得したIAMの一時認証情報を使って、S3バケットの中身を丸ごとダウンロードしたり、データベースに接続したりといった二次被害に発展するケースが報告されています。

SSRFで発生する具体的な被害

SSRFによる被害は、サーバーからアクセスできるすべてのリソースが対象になり得ます。代表的な被害パターンを見てみましょう。

2019年に発生した大手金融企業の大規模情報漏洩事件では、SSRFを起点にクラウドのメタデータAPIからIAM認証情報が窃取され、1億件以上の顧客データが流出しました。この事件はSSRFの危険性を世界に知らしめ、OWASP Top 10への追加を後押しする大きなきっかけとなりました。

具体的な防御手順

SSRFの防御は「サーバーが送信するリクエストの宛先を制限する」ことが基本です。アプリケーション層・ネットワーク層の両方で多層的に対策を講じることが重要です。

1. URLの入力値を厳格に検証する（アプリケーション層）

ユーザーから受け取ったURLに対して、以下の検証を行います。

・許可リスト方式: アクセスを許可するドメインやIPアドレスの範囲をあらかじめ定義し、それ以外は拒否する。拒否リスト（ブラックリスト）方式はバイパスされるリスクが高いため推奨しない
・スキームの制限: httpとhttpsのみを許可し、file://・gopher://・dict://などの危険なスキームを拒否する
・プライベートIPアドレスの拒否: 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（リンクローカル）を拒否する
・DNS解決後のIPアドレスも検証する: ドメイン名を解決した結果がプライベートIPでないことを確認する。DNS Rebinding攻撃を防ぐため、名前解決とリクエスト送信の間にIPアドレスが変わらないよう対策する

Pythonでの検証例です。

# PythonでのSSRF対策例（概念コード）
import ipaddress
from urllib.parse import urlparse
import socket

def is_safe_url(url):
    parsed = urlparse(url)

    # スキームをhttp/httpsに制限
    if parsed.scheme not in ('http', 'https'):
        return False

    # ホスト名を解決してIPアドレスを取得
    try:
        ip = ipaddress.ip_address(
            socket.gethostbyname(parsed.hostname)
        )
    except (socket.gaierror, ValueError):
        return False

    # プライベートIPアドレスを拒否
    if ip.is_private or ip.is_loopback or ip.is_link_local:
        return False

    return True

2. クラウドのメタデータAPIを保護する（クラウド層）

クラウド環境では、メタデータAPIへのアクセスを制限する設定が用意されています。

AWSの場合、IMDSv2（Instance Metadata Service v2）を強制する設定が有効です。IMDSv2ではPUTメソッドでトークンを取得し、そのトークンをヘッダーに含めてメタデータにアクセスする方式になります。SSRFで悪用されやすい単純なGETリクエストではメタデータを取得できなくなります。

# AWS CLI: IMDSv2を強制する設定
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

GCPではメタデータリクエストに「Metadata-Flavor: Google」ヘッダーが必須であり、デフォルトでSSRFに対する一定の保護が働きます。ただし、アプリケーションが任意のヘッダーを送信できる場合はこの保護をバイパスされるため、ネットワーク制御と組み合わせることが重要です。

3. ネットワーク層で制限をかける（ネットワーク層）

Webアプリケーションサーバーから内部ネットワークへの通信をファイアウォールで制限します。

・アウトバウンド通信の制限: Webサーバーからの外部通信はプロキシサーバー経由に制限し、プロキシでプライベートIPへのアクセスを遮断する
・セグメンテーション: 管理系のサービス（データベース・キャッシュ・管理画面）をWebサーバーとは別のネットワークセグメントに配置し、必要最小限のポートのみ通信を許可する
・メタデータエンドポイントのブロック: iptablesやセキュリティグループで、Webサーバーから169.254.169.254へのアクセスを明示的にブロックする

# iptables: メタデータAPIへのアクセスをブロック
# Webサーバーのユーザー（www-data）からの通信を遮断
sudo iptables -A OUTPUT -m owner --uid-owner www-data \
  -d 169.254.169.254 -j DROP

中小企業でも今日からできること

SSRFの対策は「外部URLを取得する機能があるかどうか」をまず棚卸しすることから始まります。情シス1人体制の中小企業でも、段階的に取り組める対策を整理しました。

WordPressなどのCMSを利用している場合は、プラグインやテーマの中にURLフェッチ機能が含まれていることがあります。利用しているプラグインの一覧を確認し、不要なものを無効化することもSSRFの攻撃面を減らす有効な手段です。

よくある誤解と注意点

【注意】「ファイアウォールがあるから内部は安全」は危険な思い込み

SSRFの本質は「ファイアウォールの内側にいるサーバーを踏み台にする」ことです。外部からの直接アクセスはファイアウォールで遮断できても、内部のWebサーバーからのリクエストは許可されているケースが大半です。ファイアウォールの存在だけでは、SSRFを防ぐことはできません。「内部だから安全」という前提を捨て、内部サービス同士でも認証を設けるゼロトラストの考え方が重要です。

【注意】「拒否リスト方式」だけではバイパスされる

「127.0.0.1や169.254.169.254を拒否リストに入れれば十分」と考えるのは危険です。攻撃者はURLエンコード（%31%32%37%2e%30%2e%30%2e%31）、IPv6表記（[::1]）、10進数表記（2130706433）、リダイレクトを利用した間接アクセスなど、さまざまな手法で拒否リストを迂回します。許可リスト方式を基本とし、DNS解決後のIPアドレスも含めた検証が必要です。

【注意】「レスポンスを返さなければ安全」ではない

SSRFの中には、リクエストの結果（レスポンス）が攻撃者に直接返されない「Blind SSRF」と呼ばれるパターンがあります。レスポンスが見えなくても、リクエストが送信される時点で内部サービスへの操作が実行される可能性があります。応答時間やエラーメッセージの違いを手がかりに情報を推測するテクニックも存在するため、レスポンスの非表示だけで安全とは言えません。

本記事のまとめ

SSRFは、Webアプリケーションのサーバーを踏み台にして内部ネットワークやクラウドのメタデータAPIに不正アクセスする攻撃手法です。クラウド環境やマイクロサービスアーキテクチャの普及に伴い、被害リスクは年々高まっています。OWASP Top 10:2021でも独立したカテゴリとして新規追加されました。

防御の基本は、アプリケーション層でのURL検証（許可リスト方式＋DNS解決後のIP検証）とネットワーク層での通信制限を組み合わせた多層防御です。クラウド環境ではIMDSv2の強制やメタデータエンドポイントへのアクセスブロックも必須の対策となります。

SSRFと併せて押さえておきたいCSRFやSQLインジェクションの対策については、本サイトの関連記事で詳しく解説しています。Webアプリケーションの脆弱性は複数の攻撃手法が連鎖して大きな被害につながるため、横断的に理解しておくことが重要です。

ファイアウォールやネットワークセグメンテーションの基礎、Linuxサーバーのセキュリティ強化については、姉妹サイトLinuxMaster.JPで詳しく解説しています。