Intercepting Proxies

The last lesson ended with a tidy instruction: change role=user to role=admin in the token, or swap session=1001 for session=1002, and the server hands back an account that belongs to someone else. Clean on paper. The trouble is mechanical. The browser builds that request, attaches the cookie, and fires it the instant someone clicks. It never pauses to ask what to send, and it offers no box to edit role before the bytes leave the machine. To rewrite a request, a tester has to stand in the path of the traffic and hold it still. An intercepting proxy is the tool that does exactly that.

A program that sits in the middle

A proxy is a program that relays traffic between two other machines. The client talks to the proxy, the proxy talks to the server, and the answer comes back along the same path. A plain proxy just forwards. An intercepting proxy adds a pause button: every HTTP request stops inside the tool, where a tester can read it, change any byte, and only then release it toward the server.

Two tools own this space. Burp Suite is the commercial standard, and its Community edition is free. OWASP ZAP is the fully open-source alternative. They differ in polish, not in idea. Both listen on a local port, both catch the traffic a browser sends, and both let a tester rewrite a request in flight and replay it as many times as the work takes.

Calling this the single most important web tool is not a slogan. The browser is built to hide the request. It renders a page, runs JavaScript, greys out the button a tester wants to press, and shows a friendly result. The raw request underneath, the actual bytes on the wire, is where every web attack lives. A proxy is the window onto those bytes.

The raw request is the truth

Here is what the browser sends when someone opens their account page, caught inside the proxy:

GET /account HTTP/1.1
Host: shop.example
Cookie: session=9f2c8a1b4d
User-Agent: Mozilla/5.0
Accept: text/html

Nothing here is new after the earlier lessons. It is the request anatomy from the HTTP lesson: a method (GET), a path (/account), the Host header, and the cookie that carries the session. What is new is that the tester can see it and touch it before it goes anywhere.

The rendered page never shows this. A logged-in account page displays a name and an order list, all of it built from the response. The request that produced it, including the exact session id and every header the browser added quietly, appears only when something intercepts it. Reading the raw request is the core web-testing skill because every later technique, changing an id, forging a cookie, injecting a payload, begins by seeing the precise bytes and deciding which one to bend.

Intercept and change it in flight

With interception turned on, the proxy holds each request instead of forwarding it. Someone clicks "Buy" and the request stops dead in the tool:

POST /api/cart HTTP/1.1
Host: shop.example
Content-Type: application/json
Cookie: session=9f2c8a1b4d
Content-Length: 29

{"item":"884","price":"1999"}

The body carries a price the browser copied straight off the product page. Nothing has reached the server yet. The tester edits "price":"1999" down to "price":"1", adjusts the Content-Length header to match the shorter body, and forwards it. If the server charges what the request says instead of looking the price up from its own database, the order clears at one cent. If it re-checks the price server-side, the tamper does nothing, and that is a useful answer too.

Two controls decide a held request's fate. Forward sends it on, edited or not. Drop discards it so it never reaches the server, which matters when a request would do something the tester does not actually want, like completing a real purchase. Interception is a mode, so a tester flips it on to catch one specific action and off again to browse without every image and script freezing the tool.

The history is the map

Intercepting every request is tedious, so most work runs with interception off. The proxy still records everything. Its HTTP history is a running log of every request the browser made and every response that came back, laid out in a table with method, path, status code, and length.

The rhythm is browse first, hunt second. A tester clicks through the app like an ordinary user, filling the history, then scrolls it for requests that carry something worth changing: a numeric id, a price, a token, a username. A GET /api/orders/1001 sitting in the log is a lead. So is any POST that submits a form or a JSON body. The history turns a stretch of aimless clicking into a searchable inventory of the app's real endpoints, including the API calls the page fired in the background that no visible link ever pointed at.

A live page also drags in noise. One page load can fire dozens of requests to analytics services, font hosts, and content delivery networks that have nothing to do with the target. Both tools fix this the same way: define a scope, meaning the set of hosts under test, and filter the history down to it. Burp calls the setting Target scope; ZAP calls the equivalent a context. With scope set to shop.example alone, the history stops showing third-party chatter and starts reading like a clean list of the app's own traffic.

Where a tester looks inside each request matters as much as which request. User input rides in a handful of predictable places: the query string after a ? in the path, the parameters in a POST body, the cookie value, and sometimes a custom header the app trusts, like X-User-Id. Every one of those is a value the browser sent and the server has to re-check. Those are the bytes worth bending.

Repeater: one request, many tries

Editing a request in the intercept window is a one-shot. Forward it and it is gone. Testing wants the opposite: the same request sent again and again with one change each time. That is what a Repeater tool is for. Burp names its version Repeater; ZAP calls the same feature Requester. The behavior is identical.

A tester right-clicks an interesting request in the history and sends it to Repeater, which opens the full raw request in an editor beside an empty response pane. Send it, and the response appears. Change one field, send again, watch the response move. No browser, no clicking back through the app to reach the endpoint, no session to rebuild. One request, isolated on a workbench.

The discipline is one variable at a time. Take the order request straight from the history:

GET /api/orders/1001 HTTP/1.1
Host: shop.example
Cookie: session=9f2c8a1b4d

Sent as-is, the response is the tester's own order:

Now change 1001 to 1002 in the Repeater editor and send again:

Same session cookie, a different id, and the server handed over another customer's data. That 200 OK on someone else's record is a finding: broken access control, the exact class the next lesson ranks first. Had the server answered 403 Forbidden or 404 Not Found, the check would have held. The value of Repeater is that the two requests differ by a single character, so the different response can only be that character's doing.

The raw request is just text, which means it is portable. The same bytes Repeater sends can go out from a command line, which is why the earlier curl work still applies once the interesting request is found.

$curl -v -H 'Cookie: session=9f2c8a1b4d' http://shop.example/api/orders/1002

Reading HTTPS means trusting the proxy's certificate

Most real targets speak HTTPS, and HTTPS wraps the request in TLS encryption so nothing in the middle can read it. An intercepting proxy is in the middle, which is the whole problem it has to solve. It solves it by presenting its own certificate to the browser for each site and decrypting the traffic itself. That is a deliberate machine-in-the-middle, and the browser rejects it unless it has been told to trust the proxy's certificate first.

So the setup has two steps. First, point the browser's proxy setting at the tool's address, which is 127.0.0.1:8080 by default for both Burp and ZAP, so traffic flows through it. Second, install the proxy's certificate authority into the browser's trusted store. Skip the second step and every HTTPS site throws a certificate warning while the proxy sees only encrypted bytes it cannot open. This is the most common reason a fresh proxy setup shows nothing useful in its history.

Now a tester can see any request, freeze it, rewrite any byte, and replay it until the server does something it should not. That is the instrument. What it does not hand over is a target list: which fields reward the effort, which requests are worth bending, which responses signal a real vulnerability instead of a dead end. The next lesson, the OWASP Top 10, is that map, the ranked catalog of the ten flaws worth hunting and the first probe to try for each.