InfoSec 3001 — Information Security from the Offensive Perspective

Step 132. Burp Suite 1: Intercepting with a Proxy — Slipping Between Browser and Server

Step 132. Burp Suite 1: Intercepting with a Proxy — Slipping Between Browser and Server

Level 2 — Introduction to Security and Attack Skill Basics | Difficulty ★★☆☆☆ | Estimated time: 2 hours

Prerequisites: Step 131 (the login/session web app) and Step 73 (HTTP). Kali comes with Burp Suite Community built in.

  • What you need: Kali (with built-in Burp Suite Community) or the Windows installer, and Step 131’s web app. Burp’s GUI screens are marked as screen examples; the proxy-principle experiments are measured (2026-09-09, a Python mini proxy + curl).
  • ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.

Eighty percent of web hacking fits in one sentence — catch the request, look at it, change it, send it. Burp Suite is the tool for that job. It slips between browser and server as a transparent middleman, stops every passing request in its tracks, lets you look inside, change it, and send it on. Today is the first step — learning to intercept with a proxy.

1. Learning Objectives

By the end of this chapter, you will be able to:

  • Explain what a proxy does between a browser and a server
  • Start Burp Suite as a temporary project and catch requests with the built-in browser
  • Forward/Drop requests while Intercept is on
  • Modify the parameters of an intercepted login request and observe the difference in the server’s response
  • Read raw Requests/Responses in HTTP history

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category Details
Language/environment Burp Suite Community (built into Kali), target is my own web app from Step 131; principle measurements use Python + curl
Today’s tools Burp Proxy (Intercept, HTTP history), curl -x (requests via a proxy)
Concepts needed Proxy, man-in-the-middle (MITM), intercept, Forward/Drop, CA certificates
Today’s artifact A record of intercepting and modifying a login request + a proxy-principle measurement log

2-1. The Proxy — Both Agent and Wiretap Point

A proxy is an "agent." Instead of the browser talking to the server directly, you ask the proxy, and the proxy relays it and brings back the response. Its original uses are caching and bypassing, but in security this very structure becomes an observation point — every request passes through the proxy’s hands.

Burp Suite opens a proxy at 127.0.0.1:8080. Once the browser is set to "send all traffic there," the HTTP request from the moment you press the login button appears on Burp’s screen raw, exactly as it is.

2-2. Intercept — The Button That Stops Requests

When Burp’s Intercept is on, a request stops right before it reaches the server. The screen shows the raw request, and you get three choices.

  • Forward — send it to the server (modified, if you modified it)
  • Drop — throw it away. The server never even knows the request came
  • Edit, then Forward — change anything — parameters, headers, cookies — then send

In Step 131 you learned that "every input arriving at the server can be manipulated." Intercept is the tool that turns that manipulation into a single button press.

2-3. HTTPS and Certificates — The Middleman’s Only Barrier

HTTPS traffic is encrypted, so even a proxy can’t see the contents. Burp solves this with its own CA certificate — once the browser is made to trust Burp as a certificate authority, Burp decrypts in the middle, looks, and re-encrypts (the man-in-the-middle structure itself — which is why this tool is used only in your own lab).

That setup is fiddly at first, so today we use the Burp built-in browser — the certificate and proxy settings come pre-configured, so requests are caught the moment it opens.

3. Follow Along

3-1. Starting Burp and the Built-in Browser

Launch Burp Suite from the Kali menu, and start with a Temporary project → default settings. Among the top tabs, open Proxy → the Intercept sub-tab, and press the Open browser button.

Screen example: the built-in browser (Chromium-based) opens, and when you type your web app’s address (http://127.0.0.1:5000 — have the Step 131 server running beforehand) into the address bar, the raw request freezes on Burp’s screen.

GET / HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: Mozilla/5.0 ...
Accept: text/html,...

How to read it: the browser is still loading — because the request is being held by Burp. This screen is "the state where a request has been stopped."

3-2. Forward and Drop — Holding a Request’s Life in Your Hands

Press Forward in front of the stopped request, and the browser’s loading finishes and the page appears. Press Drop, and the browser waits forever until it errors out — the server doesn’t even have a record of the request arriving (no line gets written in the server log — recall Step 131’s 3-8 log).

As an experiment, press Forward and Drop alternately a few times, and once your hands get used to it, switch Intercept is on → click to turn it off. While off, requests pass through without stopping, but all of them get recorded in HTTP history — the working habit is to leave it off normally and turn it on only at the moment you want to catch something (right before submitting a login).

3-3. Intercepting and Modifying a Login Request

Now for today’s core. Type a username and password into the login form of the Step 131 web app, and switch Intercept on right before submitting. Press the submit button and the POST request stops.

Screen example (the intercepted request):

POST /login HTTP/1.1
Host: 127.0.0.1:5000
Content-Type: application/x-www-form-urlencoded
Content-Length: 24

uid=nadia&pw=blue-fox-31

Change pw=blue-fox-31 in the last line to pw=hack and Forward. What does the server answer — just as you built it in Step 131, a wrong password returns 401 and "Login failed." Conversely, send it with the correct value and 302 plus a session cookie comes back.

Why: you just swapped in the middle a request the browser made, and the server never asked whether it was the original or a forgery. The "form’s text box" is only a user interface — what arrives at the server is one chunk of text, and the fact that you can write it however you like is today’s takeaway.

3-4. Confirming the Proxy’s Principle Yourself — A 30-Line Mini Burp

To see the essence of what Burp does beyond the GUI, we built a minimal proxy in Python and measured it. It receives a request, prints the contents, then relays it to the real server — a scale model of Burp.

Input: launch proxy.py (a 30-line proxy that prints requests to a log and forwards them to the original destination — you’ll write the full code yourself in the mission) on port 8080, and tell curl to "go through the proxy."

python proxy.py &          # listening on 127.0.0.1:8080
curl -x http://127.0.0.1:8080 -X POST -d "uid=nadia&pw=blue-fox-31" http://127.0.0.1:5000/login

Output (measured 2026-09-09, the proxy’s log):

[Proxy started] 127.0.0.1:8080 — waiting for requests
==================================================
[Intercepted request] POST http://127.0.0.1:5000/login HTTP/1.1
    Host: 127.0.0.1:5000
    User-Agent: curl/8.11.0
    Accept: */*
    Proxy-Connection: Keep-Alive
    Content-Length: 24
    Content-Type: application/x-www-form-urlencoded
    [Body] uid=nadia&pw=blue-fox-31
==================================================

How to read it: the -x option told curl "ask the proxy at 8080," and the proxy saw the entire request — headers, and even the password in the login body — in plaintext. What Burp shows on screen is exactly this. Only the tool differs; the principle is the same.

Why: over HTTP (no encryption), a middleman reads everything. This is the technical substance behind "café Wi-Fi is dangerous," and also the reason HTTPS is necessary.

3-5. HTTP History — The Ledger of Every Request That Passed

Open the Proxy → HTTP history tab. The requests that passed while Intercept was off are recorded in rows with number, method, address, and status code. Click a row and the raw Request/Response appears side by side below.

Screen example (the history list):

#   Host              Method  URL         Status  Length
1   127.0.0.1:5000    GET     /           200     124
2   127.0.0.1:5000    GET     /login      200     271
3   127.0.0.1:5000    POST    /login      302     276
4   127.0.0.1:5000    GET     /dashboard  200     160

How to read it: this ledger corresponds exactly to Step 131’s server log — the requester’s ledger and the receiver’s ledger. It wouldn’t be an exaggeration to say web analysis is the work of comparing these two ledgers.

4. Missions & Exercises

Mission — Intercepting a Login and a Modification Record

  1. Start Burp Suite as a temporary project and open the Step 131 web app in the built-in browser.
  2. With Intercept on, catch GET /login and experience Forward and Drop once each.
  3. Catch the login POST, change the password to a wrong value, Forward → confirm the 401 response and record the screen.
  4. Catch it again and Forward with the correct value → find the 302 + Set-Cookie response in HTTP history’s Response pane and record it.
  5. (Challenge) Write the 3-4 mini proxy yourself — code that prints the first line and body of requests received on 8080 and forwards them to the server on 5000. You learned sockets in Steps 77–78.
  6. Write proxy-and-intercept.md in your wiki — one diagram of the proxy structure, Intercept’s three choices, and 3 lines on why HTTPS needs a certificate.

Exercises

Exercise 1. Explain why the proxy’s original uses (caching, bypassing) and its security use (observation point) come from the same structure.

Exercise 2. Explain the difference between Intercept’s Forward and Drop from the server log’s perspective.

Exercise 3. In the 3-4 measurement, the proxy could see the password in plaintext. Why is the same thing not immediately possible with HTTPS, and with what structure does Burp work around it?

Exercise 4. The browser’s login form shows asterisks in the "password box," yet the password is visible in the request Burp caught. What does this difference tell you?

5. Model Answers & Completion Criteria

Mission Model Answer

Verification points:

  1. Traces of interception: is there a record of the request stopped with Intercept on, and the page loaded after Forward?
  2. The contrast of modification: for the same POST /login, are the responses to a wrong value (401) and a correct value (302 + Set-Cookie) recorded side by side — clicking the two requests’ Responses in HTTP history confirms this.
  3. The challenge’s mini-proxy skeleton:
import socket

srv = socket.socket()
srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind(("127.0.0.1", 8080))
srv.listen(5)
while True:
    conn, _ = srv.accept()
    data = conn.recv(65536)
    print(data.decode("iso-8859-1"))            # print the intercepted contents
    up = socket.create_connection(("127.0.0.1", 5000))
    up.sendall(data)                            # forward to the real server
    resp = up.recv(65536)
    conn.sendall(resp)                          # return the response
    up.close(); conn.close()

Being a simple version, it has limits — a POST body may get cut off and the response is read only once. "Reading the body to the end (parsing Content-Length)" is the difference between a real proxy and a toy proxy. If you thought it through to that point, the challenge is complete.

Exercise Answers

Answer 1. Because the proxy’s very definition is "an agent through whose hands all traffic passes." To relay on your behalf it must receive the contents, and received contents can be read — caching spent that visibility on performance, and security tools spend the same visibility on observation and modification. The structure is the same; the use splits by the owner’s intent.

Answer 2. Forward delivers the request to the server, so one line "POST /login HTTP/1.1" remains in the server log. Drop never lets the request reach the server, so no line appears at all — only the browser suffers a timeout error. In attack experiments, Drop is the button for "this request never happened."

Answer 3. With HTTPS, the browser and server form an encrypted channel directly, so only ciphertext passes by the proxy in the middle. Burp installs its own CA certificate into the browser and forms two separate encrypted channels — one between browser and Burp, one between Burp and server — a legitimate man-in-the-middle (MITM) structure that decrypts, looks, and re-encrypts in the middle. The reason this is possible (I installed a certificate into my own browser) is also the reason abuse is forbidden.

Answer 4. That the asterisks are a screen trick, not protection of the data. The moment the form is submitted, the password rides the HTTP body as plaintext, and a middleman sees it as is. "Masking the input field" and "protecting transmission (HTTPS)" are stories of completely different layers.

Completion Criteria Checklist

  • [ ] I can start Burp Suite as a temporary project
  • [ ] I confirmed requests get caught in the built-in browser
  • [ ] I can use Forward and Drop with Intercept on
  • [ ] I modified an intercepted login request’s parameters and observed the difference in the server’s response
  • [ ] I can read raw Requests/Responses in HTTP history
  • [ ] I confirmed with the mini-proxy measurement that a middleman sees plaintext over HTTP

6. Common Pitfalls & Fixes

Wall 1. The browser just keeps loading

Symptom: the page never appears and the spinner keeps turning.

Cause: Intercept is on and the request is stopped in Burp. It’s not the browser’s fault.

Fix: go to Burp’s Proxy → Intercept and Forward the stopped request, or click Intercept is on to turn it off.

Wall 2. Nothing gets caught in an external browser (Firefox/Chrome)

Symptom: the built-in browser works, but my usual browser doesn’t pass through Burp.

Cause: that browser has no proxy setting (127.0.0.1:8080). Browsers don’t find a proxy on their own — you have to set it.

Fix: the built-in browser is enough at first. If you need an external browser, set a manual proxy to 127.0.0.1:8080 in the browser’s settings — to catch HTTPS too, you’ll additionally need to install the CA certificate (Wall 3).

Wall 3. I get a certificate error on HTTPS sites

Symptom: visiting HTTPS from an external (not built-in) browser shows a "this connection is not secure" warning.

Cause: the browser doesn’t trust Burp’s CA certificate, so it judges Burp’s middleman channel to be fake.

Fix: from a browser with the proxy configured, visit http://burp, download the CA Certificate, and register it as a trusted authority in the browser’s certificate manager. Make a habit of removing it when practice ends — while that certificate exists, your browser trusts a middleman holding that key.

Wall 4. Burp says 8080 is already in use

Symptom (screen example): an error of the java.net.BindException: Address already in use family.

Cause: a previously launched Burp or another program (including 3-4’s mini proxy!) is holding 8080.

Fix: terminate the proxy/server processes in other terminals. The habit of shutting down what you launched after practice is this wall’s vaccine.

Wall 5. Korean text in a caught request looks garbled

Symptom: Korean in the request body shows as broken characters.

Cause: it’s only a display-encoding issue; the data itself is fine in most cases.

Fix: check the font and encoding (UTF-8) in Burp’s User options → Display. If you want to know the value the server actually received, comparing against the server-side log (Step 131’s console) is the surest way.

7. Summary

Today’s Concepts

Concept One-line explanation
Proxy Traffic’s agent — in security, an observation/modification point
Intercept A feature that stops requests right before the server to view and edit
Forward / Drop Send it / pretend it never happened
HTTP history The ledger of past requests and responses — the requester-side pair of the server log
CA certificate The root of trust Burp plants in the browser to open up HTTPS

Today’s Commands & Actions

Command/action What it does
Proxy → Intercept → on/off Turn intercepting on/off
Open browser Open the pre-configured built-in browser
Forward / Drop Send / discard the stopped request
HTTP history tab View raw past requests/responses
curl -x http://127.0.0.1:8080 <URL> Send a request via a proxy
http://burp CA certificate download page

An Instinct More Important Than Commands

From today on, a web page has two layers for you — the visible screen, and the raw requests flowing beneath it. The moment you turn Burp on, the lower floor opens, and the act of "typing into a form" turns into the reality of "throwing text at a server."

And as you confirmed in 3-4, this tool’s essence is 30 lines of socket code. Burp merely adds convenience on top — having seen the principle, you can build a middleman even without the tool, and so you know exactly what a middleman can see.

Once every box is checked, Step 132 is complete. Click the checkbox in the sidebar to save your progress.

← 이전 스텝
다음 스텝 →