Burp Suite Tutorial

Burp Suite sits between your browser and the target as a proxy, so you can read and modify every request before it is sent. The Community edition is free and enough to learn on. The workflow that matters is: intercept in Proxy, send interesting requests to Repeater, modify and resend by hand, then automate the repetitive part with Intruder.

Most Burp tutorials stop after the proxy setup, which is the least useful part. This one gets you to the point where you are actually finding things.

Setup, once

1. Install Burp Community. Free from PortSwigger. Java is bundled.
2. Use the built-in browser. Proxy tab, Open Browser. It is preconfigured and skips all the certificate pain. Do this first.
3. If you want your own browser: point it at 127.0.0.1 port 8080, then visit http colon slash slash burp and download the CA certificate. Install it as a trusted authority. Without this every HTTPS site throws errors.
4. Set scope. Target tab, Scope, add your target. Then filter the site map to in-scope only. Without scope you will drown in noise from every other tab you have open.

The five tools you actually use

Proxy: stop intercepting everything

Beginners leave Intercept on and then fight the browser for twenty minutes. Turn Intercept off. Browse the application normally and let everything land in HTTP history. Then go back and look.

Intercept is for when you specifically need to change a request in flight, not for browsing.

Repeater: where the work happens

Find an interesting request in HTTP history, right click, Send to Repeater. Now you can change one thing at a time and watch what the response does.

The habit to build: change exactly one parameter, send, read the response carefully, then change it back. Changing three things at once and getting a different response teaches you nothing about which change caused it.

Things worth trying in Repeater on almost any request:

• Change a numeric id to another user's id. See access control testing.
• Add a single quote to every parameter and watch for errors
• Remove the authentication header entirely and see what still works
• Change the HTTP method from POST to GET
• Add an unexpected field to a JSON body

Intruder: automate one thing

Send a request to Intruder, clear the auto-selected positions, and mark only the one value you want to vary. Then pick an attack type.

Community edition throttles Intruder heavily. That is annoying and it is also fine for learning, because it forces you to think about which payloads are worth sending rather than firing ten thousand and grepping.

Sort by response length, not status code. The interesting result is usually the one that came back a different size, not a different code.

The workflow professionals actually use

1. Browse the whole application with Intercept off, clicking every feature, to populate the site map
2. Set scope, then filter to in-scope only
3. Read the site map and pick the requests that touch data, identity or money
4. Send those to Repeater and probe by hand
5. Where a pattern appears, automate it in Intruder
6. Use Comparer when two responses look identical but behave differently
7. Document as you go, not at the end. See how to write a VAPT report.

Mistakes that slow beginners down

• No scope set. Everything becomes noise.
• Leaving Intercept on. Fighting the browser instead of testing.
• Trusting the scanner. Community has no scanner, which is a hidden blessing while learning.
• Not reading responses. The finding is usually in a subtle difference, not an error message.
• Skipping Comparer. It finds things eyes miss.

Practise this

Reading about Burp teaches you the menus. Using it teaches you the tool. Work through web challenges on Hacklido with Burp open and Repeater as your main window.