少しずつ変えて送る — Repeater の発想

1つのリクエストをコピーして、パラメータを少しずつ変えて再送する。診断の基本動作を curl で身につけ、Burp への橋を架けます。

第3章 / 全4章目安約10分この章のゴール: 1リクエストを変えながら繰り返し送る動作を身につけ、次の Burp コースの意味を理解する

診断で穴を見つける動きは、たいてい同じ形をしています。1つのリクエストを送る → 返りを見る → どこかを少し変えて、また送る。この繰り返しです。

変えて、比べる

たとえば「ID を変えたら、他人のデータが見えないか?」を確かめる動作は、こう表せます。

curl -s "http://127.0.0.1:4610/api/notes/1"
curl -s "http://127.0.0.1:4610/api/notes/2"
curl -s "http://127.0.0.1:4610/api/notes/3"

パスの数字だけを変えて、返りを比べます。1 は 200 で中身が返り、2 は 403 で返らない——なら認可が効いています。2 も中身が返る——なら、それが IDOR です(この比較は、旗艦コースで本物のやられに対して実際にやります)。

ヘッダやボディでも同じです。「Cookie を消したら?」「メソッドを変えたら?」「数を負の値にしたら?」——1か所ずつ変えて、返りの違いを読む。これが診断の芯の動作です。

curl でも一つ一つはできます。ただ、リクエストが長く(ヘッダが10行、JSON ボディが複雑)なると、毎回コマンドを組み直すのは大変です。そこで、実務では Burp Suite の Repeater という道具を使います。

Repeater は、一言でいえば「1つのリクエストを画面に置いて、好きな所を書き換えて、送信ボタンで何度も送り直せる場所」です。やっていることは、この章の curl とまったく同じ——変えて、送って、返りを比べる。違うのは、それを GUI で速く快適にできることだけです。

道具が変わっても、考え方は変わりません。手で HTTP を組める人が Repeater を使うと速くなる、というだけです。逆に、手で組めないまま GUI に頼ると、返りの何が変わったのかを読めません。だからこの「手で話す」章を先に置いています。

次のコース「Burp Suite 最初の一歩」で、この Repeater を含む Burp を実際に立ち上げます。多くの人がつまずくのは Burp の機能ではなく、その手前のプロキシと CA 証明書の壁です。そこを1章で越えます。

検査用サーバ(echo.mjs)は、止めておいて大丈夫です(起動中のターミナルで Ctrl+C)。

この章で卒業です。

この章はまだ完了していません。