Hello there, ('ω')ノ
💡 どうしてSSPPが発生するのか？
アプリケーションが外部ユーザーからのリクエストを受け取り、その一部をそのまま内部APIリクエストのパラメータとして埋め込んでいるケースがあります。
例: 通常のフロー
- ユーザーが以下のURLで検索を行う：
GET /search?query=laptop
- サーバー側で内部APIにリクエストを組み立てて送る：
GET /internal/search?q=laptop&type=public
🚨 SSPP攻撃の例
攻撃者が以下のようなリクエストを送信：
GET /search?query=laptop&type=private
アプリケーションがこのtype=privateを適切に処理せず、内部APIにそのまま送ると：
GET /internal/search?q=laptop&type=private&type=public
💥 結果：type=private が type=public より優先され、非公開データが返ってくる可能性
🔍 テスト対象になる入力ポイント
| 入力箇所 | 例 |
|---|---|
| クエリパラメータ | ?id=1&type=admin |
| フォームフィールド | <input name="role" value="user"> |
| ヘッダー | X-User-Role: admin |
| URLパス | /profile/admin?id=123 |
🧪 SSPPのテスト方法
✅ 1. パラメータの重複挿入を試す
?type=public&type=private?user=123&user=456- フォーム内で同じ名前のフィールドを2つ送る
✅ 2. エンコーディングを使ってバイパスを試す
type%3dadmin（%3dは=のURLエンコード）type%3dadmin&type=guesttype=admin%26debug=true（&のURLエンコード）
✅ 3. ヘッダーやCookieにも注入を試す
X-Internal-User: adminCookie: user_id=1; is_admin=true
🧠 SSPPとよくある混同に注意
| 用語 | 内容 |
|---|---|
| Server-side Parameter Pollution | 内部APIに渡す際のサーバー側でのパラメータ注入 |
| HTTP Parameter Pollution | 同じパラメータを複数指定してWAFをバイパスする手法 |
| Server-side Prototype Pollution | JavaScriptオブジェクトの__proto__を汚染する別の脆弱性 |
💡 このトピックでは SSPP = サーバー内でのパラメータ注入 のみに絞って解説します。
✅ まとめ：SSPP対策と実践ポイント
| やること | 内容 |
|---|---|
| ユーザー入力をそのまま内部APIに渡さない | 必ずサニタイズ・エンコード処理を行う |
| 重複パラメータの優先順位を明確にする | 最初の値だけを採用するなどのルールを明示 |
| Burp Intruderでパラメータ汚染テストを実行 | 同名パラメータやエンコード値を大量に試す |
| 内部APIの挙動を観察 | エラーやデータ漏洩が起こっていないかを注意深く確認 |
SSPPは、内部処理の見落としから発生する脆弱性です。ユーザー入力がどのように使われているかを深く理解し、表面的には見えない「裏側の処理」にこそ注目することが、発見の鍵です。
Best regards, (^^ゞ
