Setting up Burp Suite: the intercepting proxy
When you browse the web, your browser hides a lot of what it sends. A web tester needs the opposite: to see every request, read it, and sometimes change it before it reaches the server. That is exactly what an intercepting proxy does, and Burp Suite is the best-known one.
Reminder
An interception proxy is a neutral tool, much like a magnifying glass. Used on your own lab it is perfectly legitimate. Used to tamper with traffic of a system you are not authorised to test, it falls under the same laws as any other intrusion. In this course you will only route traffic to your own training applications through it.
What is a proxy?
A proxy is an intermediary. Normally your browser talks directly to a server. With a proxy configured, the browser sends its requests to the proxy, which forwards them to the server and then returns the answer. Companies use proxies to filter and log traffic; testers use them to look inside it.
Think of a translator sitting between two people who speak the same language. You will have the opportunity to read every sentence, pause the conversation and even reword a sentence before passing it along.
Browser ---request---> Proxy (127.0.0.1:8080) ---request---> Training application
Browser <--response--- Proxy <--response--- Training application
The proxy listens on your own machine (the address 127.0.0.1, also called localhost) on a port such as 8080. Nothing leaves your computer until you let it.
What Burp Suite offers
Burp Suite is a professional toolbox for web testing, produced by PortSwigger. A free Community Edition is available and is more than enough for this course. The modules you will use most are:
| Module | What it does |
|---|---|
| Proxy | Intercepts and records all requests and responses passing through it. |
| HTTP history | A searchable log of everything that went through the proxy. |
| Repeater | Lets you take one request, modify it by hand and send it again, as many times as you want. |
| Target / Site map | Builds a tree of the pages and resources discovered, and defines the scope. |
| Decoder / Comparer | Converts between encodings (URL, Base64, hexadecimal) and compares two responses. |
Other tools exist, such as the open source ZAP, and you are free to use them; the concepts are identical. We use Burp as our example because it is common in the profession.
Installing Burp Suite
Download the Community Edition from the publisher’s official website, using the installer for your operating system. It requires no special configuration. Kali Linux, the distribution you may already use in your virtual lab, usually includes it already. If you work in a virtual machine, install it in that machine so that your testing tools stay separate from your daily system.
On first launch, choose a temporary project and the default configuration. Then open the Proxy tab. Burp starts a listener on 127.0.0.1, port 8080, by default.
Connecting your browser to the proxy
You have two options.
- The built-in browser. Burp includes a pre-configured browser, launched from the Proxy tab with an “Open browser” button. It is already set up for interception and trusts Burp’s certificate. This is the easiest way to start.
- Your own browser. In the network settings, set a manual HTTP proxy to
127.0.0.1and port8080. A dedicated browser profile just for testing is a good idea, so that your normal browsing never goes through the proxy.
The certificate question
Modern sites use HTTPS, which prevents anyone in the middle from reading the traffic. For Burp to read it, it plays the role of the “middle” on purpose: it presents its own certificate to your browser. Your browser will warn you about this unless you install Burp’s certificate authority in the test profile. This works because you control both ends. Install that certificate only in your dedicated testing browser or virtual machine, never in your everyday browser, as it would let the proxy read all of your secure traffic.
The training applications you will install in the next lesson run locally on plain HTTP, so you will not need the certificate for them. It is still useful to understand why the warning appears.
Intercepting a request
In the Proxy tab, the Intercept button toggles between “on” and “off”.
- Intercept on: each request pauses in Burp. You can read it, edit it, then click Forward to send it or Drop to discard it.
- Intercept off: requests flow through freely, but are still logged in the HTTP history.
Beginners often leave interception on and then wonder why the browser seems frozen. The page is simply waiting for you to forward the request. In practice, professionals keep interception off most of the time, browse normally, and review the history afterwards. They only switch it on when they want to alter a specific request.
Reading a request
Here is a typical intercepted request, rewritten here for a generic lab application:
POST /login HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 37
Cookie: session=abc123
username=student&password=lab-password
Learn to break it down. The first line is the method (POST), the path (/login) and the protocol version. The following lines are headers, which are metadata. A blank line separates them from the body, which carries the form data. Every one of these elements is something the user, and therefore a tester, can change. This is the central idea of web security: the server must never trust what arrives from the client, because the client is under the user’s control.
Repeater: your workbench
Right-click any request in the HTTP history and choose “Send to Repeater”. In Repeater you can change a value, press Send and read the response next to the request. This lets you run small controlled experiments, exactly the kind of testing we described in the previous lesson. You will use Repeater constantly from chapter 2 onwards.
Defining the scope in Burp
In the Target tab, you can add your lab application to the scope. Burp can then ignore everything else, which keeps your history clean and prevents you from accidentally acting on an unrelated site. It is the technical counterpart of the scope statement you wrote in lesson 1. Make it a habit: first the scope, then the tools.
Tip
If a page behaves strangely when the proxy is on, check three things first: is intercept paused, is the proxy address correct, and does the browser trust the certificate? Most problems come from one of these.
Your turn: observe your own traffic
Install Burp Suite Community Edition in your lab machine and start the built-in browser. Create a notebook entry titled “Proxy setup”. Then, with intercept off, open a local page of your own (for instance a simple HTML file served on your machine, or the training application once you install it in the next lesson) and look at the HTTP history. Pick one request and note its method, path, three headers and whether it has a body.
See a solution
Your entry could read:
Proxy setup
- Burp listener: 127.0.0.1:8080, built-in browser works
- Intercept off, history shows requests as I browse
- Sample request: GET /index.html HTTP/1.1
- Headers noted: Host, User-Agent, Accept
- Body: none (a GET request normally has no body)
- Lesson learned: every header comes from the browser and could be modified
If your history stays empty, verify that the browser really uses 127.0.0.1:8080, and that you did not open the page in a different, non-proxied browser window.
Key takeaways
- An intercepting proxy sits between the browser and the server so that you can read, pause and modify HTTP traffic.
- Burp Suite Community Edition is enough for this course; the Proxy, HTTP history and Repeater modules cover most needs.
- Install the proxy certificate only in a dedicated testing browser or VM.
- Everything the browser sends (path, headers, cookies, body) can be changed by the user, so the server must never trust it.
- Set your scope first, and route only your own lab traffic through the proxy.
Next, you will choose and install the legal training environment that your proxy will observe.