Field guide
Burp Suite 101
Several tracks here — SQL injection, SSRF, CSRF and the Modern set — hide the vulnerable input off the on-page form: in a header, a cookie, an extra parameter, the request method, or the server's own response. A form can't reach those. An intercepting proxy can. This is the ten-minute version.
Why a proxy
The browser is not the client — the request is
A web form can only send what its fields allow. The server, though, reads far more: every request header,
your cookies, the HTTP method, the Content-Type, the raw body, and any parameter — whether or
not a field exists for it. An intercepting proxy sits between your browser and the site so you can read and
rewrite the actual bytes on the wire before they arrive — and rewrite the response before your browser
sees it.
Set it up once
Run Burp's listener
Community Edition is free and enough for everything here. By default Burp listens on
127.0.0.1:8080 (Proxy → Proxy settings).
Send traffic through it
Use Burp's built-in browser (Proxy → Intercept → Open browser), or point your own at
127.0.0.1:8080 with a switcher like FoxyProxy.
Trust the CA for HTTPS
Browse to http://burp and install its CA certificate so HTTPS pages stop warning. Plain
HTTP (e.g. http://localhost:8000) needs no certificate at all.
Watch the history
Open any lab and look under Proxy → HTTP history. If your requests show up there, you are wired up correctly.
The core loop
Pause a request
With Proxy → Intercept on, submit the form. Burp holds the request so you can edit any line — a header, a parameter, the method — then Forward it.
Edit & resend
Right-click a request → Send to Repeater (Ctrl‑R). There you can tweak it and hit Send again and again — ideal for iterating a payload one character at a time.
Rewrite what comes back
Enable intercept responses (Proxy settings) to edit the server's reply before the page reads it — the whole trick behind the response-tampering lab.
Where the labs hide the input
Each converted lab moves the exploit onto one of the channels below. The lab's own hint tells you
which channel — never the payload. Here is what each looks like in a raw request; the walkthroughs
carry the exact payload and a copy-paste curl line.
Header injection
Add or rewrite a header the app trusts — Host, X-Forwarded-Host,
X-Forwarded-For, User-Agent, Referer.
GET /labs/misc/12/ HTTP/1.1 Host: localhost:8000 X-Forwarded-Host: evil.example <-- the line you add
Extra / hidden parameter
The form posts a tidy set of fields; the handler quietly honours one more. Add it to the body yourself.
POST /labs/misc/14/ HTTP/1.1 Content-Type: application/x-www-form-urlencoded email=you@cspshivam.com&frequency=weekly&internal_access=1
Method / Content-Type
A hardened HTML form can sit in front of an unhardened JSON API on the same URL. Change the body type and you reach a different code path.
POST /labs/misc/11/ HTTP/1.1
Content-Type: application/json
{"username":"admin'-- -","password":"x"}
Cookie
Some state lives in a cookie the UI never exposes — a role, a signed token. Edit it in place on the request.
GET /labs/misc/5/ HTTP/1.1 Cookie: session=eyJhbGciOiJub25lIn0.eyJyb2xlIjoiYWRtaW4ifQ. (illustrative — forge your own)
Response tampering
The server returns a verdict; the client trusts that string. Flip it on the way back and the gate opens.
HTTP/1.1 200 OK
Content-Type: application/json
{"entitlement":"granted"} <-- was "denied"
No proxy handy?
curl speaks the same protocol
Every channel above is just an HTTP request, so curl reproduces it — a header override, an
extra field, a JSON body, a cookie. The walkthroughs give a ready one-liner for each lab. For example:
curl -s http://localhost:8000/labs/misc/4/ -H 'User-Agent: {{secret}}'
A proxy is still worth learning: it shows you the whole request and response, lets you iterate in Repeater, and is how you would work against a real target.