Burp Suite Repeater Tab: Precision Testing Made Simple

---

April 08, 2025

my week-long Burp Suite study brought me to the Repeater tab—a tool that’s all about manual control and precision in web security testing. Using my custom VulnHub app, a Flask-based vulnerable web app running in Docker , I explored how Repeater lets you tweak and resend HTTP requests to uncover flaws like Insecure Direct Object References (IDOR) and SQL injection. Here’s a detailed look at Repeater, how it works, and what it revealed about my app.

What Is the Repeater Tab?

Repeater is Burp Suite’s playground for manual request manipulation. You take an HTTP request—captured via Proxy or another tool—modify any part (parameters, headers, body), and send it back to the server to see what happens. Unlike Intruder’s automation or Scanner’s broad sweeps, Repeater is hands-on, letting you iterate quickly and test hypotheses with surgical precision. It’s perfect for confirming vulnerabilities, experimenting with payloads, or digging into server behavior—all in real-time.

Available in both Community and Professional editions with no limitations, Repeater’s a core skill for any pentester.

How Repeater Works

The workflow is straightforward but powerful:

1. Capture a Request:

   • Start in Proxy > HTTP history, where all your app interactions are logged.

   • Right-click a request (e.g., a GET or POST) and select “Send to Repeater.”

   • It opens in a new Repeater sub-tab (e.g., “Repeater 1”).

2. Modify the Request:

   • The left pane shows the raw request—edit anything: URL parameters, form data, cookies, headers.

   • Repeater’s interface is clean: you see the request as text, ready for tweaking.

3. Send and Analyze:

   • Click “Send,” and the response appears in the right pane—status code, headers, body, all laid out.

   • Tabs like “Inspector” or “Hex” let you dig deeper into parameters or raw data.

4. Iterate:

   • Tweak, send, observe, repeat—Repeater keeps the original request intact, so you can experiment freely.

Testing VulnHub with Repeater

VulnHub’s intentional weaknesses—IDOR, SQL injection, and more—made it a perfect Repeater target. Here’s how I used it to expose two critical flaws.

Exploiting IDOR on /profile

• Setup:

  • Logged in as admin (admin:1234) via Proxy to get a session cookie.

  • Captured a GET /profile?id=1 request:

  • Sent it to Repeater.

• Test:

  • Changed id=1 to id=2 and hit “Send.”

  • Tried id=999—got User not found!.

• Findings:

  • id=2 revealed user’s profile—unauthorized access since I was logged in as admin.

  • VulnHub doesn’t check if the id matches the session’s user, a textbook IDOR vuln.

  • Response lengths (~300 bytes for valid IDs, ~250 for invalid) confirmed the pattern.

Bypassing Login with SQL Injection

• Setup:

  • Captured a POST /login request:

  • Sent it to Repeater.

• Test:

  • Edited to username=admin' OR '1'='1&password=anything and clicked “Send.”

  • Original admin:1234 worked too, but this bypassed the password check.

• Findings:

  • The app’s query (SELECT * FROM users WHERE username = '{input}' AND password = '{input}') let me inject SQL to make it always true.

  • Repeater’s manual tweak confirmed the vuln—Login failed! flipped to success with one change.

Key Takeaways

• Precision Matters: Repeater’s control let me pinpoint IDOR and SQLi flaws Intruder might’ve brute-forced broadly.

• Response Clues: Subtle differences (e.g., “Welcome” vs. “not found”) expose security gaps.

• Real-World Risk: These vulns—unauthorized access and auth bypass—are common and devastating if unpatched.

Tips for Using Repeater

• Start Simple: Test one change at a time (e.g., id=2) before getting fancy.

• Preserve Sessions: Use a valid Cookie header from Proxy to stay logged in.

• Compare Responses: Use “Previous/Next” buttons to flip between sends—spot patterns fast.

• Scope It: Ensure 127.0.0.1:5000 is in Target > Scope to avoid request drops.

Why Repeater Stands Out

Repeater bridges automation (Scanner, Intruder) and manual testing. It’s where you confirm Scanner’s alerts (like SQLi) or explore Intruder’s hits (like valid IDs). For my VulnHub app, it turned vague suspicions into concrete exploits—id=2 shouldn’t have worked, but it did. As a developer, it’s a stark reminder to validate inputs and enforce access controls.

Wrapping Up

Repeater’s hands-on power has me hooked—it’s like a lab for crafting attacks. Day 5’s Sequencer is next, but for now, I’m marveling at how one tweak in Repeater can unravel an app’s defenses. Have you used Repeater to catch a vuln? Share your story—I’m learning fast!

---