Hello there, ('ω')ノ
動画
要点
- Intercept（Proxy）：ブラウザから送られる「そのままの生のリクエスト」をリアルタイムで止めてその場で書き換えられる。ワークフローを崩さずに素早く試せるのでログイン系のワンショット操作に便利。
- Repeater：一度キャプチャしたリクエストを何度でも編集・再送できる。細かい試行錯誤に向くが、ワンタイムトークンやセッション依存のあるリクエストでは注意が必要（トークンの新鮮さを維持する必要がある）。
なぜこのラボで Intercept の方が楽 なのか（具体的理由）
ブラウザ→サーバの“生”リクエストをその場で改変できる
- ログインフォームをブラウザで普通に送信するときに Intercept を有効にしておけば、送信直前にパラメータ（username）を直接書き換えられる。改変後にそのまま forward すれば成功／失敗の挙動をすぐに確認できる。
ワンタイム要素（CSRF トークン、nonce、動的ヘッダ）に強い
- 多くのログイン処理は CSRF トークンや１回限りのパラメータを含む。Intercept だとブラウザが送ろうとしている「最新の（有効な）トークン入りリクエスト」をそのまま改変できるため失敗しにくい。
- Repeater にコピーして使う場合、古いトークンを使ってしまいサーバに弾かれることがある。
操作が一発で済む（手順が短い）
- ブラウザでフォームを送る → Intercept で止める → username を
administrator'--に書き換える → forward - Repeater は「Proxyでキャプチャ → 右クリック → Send to Repeater → Repeater で編集 → Send」といった手順が増える（もちろん慣れれば気にならないが、ラボの指示は最短手順を想定していることが多い）。
- ブラウザでフォームを送る → Intercept で止める → username を
元のブラウザセッションにそのまま結果が反映される
- Intercept ではブラウザ側のセッションやリダイレクトが自然に続くので、ログイン成功後にブラウザで管理者ページに遷移する様子をそのまま見ることができる（確認が楽）。
ただし、Repeater でも可能 なケース・注意点
- Repeater にキャプチャしたリクエストを送り、
usernameをadministrator'--に書き換えてSendすれば SQLi によるログインバイパスは成功することが多いです。 - ただし、必ずブラウザで送られている最新のヘッダ / クッキー / トークンを含めて Repeater に送る必要があります。古いトークンを使うと失敗します。
- Repeater は反復試行（payload を色々変えて試す）に向いているため、探索フェーズでは便利です。
実際の手順（Intercept を使う場合） — 参考（ラボ向け）
1. Burp をプロキシモードで起動し、ブラウザのプロキシ設定を Burp に向ける。 2. Burp の Proxy → Intercept を "On" にする。 3. ブラウザでログインフォームに普通に入力して「Submit」する。 4. Burp がリクエストをキャプチャして止めるので、Proxy → Intercept タブでリクエスト本文を編集する。 例: username=administrator'--&password=anything 5. 編集後、"Forward" を押してサーバに送る。 6. ブラウザでレスポンス（管理者ログイン成功ページ等）を確認する。
実際の手順（Repeater を使う場合） — 参考
1. Proxy の History から該当のログインリクエストを見つける。 2. 右クリック → "Send to Repeater"。 3. Repeater タブで username を administrator'-- に書き換え、"Send" を押す。 4. レスポンスを確認（必要ならブラウザ側でもセッション状態を確認）。
まとめ
- ラボが Intercept を推奨するのは「その場で最新版のリクエストを即改変でき、手順が短く成功しやすい」から。
- 技術的には Repeater でも可能だが、CSRF トークンやセッション、手順の手間を考えると Intercept の方が扱いやすい場面が多い。
Best regards, (^^ゞ
