🎭 サーバーをハッカーの操り人形に！OWASP Top 10、SSRF（サーバーサイドリクエストフォージェリ）攻撃

10月 30, 2026

—

こんにちは！👋 ついにOWASP Top 10 2021攻略シリーズの最終回です。待望の10位は、コミュニティアンケートを通じて新たにランクインした、非常に強力で危険な攻撃であるA10:2021-SSRF（Server-Side Request Forgery、サーバーサイドリクエストフォージェリ）です。

「信頼できる内部の従業員を操って、社長室の秘密文書を盗ませるとしたら？」 🕵️‍♂️ SSRFはまさにこのように、攻撃者が信頼されたサーバーを操り人形のように操り、サーバーが代わりに他の場所に悪意のあるリクエストを送信するように仕向ける攻撃です。これから、私たちのサーバーがどのようにハッカーのスパイになり得るのか、その恐ろしいシナリオを一緒に掘り下げていきましょう！

🤔 SSRF？それは一体何ですか？

SSRF（サーバーサイドリクエストフォージェリ）は、攻撃者がウェブアプリケーションの脆弱性を利用して、サーバーが直接攻撃者が望む任意のURLにHTTPリクエストを送信するように強制する攻撃手法です。

CSRF（クライアントサイドリクエストフォージェリ）と名前が似ているため混同しやすいですが、攻撃の主体が全く異なります。

CSRF (Client-Side): 攻撃者がユーザーのウェブブラウザを騙して、ユーザーが意図しないリクエストを送信させます。（被害者：ユーザー 👤）
SSRF (Server-Side): 攻撃者がウェブサーバー自体を騙して、サーバーが直接他のシステムにリクエストを送信させます。（被害者：サーバーおよび内部ネットワーク 🏠）

サーバーは通常、ファイアウォールの内部に位置し、外部から直接アクセスできない内部システムと自由に通信できます。SSRF攻撃は、この「内部者」としてのサーバーの信頼を悪用するため、非常に危険です。

🕵️‍♂️ SSRF攻撃はなぜそんなに危険なのですか？

サーバーが攻撃者の命令を代わりに実行するようになると、想像以上の被害が発生する可能性があります。

1. 内部ネットワークスキャンおよび情報漏洩 🔥🧱

攻撃者はサーバーをプロキシのように利用して、ファイアウォールの背後に隠された内部ネットワークをスキャンできます。

攻撃シナリオ: 攻撃者は192.168.1.1:8080、10.0.0.5:3306などの内部IPアドレスとポート番号にリクエストを送信するようにサーバーを操ります。サーバーの応答時間やエラーメッセージを通じて、どのポートが開いているか、どのようなサービス（データベース、管理者ページなど）が実行中であるかを把握し、内部システムの地図を作成できます。

2. 内部サービス攻撃 💣

外部に公開されておらず安全だと信じられていた内部サービスを直接攻撃できます。

攻撃シナリオ: 内部からのみアクセス可能な管理者ページ（http://localhost/admin）にサーバーが代わりにアクセスして管理者機能を実行したり、内部APIを呼び出してデータを漏洩させたり、システムを操作したりすることができます。

3. クラウドメタデータ奪取 ☁️🔑 (最も致命的！)

クラウド環境では、SSRFは災害を引き起こす可能性があります。

攻撃シナリオ: AWS、GCP、Azureなどのクラウド環境のサーバー（インスタンス）は、http://169.254.169.254のような特殊な内部IPアドレスを通じて自身のメタデータ（ロール、一時的な認証情報など）にアクセスできます。攻撃者がサーバーを操ってこのアドレスにリクエストを送信させると、一時的なアクセスキー、秘密キーなどの機密性の高い認証情報を奪取できます。これらのキーを手に入れた攻撃者は、当該クラウドアカウントのすべてのリソースを自由に制御できるようになります。

4. ローカルファイルの読み取り 📄

file:///プロトコルを利用して、サーバーのローカルファイルを読み取ることもできます。

攻撃シナリオ: 攻撃者がfile:///etc/passwdやfile:///c:/windows/win.iniのようなパスを入力すると、サーバーがそのパスのファイルを読み取り、その内容を攻撃者に転送できます。

🧰 SSRFの脆弱性はどこで発生しますか？

SSRFは主に、サーバーがユーザーから入力されたURLアドレスに直接接続して何らかの操作を実行する機能で発生します。

URLベースの画像/コンテンツ取得: ユーザーが入力したURLの画像をサーバーが取得して表示する機能。
ウェブフック(Webhook): 特定のイベントが発生したときに、ユーザーが指定したURLに通知を送信する機能。
PDF/ドキュメント変換器: ウェブページのURLを入力として受け取り、そのページをPDFに変換する機能。
リンクプレビュー生成: メッセンジャーやソーシャルメディアでリンクを貼り付けたときに、サーバーがそのURLにアクセスしてタイトル、説明、サムネイルを取得する機能。

🛡️ どうすれば防げますか？ (防御方法)

SSRFを防ぐための核心は、「サーバーが送信するリクエストの宛先を厳格に制御すること」です。

ホワイトリスト（Allow List）ベースのアクセス制御 ✅ (最も重要！) ブラックリスト方式（localhost、127.0.0.1のブロックなど）は迂回されやすいです。サーバーがアクセスできるドメイン、IPアドレス、ポート、プロトコルのリスト（ホワイトリスト）を必ず作成し、このリストにないリクエストはすべてブロックする必要があります。「許可されたもの以外はすべて禁止」が原則です。
入力値の検証とパース 🧐: ユーザーから入力されたURLをそのまま使用してはいけません。URLをパースしてホスト、ポート、パスなどを分離し、各部分がホワイトリストポリシーに準拠しているかを徹底的に検証する必要があります。file:///, ftp:///などの危険なプロトコルは当然禁止すべきです。
リダイレクト(Redirection)の無効化 ↪️➡️❌: 攻撃者は安全なURLを入力した後、危険な内部アドレスにリダイレクトされるように誘導することができます。したがって、サーバーのHTTPクライアントはリダイレクトを追跡しないように設定する必要があります。
ネットワーク隔離とファイアウォール設定 🧱: 外部リクエストを処理するサーバーは、別途隔離されたネットワークに配置し、ファイアウォールを通じて、そのサーバーが必要とする内部システム以外にはアクセスできないようにネットワークポリシーを強化する必要があります。（多層防御）

✨ 終わりに

SSRFは発生頻度は比較的低いかもしれませんが、一度発生するとファイアウォールを無力化し、内部システム全体を危険に陥れるという計り知れない破壊力を持つ攻撃です。「サーバーが外部にリクエストを送る？それがなぜ危険なの？」と安易に考えては絶対にいけません。

私たちのサービスに、ユーザーが入力したアドレスをサーバーが直接訪問する機能があるなら、今すぐその宛先を私たちが完璧に制御しているかどうか、もう一度確認してみましょう。信頼された私たちのサーバーがハッカーのスパイになるのを防がなければなりません！

タグ: OWASP, A10, SSRF, Server-Side Request Forgery, セキュリティ, ウェブ脆弱性, クラウドセキュリティ