SSRF（Server-Side Request Forgery）は、サーバーに意図しないリクエストを送らせる脆弱性です。
一見すると単純な仕組みに見えますが、内部ネットワークへのアクセスや、最終的にはRCE（リモートコード実行）につながる可能性もある危険な攻撃です。
本記事では、Web Security Academyで扱われているSSRFラボをベースに、WordPress視点で攻撃の流れを整理しました。
各攻撃パターンごとに関連記事へリンクしているので、全体像を掴みながら理解を深めていくことができます。
SSRFの基本的な仕組みについては、こちらの記事で詳しく解説しています。
【SSRFの攻撃フロー】
SSRFは単体の脆弱性というより、段階的に発展していく攻撃です。
以下の流れで理解すると、全体像がつかみやすくなります。
ユーザー入力 ↓ サーバーが外部にアクセス（SSRF） ↓ 内部ネットワークへ侵入 ↓ フィルタ回避・別経路の利用 ↓ Blind SSRF（見えない攻撃） ↓ RCE（最終的な侵害）
① 基本のSSRF（攻撃の入口）
最も基本的なSSRFは、ユーザーが指定したURLにサーバーがアクセスしてしまう状態です。
この段階でも、localhostや内部ネットワークにアクセスできるため、十分に危険です。
localhostへのアクセス
▶ WordPressで考えるSSRF│localhostにアクセスする攻撃│Basic SSRF against the local server解説
内部ネットワークへのアクセス
▶ WordPressで考えるSSRF│内部ネットワークをスキャンする攻撃｜Basic SSRF against another back-end system解説
localhostと内部ネットワークの違い
▶ localhostと内部ネットワークの違いとは│初心者向けに図解でわかりやすく解説
② フィルタ回避（バイパス技術）
実際の環境では、ある程度の対策（ブラックリスト・ホワイトリスト）が入っていることが多いです。
しかし、SSRFはURLの解釈の違いを突くことで、これらの対策を回避できます。
ブラックリスト回避
▶ WordPressで考えるSSRF対策の回避テクニック｜ブラックリストでの防御はなぜ破られるのか
ホワイトリストバイパス
▶ WordPressで考えるSSRFホワイトリストバイパス｜URL解釈のズレで内部アクセスが可能になる仕組み
③ 別経路からの侵入（オープンリダイレクト）
直接内部にアクセスできない場合でも、オープンリダイレクトを利用することで、サーバーに内部アクセスをさせることができます。
これは、外部URLに見せかけて内部へ誘導するテクニックです。
オープンリダイレクト経由のSSRF
▶ 【WordPressで考えるSSRF】オープンリダイレクトで内部APIにアクセスする方法｜WSAラボ解説
④ Blind SSRF（見えない攻撃）
Blind SSRFは、リクエストは送られるがレスポンスが見えないタイプのSSRFです。
そのため、攻撃者は外部サーバー（OASTなど）を使って、通信が発生したかどうかを確認します。
Refererヘッダーから発火するSSRF
▶ WordPressで考えるBlind SSRF｜Refererヘッダーから発火する見えない攻撃と検知方法
⑤ SSRFからRCEへ（最終段階）
SSRF単体では情報取得にとどまることも多いですが、他の脆弱性と組み合わせることで、サーバー上でのコマンド実行につながることがあります。
Blind SSRF × Shellshock
▶ WordPressで考えるBlind SSRFとShellshock｜見えない攻撃が内部サーバーに到達する仕組み
攻撃者視点で見るSSRF
SSRFは「サーバーにリクエストを送らせる」だけのシンプルな脆弱性ですが、攻撃者はその先を見ています。
狙いは単なる外部アクセスではなく、サーバーがアクセスできる内部領域です。
内部ネットワークへの侵入
攻撃者がまず狙うのは、localhostや内部IPです。
- 127.0.0.1（localhost）
- 192.168.x.x / 10.x.x.x（内部ネットワーク）
これらは通常、外部から直接アクセスできませんが、SSRFを使えばサーバー経由でアクセスできてしまいます。
管理機能・内部APIの探索
内部にアクセスできるようになると、次に探すのは管理系のエンドポイントです。
- 管理画面（/admin など）
- 内部API
- 開発用エンドポイント
認証が甘い場合や、内部専用前提で設計されている場合、不正操作につながる可能性があります。
クラウドメタデータの取得
クラウド環境では、メタデータサービスが大きな攻撃対象になります。
例えば、サーバーのIAMロール情報や認証トークンが取得できるケースがあります。
これはSSRFの中でも特に深刻な被害につながるポイントです。
ポートスキャン・サービス探索
SSRFは単なるアクセスだけでなく、内部の状態を調べる用途にも使われます。
- 特定ポートが開いているか
- サービスが応答するか
- エラーの違いによる判別
このようにして、内部ネットワークの構造を把握していきます。
見えない攻撃（Blind SSRF）の活用
レスポンスが見えない場合でも、攻撃は止まりません。
- 外部サーバーへの通信（OAST）
- DNSリクエストの発生
- ログの変化
こうした「間接的な証拠」を使って、攻撃の成功を確認します。
SSRFは入口にすぎない
重要なのは、SSRF単体がゴールではないという点です。
攻撃者は以下のように段階的に進めていきます。
- 内部アクセスの確立
- 情報収集
- 脆弱なエンドポイントの発見
- 別の脆弱性と組み合わせる
- 最終的にRCEへ
SSRFは、その最初の足がかりとして使われることが多い脆弱性です。
WordPressで現実に起こるポイント
SSRFは特別な環境だけで発生するものではありません。
WordPressでも、以下のような機能で発生する可能性があります。
- OGP取得機能
- RSSフィード読み込み
- 外部API連携
- Webhook機能
- プラグインの外部通信処理
外部URLをそのまま取得する処理がある場合、それはそのままSSRFの入口になります。
なぜSSRFは危険なのか
SSRFが厄介なのは、以下の特徴を持つためです。
- サーバーの権限で内部にアクセスできる
- 通常の機能に見えるため気づきにくい
- Blind SSRFの場合は結果が見えない
- 他の脆弱性と組み合わせて被害が拡大する
特に見えない攻撃である点が、発見と対策を難しくしています。
セキュリティ診断で見るべきポイント
SSRFの観点でチェックすべきポイントは以下です。
- 外部URLを受け取る機能があるか
- URLのバリデーションが適切か
- 内部IPへのアクセスが制限されているか
- curl / file_get_contents などの使用箇所
- プラグインの外部通信処理
詳細な診断方法については、別記事で解説予定です。
まとめ
SSRFは単純な構造の脆弱性ですが、攻撃が段階的に発展していく点が特徴です。
- 基本SSRFで内部にアクセス
- バイパスで制限を突破
- Blind SSRFで検知を回避
- 最終的にRCEへつながる
WordPressでも外部通信を行う機能は多く、決して他人事ではありません。
本記事で全体像を押さえたうえで、各詳細記事を読むことで、SSRFへの理解をより深められます。
SSRFの基本から理解したい場合は、以下の記事もあわせてご覧ください。