Burp Suite and the Web Hacker’s Toolkit

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: A browser shows you what a web app wants you to see. To attack or test an app you need to see — and change — what’s actually being sent on the wire, before it reaches the server. An intercepting proxy gives you that power: it sits between your browser and the server, letting you pause, read, and rewrite every request. Burp Suite is the standard such tool, and it will be open on your screen for most of your offensive career.

Part 1: The Problem

In section 0.3 you used browser dev tools to watch HTTP requests. Watching isn’t enough. To test a web application you need to modify requests — change a parameter, tamper with a cookie, alter a header, replay a request a thousand times with variations.

The browser won’t let you do that easily; it sends what the page tells it to send. You need a tool positioned between the browser and the server, with full control over the traffic. That tool is an intercepting proxy, and Burp Suite is the one you’ll learn.

Part 2: The Concept — An Intercepting Proxy

A proxy is a middleman that traffic passes through. An intercepting proxy is a proxy you control, that can pause traffic and let you inspect or edit it before it continues.

   NORMAL
   Browser ──────────────────────► Server

   WITH AN INTERCEPTING PROXY
   Browser ──► [ BURP ] ──► Server
                 │
        you can pause here, READ the
        request, MODIFY it, then send
        it on — or drop it entirely.

Because you control the proxy, you control the conversation. Every request the browser makes, you can catch and rewrite. Every response from the server, you can read in full. This is the foundational capability of web hacking — the app’s defenses that live in the browser (hidden fields, JavaScript checks, disabled buttons) become irrelevant, because you edit the request after the browser is done with it.

This is also the practical proof of a Phase 1.4 principle: never trust the client. The proxy is exactly how an attacker bypasses anything enforced only in the browser.

Part 3: Burp Suite — The Core Tools

Burp Suite is a collection of tools sharing one proxy. The Community Edition is free and enough to learn everything in this curriculum. The pieces you’ll use constantly:

The two you’ll live in: Proxy (to capture) and Repeater (to test one request methodically). Master those two and you can do most of Phase 2.

Part 4: How the Pieces Fit — A Typical Workflow

Here’s how the tools combine in a normal testing session:

1. PROXY      Browse the target app through Burp.
                 │  Every request is captured and logged.
2. HTTP        Review the history — see every endpoint,
   HISTORY     │  parameter, cookie the app uses.
3. Pick an     Find a request worth testing — a login,
   interesting │  a search, a profile fetch.
   request     │
4. REPEATER    Send it to Repeater. Modify a parameter,
                 │  re-send, observe the response. Repeat,
                 │  changing one thing at a time.
5. INTRUDER    If a test needs many variations (e.g. trying
                 │  many inputs), automate it with Intruder.
6. ANALYZE     Read responses — status codes, content,
                  errors, timing — for signs of a vulnerability.

Every exploitation technique in the rest of Phase 2 — injection, XSS, IDOR, and the rest — is, mechanically, this loop: capture a request, modify it thoughtfully in Repeater, read what the server does. The technique is what you change and what you look for; the workflow is always this.

Part 5: Setting Up — Browser, Proxy, and HTTPS

To route your browser through Burp, three things must be configured. You’ll do this in the lab; here’s the concept so it’s not mysterious:

1. Point the browser at Burp. The browser is told to send all traffic to Burp’s proxy address (by default 127.0.0.1:8080) instead of straight to the internet. Many testers use a dedicated browser (or browser profile) just for this.
2. Install Burp’s CA certificate. Here’s a subtlety. To read HTTPS traffic, Burp must decrypt it — but HTTPS is designed to prevent middlemen from doing exactly that. So Burp acts as a deliberate, authorized middleman: it presents its own certificate to your browser. For the browser to accept it without warnings, you install Burp’s certificate as trusted.

This is, in effect, a man-in-the-middle on your own traffic, with your own consent. It’s safe because you run Burp and you authorized it. It’s also a quiet lesson: this only works because you can install a trusted certificate on your own machine — which is precisely why, on systems you don’t control, HTTPS resists interception.

1. Confirm it works. Browse the target; requests appear in Burp’s HTTP history, HTTPS included.

   Browser ──HTTPS──► [ BURP ] ──HTTPS──► Server
                        │
        Burp decrypts (using its trusted cert),
        lets you read/edit, then re-encrypts.
        Works ONLY because you trusted Burp's
        cert on your OWN machine.

Part 6: Other Tools in the Web Hacker’s Kit

Burp is central, but a few companions are worth knowing. Add them to your Cheatsheet:

• OWASP ZAP — a free, open-source intercepting proxy; a full alternative to Burp. Some practitioners prefer it, and it’s entirely capable.
• Browser developer tools — still useful for inspecting the DOM, JavaScript, and the live page (section 0.3).
• curl — a command-line tool to send HTTP requests. Perfect for scripting requests and for precisely controlling a single request.
• A note-taking system — not a hacking tool, but essential. You’ll discover dozens of endpoints and observations; testing is only as good as your notes. Your Notion target map from 2.1 is exactly this.

You don’t need many tools. You need to know Burp’s Proxy and Repeater deeply, and have curl and ZAP as supporting options. Depth on a few tools beats shallow familiarity with many.

📓 Key Terms

🧪 Hands-On Lab

Do all of this against your own lab (Phase 0.5) or a deliberately vulnerable practice app. Burp is pre-installed on Kali Linux.

Task 1 — Launch Burp and configure the browser. Open Burp Suite (Community Edition). Configure a browser to route through Burp’s proxy (127.0.0.1:8080). Burp’s Community Edition also ships an embedded browser pre-configured — using that is the easy path to start.

Task 2 — Install the CA certificate. Follow Burp’s process to install its CA certificate in your testing browser, so HTTPS traffic is readable without warnings. Re-read Part 5 while you do it — understand why this works and why it only works on a machine you control.

Task 3 — Capture traffic. Browse your lab’s vulnerable web app through Burp. Watch the HTTP history fill with requests. Click through several — read the request line, headers, cookies, and the response. This is section 0.3’s theory, now fully visible and under your control.

Task 4 — Use Repeater. Find a request that takes a parameter (a search box, a login). Send it to Repeater. Change the parameter value and re-send. Observe how the response changes. Do this several times, changing one thing each time. You’ve just performed the core loop of all web testing.

Task 5 — Try Intruder. Take a request with one input. Use Intruder to send it repeatedly with a short list of different values. Watch the results table — note how response length and status code vary. This is the engine behind automated testing later.

Task 6 — Compare with curl. Send the same request from the command line with curl. Notice you can do precisely from the terminal what Burp does graphically — useful when scripting.

⚠️ Common Mistakes

• Routing all your traffic through Burp permanently. Use a dedicated browser/profile for testing. You don’t want your personal browsing flowing through Burp.
• Forgetting to remove Burp’s certificate / proxy settings later. When done testing, undo the browser proxy config. Leaving a machine permanently trusting a proxy cert is poor hygiene.
• Drowning in Burp’s features. Burp has many tools and extensions. Beginners get lost exploring all of them. Master Proxy and Repeater first; add the rest as needed.
• Testing apps you’re not authorized to test. Burp makes it trivially easy to attack any site you visit. That ease is a trap — scope and authorization (page 1.0) still govern everything.
• Not taking notes. You’ll pass hundreds of requests through Burp. Without notes tied to your target map, findings get lost.

✅ Recap & What’s Next

• A browser shows what an app permits; an intercepting proxy lets you pause and rewrite every request — defeating any defense that lives only in the browser.
• Burp Suite is the standard tool; Proxy captures traffic and Repeater lets you methodically modify and re-send a request — together they cover most of Phase 2.
• Reading HTTPS in Burp requires installing its CA certificate — a consensual man-in-the-middle on your own machine, which itself shows why HTTPS resists interception elsewhere.

Next (2.3): You have a mapped target and a workbench. Now you need the industry’s shared map of what to look for — the OWASP Top 10, the common language for the most serious web vulnerabilities.