Burp Suite for OSWE preparation is a manual discipline, not a scanning job. The active scanner is black-box, Professional-only and blind to source-level sinks and multi-request state, though it still maps surface quickly. What decides an OSWE-style chain is Repeater discipline, a request-to-source map and session handling that doesn’t fight you.
This article covers that workflow. It assumes you already read code and live in Burp, so it teaches neither from zero.
Why Burp Suite’s Active Scanner Misses Source-Driven OSWE Chains
The scanner sends payloads and scores responses, so it needs a single request that misbehaves. A chain that needs a login, then a crafted object stored in one request, then a trigger in a second, gives it no single response to score, and a sink reachable only after the framework renames a parameter never shows up as an anomaly.
| Tool | Role in source-driven work | Where it fails | Edition |
|---|---|---|---|
| Scanner | Surface mapping: crawl, endpoint and parameter discovery | Black-box; can’t see sinks or follow multi-request state | Professional only |
| Repeater | One hop per tab, one variable per send | Doesn’t follow redirects unless you enable it; no chain logic | Community and Professional |
| Comparer | Benign-vs-payload response diffs | Only diffs what you send it; no context | Community and Professional |
| Session rules and macros | Keep an authenticated flow valid | Can silently swap the session you’re testing | Confirm in your edition’s Sessions settings |
| Intruder vs Turbo Intruder | Many or timed requests | Community Intruder is throttled; Turbo Intruder needs a script | Intruder in both; Turbo Intruder is a BApp Store extension |
Reaching for the scanner first is a common habit among web-exam candidates, not a measured one, and nothing here is survey data. Don’t drop the scanner entirely: a crawl on a practice app is a fast way to list endpoints before you read the route definitions.
Burp Community is enough for everything below. Scanner ships with Professional, so on Community the manual workflow is the only workflow, and the two gaps that matter are a throttled Intruder, which Turbo Intruder covers, and temporary-only projects, which you handle by exporting evidence at checkpoints.
Whitebox Source Code Review Mapped to Burp Request History
OSWE is a white-box exam, so reading the application source is part of the job, and the sitting is timed with a separate report window that belongs in your pacing plan. Check the current lengths in OffSec’s exam guide rather than trusting any blog.
Minutes in Repeater without knowing the handler are the most expensive ones you’ll spend. For the reading half, see the OSWE source code review methodology; this section covers only the join between code and traffic.
Build a Route-to-Request Map from the Site Map
Browse the application through the proxy, set the target scope, then filter history to in-scope entries only. For each entry, write one row: method and path, route definition, handler, parser (form, JSON, XML, multipart) and the sink the handler eventually reaches.
The order is the same as in any good engagement: enumerate before you exploit. That page is OSCP-oriented, so take the principle, not its steps.
The valuable column is the one you fill in last. Flag every place the live request departs from what the code expects:
- a parameter the UI sends under one name and the handler reads under another
- a form body where the handler calls a JSON parser, or the reverse
- a field the handler reads with a default that the UI never sends
Those gaps are where input reaches code the interface was never designed to exercise.
Diff Code Paths and Responses to Locate the Sink
Work backwards. Grep for dangerous calls, then trace each hit up to a route and only then send traffic.
grep -rnE "unserialize\(|readObject\(|ObjectInputStream|eval\(|Runtime\.getRuntime|ProcessBuilder|render_template_string|createStatement|HttpURLConnection|curl_exec" src/ --include=*.php --include=*.java --include=*.py
Hypothetical output, for shape only:
src/controllers/ExportController.java:88: ObjectInputStream in = new ObjectInputStream(req.getInputStream());
src/services/FetchService.java:41: HttpURLConnection conn = (HttpURLConnection) new URL(userUrl).openConnection();
A hit is a candidate, not a finding. If you can’t trace it to a route reachable from an authenticated request in your history, park it. A clean grep doesn’t clear the app either, because the sink may live in a dependency, so check the manifest and any vendored directories next.
Once a path looks live, send a benign request and a payload request, then push both responses to Comparer. Use words mode for error text and bytes mode for length or header drift. A difference that matches the branch you read in the source is evidence; a difference that doesn’t match any branch usually means you’re hitting a different handler than you think.
Burp Suite Macros for Authenticated Session Handling
Most OSWE-style targets sit behind a login, and sessions expire or get invalidated mid-test. A session handling rule keeps the flow valid, but a badly scoped one will quietly rewrite the requests you’re trying to study.
The rule has three moving parts. Find them under Settings > Sessions on current releases (Project options > Sessions on older builds), and confirm your edition exposes them.
- Scope. The URL scope plus the tool tickboxes: Proxy, Repeater, Scanner, Intruder, Extensions. Never assume which ones are on.
- Macro. A recorded login request. If the form carries an anti-CSRF token, configure the macro item to derive that parameter from the previous response, so every replay uses a fresh token.
- Validity check. A “check session is valid” action that looks for a string or status, such as a redirect to the login page, and runs the macro only when the check fails.
That third part decides when the macro fires, so pick a marker that appears only on a truly dead session. A marker that also matches a legitimate 403 will trigger re-logins constantly.
When Auto Re-Login Swaps the Session Under Your Test
Say you’re checking a privilege boundary with a low-privilege cookie in Repeater, and a rule in scope for Repeater sees your expected 403, decides the session is dead and runs the macro, which logs in as the macro’s user and writes that cookie into the jar. Your next request then carries a different identity than you think, so the 403 disappears and you read it as a bypass, or a working request looks broken for the opposite reason.
The result is a false finding that costs you an hour.
Open the session handling tracer to see which rule fired and what it changed, then compare the Cookie header in Repeater with what Logger++ recorded. To fix it, remove Repeater from the rule’s tool scope for the chain you’re validating, or tighten the validity check so it can’t match your own test’s expected failure.
Burp Repeater Workflow for Validating Exploit Chains
Manual testing in Burp Suite is where a chain becomes provable. An exploit that works once in a messy tab proves little, while one that works hop by hop, from a known state, is something you can explain and replay.
One Hop per Tab, with Session State Pinned
Name each tab in exploit order: 01-login, 02-stage-object, 03-trigger. On current releases you can keep them in a tab group per chain, which stops two chains from sharing a tab strip.
Pin the state by hand. Hold the cookie constant across tabs and copy the anti-CSRF token from the preceding response yourself, so you see when it rotates instead of letting a macro hide it. Change one variable per send and note what you changed, because a result you can’t attribute to a single edit is just noise.
Where the hypothesis takes one or two requests, stay in Repeater. Scripting it is slower than just sending it.
Failure Signals That Point Upstream of the Payload
When a hop fails, the payload is rarely the first suspect. These signals usually point somewhere earlier; menu labels below match current Burp releases, but confirm them on your build.
| Signal | Likely cause | Next branch |
|---|---|---|
| 302 to the login page, or a 200 with a login form | Session dead or swapped | Check the Cookie header, then the session tracer |
| 302 elsewhere, effect not visible | Repeater doesn’t follow redirects by default | Click Follow redirection, or read the Location header and send it as its own hop |
| 400 or a hang after a manual body edit | Content-Length drift | Check that Repeater’s Update Content-Length option is on; look for leftover chunked headers |
| Payload reflected mangled or not at all | Parser-specific encoding, decoded once versus twice | Try URL-encoding versus JSON unicode escapes; test the transform in Hackvertor |
| Response byte-identical to an earlier one | Stale or cached response | Check Cache-Control, ETag and the Date header; vary the path with a harmless parameter |
| 403 on a request that worked a minute ago | Spent or rotated CSRF token | Refetch the token from the previous response |
Each row sends you back to a precondition, not to a new payload. Check them in this order before you rewrite the exploit.
Mapping Common OSWE Vulnerability Classes to Burp Tools
The class list below follows AWAE (WEB-300) course methodology; confirm it against the current syllabus. Examples stay generic, with no exam targets and no protected material.
Injection and Template Classes: SQLi, SSTI and Command Injection
| Class | Sink to grep for | Burp tool | What it can’t prove alone |
|---|---|---|---|
| SQL injection | String concatenation into a query, createStatement, raw query helpers |
Repeater, Comparer for boolean and timing diffs | Which query or context you hit; a diff may come from app logic, not the database |
| SSTI | render_template_string, user input concatenated into a template |
Repeater with an arithmetic probe; Hackvertor for encoding | A reflected result proves evaluation, not an exploitable sandbox |
| Command injection | exec(, system(, Runtime.getRuntime, ProcessBuilder |
Repeater timing; Collaborator or your own listener for out-of-band | A callback shows a process ran something, not which user or whether output can return |
Source tells you which of these to try. Burp’s job is to show that the live request reaches the sink with your input intact.
Trust-Boundary Classes: Deserialization, SSRF and Authorization Logic
| Class | Sink to grep for | Burp tool | What it can’t prove alone |
|---|---|---|---|
| Deserialization | unserialize(, readObject(, pickle.loads, BinaryFormatter |
Deserialization detector BApps (Java Deserialization Scanner, Freddy) to identify format; Repeater to deliver | A detector flags a deserialization endpoint, not a working gadget chain on this classpath |
| SSRF | HttpURLConnection, curl_exec, an HTTP client fed a user URL |
Collaborator or your own listener; Repeater | A callback proves an outbound request, not code execution or internal reach |
| Authorization logic | Handlers with no role check, object lookups by raw ID | Autorize BApp, Repeater with two sessions | Similar responses don’t tell you whether the data was meant to be restricted; only the code’s policy does |
Some of these helpers hook into the Professional scanner, and Collaborator is a Professional feature, so on Community you’ll run your own listener instead. Whether any helper is permitted on the exam is a question for OffSec’s current exam guide, not this table.
Burp Extensions for Web Exploitation at Exam Pace
Every extension you add costs setup time you’ll pay from the same clock as the exploit. The ones worth adopting remove a recurring cost, and the rest are a distraction you can’t afford.
Logger++ and Turbo Intruder: Adopt Them Before Exam Day
Logger++ keeps a searchable record of everything Burp’s own tools sent, including Repeater and Intruder, with filtering. That matters when one chain spans a dozen Repeater tabs and you need to find which request carried the last working cookie. You can also export its log, which is your backup on Community, where projects don’t persist.
Turbo Intruder is the scripted option for chains that need many or timed requests, such as walking a numeric token range or lining up requests inside a short window. Community’s throttled Intruder is the usual reason to move there. A minimal sketch (Jython-based, so Python 2 syntax):
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
requestsPerConnection=1,
pipeline=False)
for i in range(0, 200):
engine.queue(target.req, str(i))
def handleResponse(req, interesting):
table.add(req)
The %s marker in the request is where each value lands. If you’ve never written a Turbo Intruder script, you won’t write a clean one under pressure, so practice it on a lab app first.
Pin the version you practiced with and don’t update mid-prep. Drop anything you haven’t run before exam day, because a half-learned extension will cost more time than it saves. When you plan that cost, adapt the exam-pacing checkpoints from the OSCP model; the OSWE window differs, so shift the timings instead of copying them.
Documenting Proof-of-Concept Requests for the Report
Keep each PoC as three things: the raw Repeater request, a curl replay, and the response excerpt that shows the effect. On current releases, right-click in Repeater and choose Copy as curl command (confirm the label on your build). Hypothetical example:
curl -i -s -X POST 'http://192.0.2.10/api/v1/profile' \
-H 'Content-Type: application/json' \
-H 'Cookie: session=<validated-session>' \
--data-binary '{"displayName":"probe-01"}'
Run the replay from a clean shell after a fresh login. A request that only works inside Burp’s cookie jar isn’t reproducible, and a reviewer won’t be able to reproduce it either.
Save at each checkpoint. On Professional that means saving the project. On Community, where projects are temporary on current builds, export the history items and the Logger++ log instead.
For layout, the evidence-first report structure shows how to write each finding so a reviewer can follow it. It’s OSCP-specific, so check OffSec’s current exam guide before copying any of it. The report rules and the tool permissions both come from that guide. This article doesn’t set either.
If you’re weighing outside resources for OSWE, the OSWE service list in the catalog opens the catalog’s OSWE listing page. Check scope, sample availability and delivery terms there before you pay, because none of those are stated in this article.
Frequently asked questions
Is Burp Community enough for OSWE prep?
Yes for the manual workflow: Proxy, Repeater and Comparer cover request mapping, hop-by-hop validation and response diffs. You lose the scanner, which ships with Professional, and Intruder is throttled, so heavy scripted requests move to Turbo Intruder. Projects are also temporary on Community, so export your evidence at checkpoints.
Is Burp’s scanner allowed on the OSWE exam?
Tool permissions come from OffSec’s current exam guide, and this article doesn’t quote it, so read it before you rely on anything. Even where a tool is allowed, the active scanner is black-box and won’t find a chain that depends on source-level sinks and several dependent requests.
What do I use instead of Burp Collaborator on Community?
Run your own listener on a host the target can reach and watch for the callback there. The limit is the same either way: a callback proves an outbound request happened, not that you have code execution or internal network access.
Do I need Logger++ if I save the Burp project?
They do different jobs. The project is your saved state, while Logger++ is a filterable record of what every tool sent, which helps when a chain spans many Repeater tabs. On Community, where projects don’t persist, exporting the Logger++ log is also your backup.