今回のラボ「Blind SSRF with out-of-band detection」では、Refererヘッダーに含まれるURLをサーバー側が取得する仕組みを利用し、Blind SSRF（見えないSSRF）を検証します。
通常のSSRFとは異なり、レスポンスが返ってこないため、外部サーバーを使った「OAST（Out-of-band Application Security Testing）」による検知が必要になります。
SSRFの基本的な仕組みについては、こちらの記事で解説しています。
このラボの脆弱性ポイント
このラボでは、以下の挙動を利用します。
- 商品ページを開く
- RefererヘッダーのURLをサーバー側の解析ツールが取得する
つまり、ユーザーが指定したURLに対して、サーバーが裏でアクセスを行います。
攻撃の流れ｜Burp SuiteでBlind SSRFを検証する方法
① 通常リクエストを取得
商品ページにアクセスし、リクエストをBurp Suiteでキャプチャします。
② Refererを書き換える
元のRefererを、Burp Collaboratorで生成したドメインに変更します。
Referer: http://xxxx.burpcollaborator.net③ リクエスト送信
Repeaterからリクエストを送信します。
④ 外部通信を確認
Burp Collaboratorで「Poll now」を実行します。
⑤ SSRF成立
以下のような通信が確認できます。
- DNSリクエスト
- HTTPリクエスト
これにより、アプリケーションが外部URLにアクセスしたことが分かります。
OASTによる検知の仕組み
Blind SSRFはレスポンスが見えないため、通常の方法では確認できません。
そこで使われるのがOAST（Out-of-band Application Security Testing）です。
OASTでは、攻撃者が用意した外部サーバーを使って、アプリケーションの挙動を観測します。
今回のラボでは、以下のような流れになります。
攻撃者 → アプリ → 外部サーバー（Collaborator）
ユーザーが指定したURLに対して、アプリケーションが裏でHTTPリクエストを送信します。
その通信を外部サーバー側で受信することで、SSRFの成立を確認できます。
なぜこれで検知できるのか
通常のSSRFでは、レスポンスに内部データが返ってきます。
しかしBlind SSRFでは、レスポンスは返ってきません。
その代わりに、
- DNSリクエストが発生する
- HTTPリクエストが発生する
といった「外向きの通信」が発生します。
この通信を観測することで、Blind SSRFを検知できるのがOASTの特徴です。
DNSリクエストだけ発生する理由
実際の検証では、以下のようなケースがよくあります。
- DNSリクエストは来る
- HTTPリクエストは来ない
これは、サーバーがURL解決までは行ったものの、HTTP通信がネットワークレベルでブロックされたためです。
多くの環境ではDNS通信は許可されているため、この挙動は珍しくありません。
DNSだけでもSSRFの可能性は十分にあります。
WordPressで考えるBlind SSRF｜外部URL取得機能のリスク
この挙動は、WordPressでも十分に起こり得ます。
特に以下の機能は注意が必要です。
OGP取得機能
記事内のリンクからタイトルや画像を取得する処理。外部URLにアクセスする。
RSSフィード読み込み
外部サイトのRSSを取得して表示するプラグイン。指定URLにアクセスする。
Webhook・外部連携
API連携や通知処理。ユーザー入力を含むURLにアクセスする場合がある。
アクセス解析・リンク解析
今回のラボと同様にRefererを元に外部ページへアクセスする可能性。
※ WordPressの基本的なセキュリティ対策はこちらでまとめています。
▶ WordPressのセキュリティ対策は何からやるべきか│初心者向けに最低限の設定を解説
攻撃が成立する条件
以下の条件が揃うと危険です。
- ユーザー入力がURLとして扱われる
- サーバー側でHTTPリクエストが発生する
- 入力値の検証が不十分
外部URL取得機能に潜むリスクと対策（SSRF対策）
外部URLの制限
- ホワイトリスト方式を採用
- 任意のURLを受け付けない
内部IPのブロック
- 127.0.0.1
- 169.254.169.254（クラウドメタデータ）
などへのアクセスを禁止
DNSリバインディング対策
- 解決後のIPもチェックする
Refererを信用しない
Refererは簡単に改ざん可能なヘッダーです。
外部アクセスのトリガーとして利用するのは危険です。
WordPressセキュリティ診断で確認すべきポイント
WordPressでは、プラグインやテーマの機能によって外部URLへリクエストが送信されるケースが多くあります。
これらの処理に不備があると、Blind SSRFの攻撃対象になる可能性があります。
セキュリティ診断では、以下のポイントを重点的に確認します。
外部URLを受け取る機能の有無
まず確認すべきは、ユーザー入力がURLとして扱われている箇所です。
例
- OGP取得機能
- RSSフィード読み込み
- API連携
- Webhook機能
これらはすべて、サーバー側でHTTPリクエストが発生します。
URLの検証が行われているか
以下のようなチェックが実装されているか確認します。
- 任意のURLをそのまま受け付けていないか
- ホワイトリスト制御があるか
- スキーム（http / https）の制限
入力値をそのまま使用している場合、SSRFのリスクが高くなります。
内部IPへのアクセス制御
特に重要なのが、内部リソースへのアクセス制御です。
ブロック対象例
- 127.0.0.1（localhost）
- 169.254.169.254（クラウドメタデータ）
- 10.x.x.x / 192.168.x.x などのプライベートIP
これらにアクセスできる場合、重大な情報漏えいにつながります。
DNS解決後のIPチェック
ドメインベースの制限だけでは不十分です。
- DNSリバインディング対策があるか
- 解決後のIPアドレスが内部IPになっていないか
このチェックがないと、制限をバイパスされる可能性があります。
Refererやヘッダーの利用方法
Refererはユーザーが自由に改ざん可能なヘッダーです。
- Refererを元に外部アクセスしていないか
- ログ解析やOGP取得に使われていないか
今回のラボのように、Blind SSRFの入口になるケースがあります。
非同期処理・バックグラウンド処理
Blind SSRFは非同期処理と相性が良い脆弱性です。
- キュー処理
- cron処理
- 外部連携処理
これらがユーザー入力を元に動作している場合、注意が必要です。
エラーレスポンスの違い
Blind SSRFでは、レスポンスに変化が出ないことが多いですが、
- レスポンス時間の変化
- エラー内容の違い
から挙動を推測できる場合があります。
まとめ
- Blind SSRFはレスポンスが見えないため発見が難しい
- OAST（外部観測）によって検知する
- Refererヘッダーも攻撃ベクトルになる
- WordPressでも外部取得機能は要注意