Hello there, ('ω')ノ
🧩 概要
多くの開発者は「ユーザーは必ずすべての必須フィールドを入力する」と想定しています。しかし現実には、攻撃者はBurp Suiteなどのツールを使って、HTTPリクエストの途中でパラメータを編集または削除することができます。これは、特に複数の機能が1つのサーバースクリプトで処理されている場合に、重大なロジック脆弱性につながることがあります。
🔍 攻撃者が利用する手法
1. パラメータの削除によるフローのすり抜け
- 攻撃者は、意図的に特定のパラメータ（またはその名前ごと）を削除してサーバーに送信します。
- それにより、サーバーが別の処理パス（通常は到達すべきでない分岐）へ進む可能性があります。
2. 複数ステップのワークフローに影響を与える
- たとえば、ECサイトの購入処理が複数段階で構成されている場合、初期ステップで不正な入力をしたとしても、次のステップでその影響が現れることがあります。
🛠 検証・攻撃手順（Burp Suite を使う場合）
通常通りフォームを送信
- フォームの構造とパラメータを確認するため、まずは通常の手順で送信。
リクエストを Burp でキャプチャ
- Proxy > HTTP history からフォームの POST/GET リクエストを特定。
1つずつパラメータを削除してリクエストを送信
- 値のみを削除 →
param= - パラメータ名ごと削除 → 削除後の挙動の違いに注意。
- 値のみを削除 →
レスポンスの変化を比較
- 処理が実行されてしまったり、意図しないページに遷移するなどの異常が見られたら脆弱性の可能性。
マルチステップの検証
- 最初のステップでのパラメータ変更が後続の処理に影響するかを観察。
✅ チェックポイント
| チェック項目 | 確認内容 |
|---|---|
| 値のみ削除 | サーバーの挙動が変化するか？ |
| パラメータ名ごと削除 | 別の処理パスに進んでいないか？ |
| 後続ステップへの影響 | 入力の省略が他ステップに影響しているか？ |
| Cookie にも注目 | URL/POST以外にCookie中のパラメータも確認する |
🧠 まとめ
「必須パラメータは常に存在する」という思い込みは、攻撃者にとって格好の狙い目です。Burp Suiteなどを使い、パラメータの削除や変更によって発生する異常な動作を観察することで、重大なロジック脆弱性を発見できる可能性があります。
Best regards, (^^ゞ
