SSRF脆弱性の隠れた攻撃対象を見つける方法

Hello there, ('ω')ノ

SSRF（Server-Side Request Forgery）脆弱性の多くは、リクエストパラメータにURLが含まれているため比較的見つけやすい ですが、すべてのケースが明確に露出しているわけではありません。
一部のSSRFは 隠れた攻撃対象（Hidden Attack Surface） を持っており、見つけるのが難しい場合があります。

1. SSRFの隠れた攻撃対象とは？

通常のSSRFは、ユーザーがURLを直接入力できるパラメータ（例：stockApi=http://example.com） で見つかることが多いです。
しかし、アプリケーションの内部動作や予期しない入力処理 によって、以下のような 見つけにくいSSRFのエントリーポイント が存在します。

🔹 隠れたSSRFの例

攻撃対象	説明
Refererヘッダー	外部のトラフィックを分析するために、バックエンドがRefererを解析し、リクエストを送信する場合がある
JSON・XMLのフィールド	JSONやXMLのリクエストパラメータ内にURLを含むフィールドがあり、バックエンドがリクエストを実行する場合がある
カスタムヘッダー（X-Forwarded-Forなど）	SSRFを誘発する可能性のあるヘッダーがアプリケーション内部で使用されている場合がある
画像やメディアの自動取得	URLを指定すると、サーバーがそのリソースを取得しようとする機能がある
OAuth/OpenID ConnectのリダイレクトURL	認証処理の中で外部サイトへリクエストを送る機能が悪用される可能性がある
WebhookやAPI統合	サードパーティとの連携機能がリクエストを実行する可能性がある

2. 隠れたSSRFエントリーポイントを探す方法

隠れたSSRFを見つけるには、アプリケーションが「ユーザー入力を使って外部リクエストを発生させる」ポイントを特定する ことが重要です。
以下の手順で アプリケーションの挙動を分析 すると、SSRFを誘発する可能性のあるポイントを見つけやすくなります。

① HTTPリクエストのすべてのパラメータを確認

まず、Burp Suiteなどのツールを使い、リクエスト内のパラメータを精査 します。
特にURLやドメインを指定できるパラメータを探す！

🔹 調査するべきパラメータの例

GET /profile?avatarUrl=http://example.com/avatar.jpg
POST /api/webhook HTTP/1.1
Content-Type: application/json

{
  "webhookUrl": "http://example.com/hook"
}

✅ こうしたURLを含むパラメータは、SSRFの攻撃対象になりやすい！

② Burp Suiteの「Passive Scan」で外部リクエストを探す

Burp Suiteの「HTTP history」を確認し、URLを含むリクエストを探す
特にRefererヘッダーやリダイレクトURLを分析する
「Passive Scan」機能を使い、サーバーが外部リクエストを発生させているか検出

✅ 「Referer」や「Location」ヘッダーが変更可能なら、SSRFの可能性あり！

③ JSON/XMLのペイロードを分析

一部のアプリケーションは、JSONやXML形式のデータを受け取る際に、URLを含むフィールドを処理して外部リクエストを発生させる 可能性があります。
例えば、以下のようなリクエストに注目します。

🔹 JSONリクエストの例

{
  "callbackUrl": "http://example.com/callback"
}

✅ callbackUrl の値を変更し、SSRFが発生するかテスト！

🔹 XMLリクエストの例

<request>
  <imageUrl>http://example.com/image.png</imageUrl>
</request>

✅ XXE（XML外部エンティティ）攻撃と組み合わせると、より強力な攻撃が可能！

④ WebhookやOAuthリダイレクトの挙動を確認

WebhookやOAuth/OpenID Connectの リダイレクトURL が自由に変更可能な場合、SSRFの攻撃対象になり得ます。

🔹 Webhookの例

{
  "webhookUrl": "http://example.com/webhook"
}

✅ この値を攻撃者のBurp Collaboratorドメインに変更し、外部リクエストが発生するか確認！

🔹 OAuthリダイレクトの例

GET /oauth/authorize?redirect_uri=http://evil.com

✅ リダイレクト先を悪意のあるURLに変更し、バックエンドがリクエストを送るか検証！

⑤ 外部リクエストの有無をBurp Collaboratorで確認

Burp Collaboratorを利用し、アプリケーションが外部リクエストを送っているかテスト
変更したURLにBurp Collaboratorのドメインを設定し、HTTPリクエストを発生させる

✅ DNSルックアップやHTTPリクエストが発生すれば、Blind SSRFの可能性あり！

3. まとめ

攻撃対象	調査すべきポイント
Refererヘッダー	外部リクエストを発生させるか確認
JSON/XMLのURLフィールド	`callbackUrl` や `imageUrl` を変更しSSRFをテスト
カスタムヘッダー	`X-Forwarded-For` などが内部リクエストに影響を与えるか
WebhookのURL	URLを変更し、リクエストを監視
OAuth/OpenIDのリダイレクト	`redirect_uri` の値を変更して挙動を確認

🚀 SSRFの攻撃対象は、単なる「URLを入力するパラメータ」だけではない！
🔍 アプリケーションの動作を詳細に分析し、バックエンドが外部リクエストを発生させるポイントを特定しよう！

Best regards, (^^ゞ

Shikata Ga Nai

Private? There is no such things.