Hello there, ('ω')ノ
🎯 目的
URLエンコードされた & を使って、ユーザーの入力がサーバー内でパースされる際に、“2つ目のパラメータ”として解釈されるかどうかを確認します。
🧪 テスト例：パラメータ注入
📤 攻撃リクエスト：
GET /userSearch?name=peter%26foo=xyz&back=/home
📥 サーバー内部での再構築（想定）：
GET /users/search?name=peter&foo=xyz&publicProfile=true
このように、foo=xyz が新しいパラメータとして意図せず追加されてしまう可能性があります。
🔍 レスポンスから判断するポイント
| 挙動 | 解釈 |
|---|---|
レスポンスが通常通り (peter が表示される) |
foo=xyz は受け入れられたが無視された可能性あり（成功の兆候） |
エラーが発生する (Invalid parameter, Malformed query) |
foo=xyz を処理しようとして失敗 → パラメータ注入成功の可能性大 |
| データの内容や挙動が変わる | foo=xyz が内部処理に影響を与えた可能性あり → 明確なSSPPの兆候 |
🔁 さらに試したいバリエーション
✅ フォーマットをいじる：
name=peter%26publicProfile=false
→ 本来 publicProfile=true が設定されるのを、false に上書きできるか？
✅ 意図的に破損したパラメータ：
name=peter%26=xyz
→ =xyz のようにキーが空の形式でサーバーのパーサーを混乱させる
✅ ブール値や内部制御っぽいパラメータを試す：
name=peter%26debug=true name=peter%26admin=true name=peter%26role=admin
→ 内部で開発用・管理者用の挙動が存在するかを探る
🧠 なぜこの攻撃が有効なのか？
- フロントエンドは
name=peter%26foo=xyzを単なる文字列として扱う - サーバーはURLを構築する際、文字列をそのまま結合してリクエストを生成してしまう
- その結果、新しいパラメータが追加された状態の内部APIリクエストが発生する
✅ まとめ：パラメータ注入のポイント
| テクニック | 効果 |
|---|---|
%26 で & をエンコードして複数パラメータ化 |
新しいパラメータを注入できるか検証 |
| 予期しないパラメータ名（debug, admin）を使う | 内部機能に影響する可能性あり |
| エラー・挙動の変化を丁寧に観察 | 成功のヒントがレスポンスに現れる |
このようなパラメータ注入は、見落とされがちなSSPPの入り口です。特に“パラメータを内部APIにそのまま流用しているアプリ”は要注意。一つの %26 で予想外の挙動を引き起こすこともあるため、細かく検証していきましょう。
Best regards, (^^ゞ
