Hello there, ('ω')ノ
🎯 目的
ユーザーが本来制御できない内部パラメータ（例：email など）を、エンコードした &（%26）を使ってリクエスト中に追加することで、サーバー側のAPIリクエストに余分なデータを差し込む。
📥 攻撃リクエスト例
GET /userSearch?name=peter%26email=foo&back=/home
→ サーバー内部では次のように解釈される可能性：
GET /users/search?name=peter&email=foo&publicProfile=true
👉 email=foo が本来ユーザーに設定されるべきでないフィールドとしてサーバーに送られている！
🧪 注入する“有効な”パラメータを見つけるには？
- GET
/users/123のようなレスポンスで出てくるフィールド名をチェック
例:json { "id": 123, "name": "John Doe", "email": "john@example.com", "role": "user", "isAdmin": false }
✅ この場合の注入候補：
- email
- role
- isAdmin
- id
🧪 テスト手順
✅ ① 有効な値を追加
GET /userSearch?name=peter%26email=test@evil.com&back=/home
→ emailパラメータが内部APIのフィルターや照合に影響していないかを確認。
✅ ② 値を不正にして影響を試す
GET /userSearch?name=peter%26role=admin
→ role=admin によって 本来表示されない管理者アカウント が出てくるかもしれない。
✅ ③ 複数パラメータの連続注入
GET /userSearch?name=peter%26isAdmin=true%26email=admin@example.com
→ すべての値が連携して 挙動やレスポンスが変わるかを確認。
🔍 レスポンスの観察ポイント
| 挙動 | 解釈 |
|---|---|
| エラーが発生しない | パラメータがサーバーに受け入れられている可能性が高い |
| 表示内容に変化がある | パラメータが処理に影響している明確な証拠 |
| 想定外のユーザーが表示される | フィルターバイパス成功の兆候 |
| メールアドレスを使って直接ユーザー情報が表示される | 内部APIの照合条件にヒットしている可能性あり |
✅ まとめ：有効パラメータ注入のポイント
| テクニック | 狙い |
|---|---|
%26param=value を使って内部APIに有効なパラメータを追加 |
データ取得や挙動のバイパスを狙う |
| GETレスポンスで出てくるフィールド名を参考にする | 注入対象のパラメータ候補を絞り込む |
| エラーが起きず、内容が変化する場合は成功の可能性 | パラメータが影響している証拠 |
このようなSSPPの活用は、本来アクセスできない内部APIの機能を外部から操作するための強力な攻撃手法です。特に有効パラメータが見つかった場合、その影響範囲をしっかりテストしておきましょう。
Best regards, (^^ゞ
