The most surprising thing about Burp Suite in CTFs is how often its core, free functionality is all you need to dominate, despite the allure of expensive extensions.
Let’s watch Burp in action. Imagine a web application with a hidden admin panel. The app uses cookies for session management, and the admin panel is protected by checking a role parameter within the cookie.
Here’s a sample request to the admin panel:
GET /admin HTTP/1.1
Host: vulnerable-website.com
Cookie: sessionid=abcdef123456; role=user
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Our goal is to change role=user to role=admin. We can do this manually, but Burp Suite excels at automating and discovering such patterns.
First, send this request to Burp’s Repeater.
[Screenshot of Burp Suite Repeater with the request loaded]
In Repeater, you can directly edit the Cookie header. Change role=user to role=admin, then click "Send".
[Screenshot of Burp Suite Repeater showing the modified request and the successful response from the server, e.g., "Welcome, Administrator!"]
If the server responds with a success message or a different page, you’ve found your vulnerability. But what if the role parameter isn’t directly in the cookie, or it’s encoded? This is where Burp’s Intruder becomes your best friend.
Let’s say the cookie looks like this: sessionid=abcdef123456; role_enc=dXNlcg== where dXNlcg== is Base64 encoding for user.
- Send the request to Intruder. Right-click the request in Repeater or Proxy History and select "Send to Intruder."
- Clear default payload positions. Go to the "Positions" tab in Intruder and click "Clear §".
- Add payload positions. Select the Base64 encoded part of the
role_encparameter (dXNlcg==) and click "Add §". - Select attack type. In the "Payloads" tab, choose "Simple list" for the payload type.
- Define your attack list. Under "Payload Options," paste a list of potential encoded values. For
role=admin, you’d need to encodeadminin Base64, which isYWRtaW4=. So your list would be:
(You might also include other common roles likedXNlcg== YWRtaW4=dXNlcg==,YWRtaW4=,bW9kZXJhdG9y==, etc.) - Start the attack. Click "Start attack."
[Screenshot of Burp Intruder running, showing the list of payloads and the responses. One row will show a significantly different response for YWRtaW4=.]
Intruder will send each payload and show you the server’s response. You’re looking for a response that differs from the others, typically indicated by a different content length or status code. In this case, YWRtaW4= would likely yield a successful "Welcome, Administrator!" page.
The mental model here is simple: Burp Suite acts as a highly configurable proxy and manual manipulation tool. You intercept traffic, identify parameters that control application logic (like authorization or input validation), and then use tools like Repeater to test hypotheses manually or Intruder to systematically test a range of possibilities. The key is understanding what the application is doing with the data you send it, not just that it’s sending data.
A common trap is focusing only on SQL injection or XSS. While important, simple parameter manipulation in cookies, hidden form fields, or URL parameters often bypasses complex defenses and wins CTF challenges. The Cookie header is just one place to look. Also, consider X-Forwarded-For, Referer, or custom headers; attackers often inject malicious values into these.
The next step after mastering parameter manipulation is understanding how to chain these findings with other vulnerabilities.