Burp Suite Proxy, Repeater, and Intruder: Intercepting and Replaying Web Requests#

Why this topic matters: nearly every web finding starts as a single request you can see, modify, and replay. Burp is where that request lives.

Ethics and scope: run everything below only against targets you own or have permission to test. Intercepting other people's traffic is not a testing technique. For the vulnerability classes this feeds into, see web hacking 101.

The Editions#

Setup in Four Steps#

1. Install from the official site.
2. Point the browser at the proxy listener on 127.0.0.1:8080.
3. Install the Burp CA certificate in the browser trust store.
4. Confirm traffic appears in Proxy history.

A browser profile or a tool like FoxyProxy makes the switch quick. Do not route your daily browsing through the test browser.

The Proxy#

The proxy is the front door. Every request the browser sends passes through it first.

Intercept tab#

• Forward sends the request as it is.
• Drop discards it.
• Modify rewrites parameters before forwarding.

HTTP history#

The history is the notebook. Filter it to the hosts you care about and exclude static assets:

Copy code
Filter bar: show only requests to example.com, hide *.png, *.css, *.woff

The golden rule#

Capture first, analyze second. The history is the record; the intercept tab is for live edits only.

Repeater#

Repeater is the workbench. Send a request to Repeater, edit it, send it again. That loop is the core of manual testing.

The loop#

1. Find an interesting request in history.
2. Send to Repeater.
3. Change one parameter.
4. Send and compare the response.
5. Note the change, change one parameter, repeat.

What a good diff looks like#

Change one thing at a time. Two changes at once is how noise becomes a finding.

Intruder#

Intruder iterates over payloads. Four modes cover most jobs:

A safe first Intruder job#

1. Capture a single request.
2. Add the position markers around one parameter.
3. Load a short, known list.
4. Watch lengths and statuses, not just 200s.

Community edition throttles Intruder; plan lists accordingly.

Decoder and Comparer#

Two utility tabs earn their keep:

• Decoder for URL, HTML, Base64, and hash transforms.
• Comparer for diffing two responses side by side.

Neither replaces reading the response. Both save copy-paste errors.

Extensions Worth Knowing#

Install extensions from the BApp store, review what each adds to the request path, and keep the list short.

A First Manual Test Flow#

1. Browse the target once through the proxy.
2. Mark every request that carries an ID, a role flag, or a price.
3. Replay each with a second role's session.
4. Compare: does the answer change when it should?
5. Record the diffs with a Repeater screenshot.

That loop alone finds most access-control bugs. Tools like the BOLA test matrix scale it up.

Noise Management#

• Exclude static files from history with the filter bar.
• Close browser tabs that belong to other origins.
• Stop interception before doing non-test browsing.
• Save the project before closing; history is lost otherwise.

Limits of Burp#

• It shows one browser's traffic; other clients are invisible.
• It does not interpret; a 200 with the wrong body is your call.
• Intruder will hammer politely but it will hammer. Scope it.
• It records traffic, not intent. You write the analysis.

Troubleshooting Notes#

Common Mistakes#

• Testing production with Intruder at full speed.
• Editing the request without a baseline copy.
• Calling a 200-with-login-page a success.
• Trusting the scanner to know your business logic.
• Forgetting to record the session cookie's role.

Reading Order Around This Topic#

• The class map: web hacking 101.
• Injection sinks to replay into: SQL injection notes.
• Markup sinks: XSS types compared.
• Secondary contexts the proxy misses: attacking secondary contexts.
• ZAP as the open-source twin: ZAP review notes.
• Access-control testing at scale: BOLA test matrix.
• The API side of the same checks: API access control test plan.
• Server action checks: server actions authorization.
• Cloud APIs the proxy fronts: AWS testing notes.
• WordPress checks through the proxy: WordPress attack surface.
• Mobile traffic, different proxy: mobile app testing notes.
• Ethical scope reminders: social engineering patterns.
• The roadmap that orders these: reading order.
• Packet-level confirmation: Wireshark guide.

Glossary#

A Note on Repeater Hygiene#

Copy the request before editing. Keep a tab named baseline with the unmodified request. Every experiment lives on its own tab with a label that names the hypothesis. When you find something, the baseline tab is the control; delete nothing until the report is written.

A Note on Intruder Hygiene#

Scope the host first, mark the positions narrowly, and start with a handful of payloads. Watch for unexpected 500s; they signal a different bug class than the one you were fuzzing for.

Final Notes#

Burp is not a finding machine. It is a mirror that shows you the request and the answer. The tester turns those two into a report. Everything in this note exists to make that mirror cheaper to use: capture, replay, compare, record.

Walkthrough: Repeater Session for One Field#

1. Capture GET /items/1042 as the baseline.
2. Send it to Repeater.
3. Duplicate the tab, label it id=1043, send it.
4. Compare status, length, and body marker.
5. If 200 with another user's data, you have an access-control candidate.
6. Record both request IDs and both response bodies.

Walkthrough: Intruder for One Parameter#

1. Capture POST /login.
2. Mark only the password field.
3. Load twelve known-bad strings, not twelve thousand.
4. Send. Sort by response length.
5. Investigate the outliers; ignore the identical 200s.

Walkthrough: History Triage#

1. Filter to the target host.
2. Hide static assets.
3. Bookmark every request that carries a role, an ID, or a price.
4. For each bookmark, replay with the second role's cookie.
5. Add a comment on the odd ones before closing Burp.

A Sample Session Log#

Copy code
09:41  GET /items/1042  200  4120B  role=user-a  baseline
09:44  GET /items/1043  200  4184B  role=user-a  NOTE: other tenant's data
09:47  GET /items/1043  403  312B   role=user-b  role check present

That three-line log is worth more than a screenshot of the same traffic.

Common Field Markers#

Scan for these markers in history before touching Repeater. The parameter you were going to test is rarely the one that matters.

Extensions in Scope#

Before installing an extension, check what it does to every request. An extension that rewrites headers is a different tool than one that logs. Keep the list short and record what each one changes, because your baseline is only a baseline when the request path is unchanged.

Closing the Loop#

A Burp project is a notebook. The history, the comments, the saved Repeater tabs, and the JSONL from a checker all describe the same session. Keep them together, and a month later the report writes itself.

Scope Discipline#

Write the allowed hosts in the project settings before the first request. Mark everything else out of scope. When a redirect leads outside scope, Burp will still follow it; stop and note it instead. Scope is a property of the session, not of the URL bar.

Pre-Engagement Checklist#

One-Line Rules#

• One change per request.
• Baseline before every variant.
• Comment on the odd one immediately.
• Out-of-scope redirects get noted, not followed.
• Scanner output is a list, not a verdict.

After the First Finding#

Stop and write it up while the session is still open. The finding, the request, the response, and the exact parameter value are all one window away. Close the window, and they are one memory away.

Two Habits That Save Reports#

First, comment on the request the moment something looks odd. Second, save a new project file after each finding. History is the only record of what you actually sent, and it is trivially lost.

Burp and the Meeting After#

Hand off findings with three artifacts: the saved request, the observed response, and your one-line hypothesis. Tool output without the hypothesis invites the team to argue about the tool's behavior. The hypothesis invites them to argue about the bug.

What to Learn Next#

Once Proxy, Repeater, and Intruder feel boring, move on to two things at once: the vulnerability classes in SQL injection notes and XSS types compared, and the access-control workflow in the BOLA matrix. Boring tooling plus sharp classes is the whole craft.

After that, the loop does not change: capture, replay, compare, record. It just changes targets.

One Last Habit#

Name the session file with the date and the client's codename. Burp projects multiply; a date alone will not tell you which one mattered.