Hello there, ('ω')ノ
🧪 テスト対象のリクエスト例
アプリの検索機能が以下のリクエストを発行しているとします：
GET /userSearch?name=peter&back=/home
このリクエストにより、サーバーは内部APIに以下のリクエストを送信：
GET /users/search?name=peter&publicProfile=true
🎯 目的
クエリ文字列に #, &, = などの特殊な記号を挿入して、サーバーが内部APIにリクエストを組み立てる際の処理に影響を与えられるかを確認します。
🧪 テストパターン
✅ ① 追加のパラメータを注入して内部APIに渡るか確認
GET /userSearch?name=peter&publicProfile=false
💡 内部で以下のように構築される可能性：
/users/search?name=peter&publicProfile=false&publicProfile=true
→ publicProfile=false が優先されると、非公開プロフィールにアクセス可能になるかもしれません。
✅ ② エンコードや記号によるパラメータ分離のバイパス
GET /userSearch?name=peter&back=/home&publicProfile=false
または、文字列の途中に & を含む：
GET /userSearch?name=peter&back=/home%26publicProfile=false
📌 %26 は & のURLエンコード → サーバーがそのまま内部APIに渡すと：
/users/search?name=peter&back=/home&publicProfile=false
✅ ③ = を含む値でのパラメータ上書きの可能性を探る
GET /userSearch?name=peter=admin
→ サーバーが以下のように解釈する可能性：
/users/search?name=peter=admin&publicProfile=true
→ 一部のシステムでは peter=admin を key=value として認識し、意図しないパラメータ扱いになることがあります。
✅ ④ # を含めてクエリの途中を打ち切るテスト
GET /userSearch?name=peter#&publicProfile=false
→ # はフラグメント識別子として扱われ、それ以降が無視されるケースもあるが、サーバーが誤って処理すると内部APIリクエストに影響を与える可能性あり。
🔍 結果の観察ポイント
| 観察対象 | 意味 |
|---|---|
| レスポンスの変化 | 検索結果が変わる、詳細データが見えるなどの挙動が変化するか？ |
| エラーメッセージの表示 | クエリ構造の崩壊によるパースエラーが出るか？ |
| リクエストのミラーやデバッグ情報の漏洩 | 内部APIリクエストの構造が見えるヒントになる |
✅ まとめ：クエリ文字列でのSSPPテストのポイント
- 同名パラメータの上書きやバイパスを狙う（例:
publicProfile=false） %26,%3D,%23などのエンコードされた記号を活用する- 内部APIの挙動やレスポンスの変化を観察して、影響の有無を判断する
- Burp Intruderなどでクエリパターンを大量に試すことで精度を上げる
SSPPは見た目では分からない裏側の脆弱性です。「サーバーがその値をどう使っているか？」を想像しながらテストすることが、発見のカギとなります。
Best regards, (^^ゞ
