Hello there, ('ω')ノ
🔍 基本の流れ
💬 通常のリクエスト
GET /userSearch?name=peter&back=/home
→ サーバーが内部で実行するリクエスト（想定）：
GET /users/search?name=peter&publicProfile=true
✅ publicProfile=true によって、公開プロフィールのみが検索可能に制限されている。
🧪 攻撃用リクエスト：%23を使ってトランケーションを試みる
GET /userSearch?name=peter%23foo&back=/home
→ %23 は # のURLエンコードなので、内部でこうなる可能性：
GET /users/search?name=peter#foo&publicProfile=true
🧠 # 以降はフラグメント扱いになり、サーバーに送信されないかもしれない → クエリの途中でトランケーションされる！
🔎 レスポンスの観察で成功の有無を確認する
| 結果 | 意味 |
|---|---|
peter のプロフィールが表示される |
publicProfile=true が無視されて内部APIが切り詰められた可能性あり |
Invalid name などのエラーが出る |
foo も name の一部として扱われた → トランケーションは失敗している可能性 |
| 非公開ユーザーが見える | publicProfile のチェックをバイパスできている！成功！ |
⚠️ 注意点
#を生で入れると意味を持たない
ブラウザが#をフラグメントとして扱い、サーバーに送らない。
✅ 必ず%23としてURLエンコードすること！後ろに文字列（例:
%23foo）をつけると、挙動を観察しやすい
エラーのメッセージなどでサーバーがどこまで解釈したか判断できる。
💥 応用：制限された内部APIパラメータのバイパス
&role=userや&access=limitedのような制限パラメータがある場合、
%23でクエリを切り詰めればそれらを無効化できる可能性があります。
例：
GET /search?query=admin%23foo&role=user
→ role=user がサーバーに届かない可能性！
✅ まとめ：%23トランケーション攻撃のポイント
| テスト項目 | ポイント |
|---|---|
%23 を使った # の注入 |
クエリの途中でトランケーションされるかを試す |
#foo などの文字列を後ろに付ける |
解釈範囲をレスポンスから観察 |
publicProfile のような制限パラメータを切る |
非公開情報のバイパスに使える可能性 |
| エラーメッセージや表示内容を比較 | 成功か失敗かを判断する手がかりになる |
クエリのトランケーションは非常にシンプルな攻撃手法ですが、適切に処理されていない内部APIが相手の場合、重大な情報漏洩につながるリスクがあります。ぜひテスト時のレパートリーに加えておきましょう。
Best regards, (^^ゞ
