Burp’s proxy, placed on a lab browser

The listener is not the application

Harbor Ledger is a small invoicing app you run for yourself on a host-only machine or on loopback. In these lessons it listens at http://127.0.0.1:3000. Burp’s proxy listens somewhere else. The default is 127.0.0.1:8080. The lab browser is configured to send its traffic to 8080, and Burp opens a new connection to port 3000. If both programs bind the same port, one of them fails to start, and the failure looks like a mysterious empty browser.

The proxy is a recording desk in the middle. It does not replace the app, and it does not grant permission to point the browser at a host that is outside the lab. Before the first request, the scope is the sentence you can point at: this process, this port, this afternoon.

A browser that exists for the lab

Burp can open its own browser, already pointed at the listener and already trusting Burp’s certificate authority. That is the clean setup for Harbor Ledger. The other clean setup is a spare Firefox profile whose proxy settings name 127.0.0.1:8080 and whose certificate store holds the exported CA. Either choice keeps the trust decision inside a profile you can throw away.

The profile you use for mail, banking, and work stays unchanged. A CA that can sign for any host is a large amount of trust to attach to a daily browser. The lab is plain HTTP on loopback, so the certificate sits idle during this exercise, and it is still the right habit to install it only where the lab runs.

• Confirm the listener is bound to 127.0.0.1, not to every interface.
• Open the built-in browser from the Proxy tab.
• Visit http://127.0.0.1:3000 and sign in with the seed account the lab README prints for Avery.
• When you stop, close that browser before you close Burp.

What a single page becomes in history

Avery’s invoice screen shows a title and a status. The address bar shows /invoices/1042. The history, once the page has loaded, also shows the static script, the stylesheet, and GET /api/invoices/1042 with Accept: application/json and a Cookie header. The JSON body carries id, title, owner, and status. The owner field is how you check that the signed-in lab account matches the row.

Write the map from the history, not from memory of the pixels. The screen omitted the owner. The API included it. That difference is the sort of fact a proxy is for: the response held a field the interface did not paint.

GET /api/invoices/1042 HTTP/1.1
Host: 127.0.0.1:3000
Accept: application/json
Cookie: session=lab-session-avery

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"id":"1042","title":"April retainer","owner":"avery@ledger.lab","status":"open"}

Worked case: the first minute on Harbor Ledger

Start the lab app so that a browser on the same machine can open http://127.0.0.1:3000. Start Burp with a temporary project. On the Proxy listener, confirm 127.0.0.1 and port 8080. Open the built-in browser, go to the lab origin, and sign in as Avery with the seed account. Click the invoice titled April retainer. Leave intercept off for this pass so the click behaves the way a clerk’s click behaves.

Stop when the detail page is visible. In HTTP history, select the row whose path is /api/invoices/1042. Read the request cookie and the response owner in the same glance. If the owner is avery@ledger.lab, the lab behaved for this account on this row. If the owner names someone else, you already have the observation: this response, this session, this field. You do not need a second identifier to write that sentence, and you stop there.

Closing the desk

A temporary project discards the history when Burp closes, which is what you want for a first look that you have already written up. A project saved to disk keeps every cookie. The later lesson on project files is the rule for that file. For this lesson, the closing check is smaller: the built-in browser is quit, the listener is not something you left bound for the rest of the day, and the daily browser never had a proxy setting typed into it.

The skill is placement. You can say which process listened, which process served the app, which browser was allowed to trust the tool, and which single request proved what the invoice page had fetched.