HTTP & Burp Suite

Before you can find vulnerabilities in a web application, you need to understand the protocol those applications speak. HTTP is not just a browser concern - it is the attack surface. Every header, every cookie, every parameter is a potential injection point, an information leak, or an access control bypass waiting to be found. This lesson makes HTTP legible to an attacker and then introduces the tool that lets you see and manipulate it in real time: Burp Suite.

HTTP in 60 Seconds

HTTP (HyperText Transfer Protocol) is a stateless, text-based request/response protocol. A client (your browser, curl, Burp) sends a request; a server sends a response. That is the entire model. The complexity - and the attack surface - lives in the details.

Modern web traffic runs over HTTPS, which is HTTP wrapped in TLS. From an attacker's perspective (using a proxy like Burp that performs a MITM on your own traffic), you see the plaintext HTTP inside the TLS tunnel. The TLS layer matters for certificate validation attacks, but for most web app testing, you work with the HTTP content.

HTTP Methods

The method (also called a verb) tells the server what kind of action the client is requesting. From a security standpoint:

HTTP Headers

Headers are metadata about the request or response. They appear after the method line, one per line, as Name: Value. A typical request looks like:

GET /api/user/profile?id=42 HTTP/1.1
Host: app.example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) ...
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Cookie: session=abc123def456; csrf_token=xyz789
Referer: https://app.example.com/dashboard

Security-relevant request headers

Host - The virtual hostname the client is requesting. Host header injection attacks trick servers into generating poisoned password reset links or cache poisoning by sending an unexpected Host value.

Authorization - Carries credentials. Bearer <token> (JWT), Basic <base64(user:pass)>, or API keys. A missing or bypassable authorization check here is A01 (Broken Access Control).

Cookie - Session identifiers and other state. Every cookie is a potential theft or forgery target.

Referer - Where the request came from. Servers sometimes use this for access control ("only allow if coming from our site") - which is trivially bypassed by setting the header yourself.

Origin - Set by browsers for cross-origin requests (CORS). Servers use this to decide whether to allow cross-origin access. CORS misconfigurations are a major bug class.

X-Forwarded-For - The client's real IP when behind a proxy. Some applications use this for IP-based access control or rate limiting - all of which can be bypassed by simply setting this header.

Security-relevant response headers (and what's missing)

HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; script-src 'self'
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
Server: nginx
X-Powered-By: PHP/8.1.0

The absent security headers are as important as the present ones:

• Missing Content-Security-Policy means XSS has no mitigation layer.
• Missing X-Frame-Options means the page can be embedded in an iframe (clickjacking).
• Missing HttpOnly on session cookies means JavaScript can read them.
• A present X-Powered-By or verbose Server header leaks technology versions.

HTTP Status Codes

Status codes tell you what happened. For attackers, they are a critical signal during fuzzing and enumeration:

Cookies

Cookies are key-value pairs stored by the browser and sent back to the server automatically on every subsequent request to the matching domain/path. They are the primary session management mechanism on the web.

Set-Cookie: session=eyJhbGciOiJIUzI1NiJ9...; 
            Path=/; 
            Domain=app.example.com;
            Expires=Sat, 01 Jan 2028 00:00:00 GMT;
            HttpOnly;
            Secure;
            SameSite=Lax

The security attributes:

HttpOnly - JavaScript cannot read this cookie. Prevents document.cookie theft in XSS attacks. If this flag is missing on a session cookie, a stored XSS becomes session hijacking.

Secure - Cookie is only sent over HTTPS. Without this, the cookie is transmitted in plaintext over HTTP connections.

SameSite=Strict|Lax|None - Controls whether the cookie is sent on cross-site requests. The primary CSRF mitigation. Lax (the browser default) prevents most CSRF. None means no cross-site protection.

Domain - Which domains receive the cookie. A cookie scoped to .example.com is sent to evil.example.com if that subdomain is compromised (subdomain takeover feeds back to cookie theft).

Expires/Max-Age - When the cookie expires. Session cookies (no expiry) are invalidated when the browser closes; persistent cookies survive.

URL Parameters and Request Bodies

Data reaches server-side code through several channels, all of which are attacker-controlled:

Query string parameters: GET /search?q=hacker&sort=date These are visible in URLs, logged everywhere, and the first place to test for reflected XSS and parameter tampering.

Form bodies (POST, application/x-www-form-urlencoded):

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
 
username=admin&password=hunter2&_csrf=abc123

JSON bodies:

POST /api/transfer HTTP/1.1
Content-Type: application/json
 
{"from_account": "1234", "to_account": "5678", "amount": 100}

Path parameters: /api/users/42/orders/7 - the 42 and 7 are parameters even though they look like path components. IDOR lives here.

Headers as parameters: Many APIs accept input via custom headers (X-User-Id, X-Role, X-Forwarded-For). These are often less well-validated than body parameters.

Burp Suite: Your HTTP Command Center

Burp Suite (by PortSwigger) is an intercepting proxy and web application testing platform. The Community Edition is free and covers everything in this module. The Professional Edition adds Burp Scanner and a more powerful Intruder - useful, but not required for learning.

The core idea: Burp sits between your browser and the server. Every request your browser makes passes through Burp, where you can inspect, modify, or replay it before it reaches the server.

Setting Up the Proxy

Burp's built-in proxy listens on 127.0.0.1:8080 by default.

Step 1 - Configure your browser. The cleanest approach is to use the Burp browser (built-in Chromium, configured automatically) or install the FoxyProxy browser extension and create a profile pointing to 127.0.0.1:8080.

Step 2 - Install the Burp CA certificate. For HTTPS interception, Burp generates its own TLS certificates. Your browser needs to trust Burp's CA:

Step 3 - Verify interception is working. With Intercept turned ON in the Proxy tab, browse to your target. The request should pause in Burp waiting for your action.

Burp Proxy: Intercept Tab

The Intercept tab catches requests in-flight. When a request is paused:

• Forward - sends it as-is
• Drop - discards it (the browser request fails)
• Action > Send to Repeater - sends a copy to Repeater while also forwarding the original
• Edit directly - modify any field before forwarding

Use intercept for a first pass: browse normally through the application while Burp is intercepting, get a feel for the request structure, then turn intercept off and use the HTTP History (Proxy > HTTP history tab) to review everything.

Burp Repeater: Manual Testing

Repeater is where most of your actual testing happens. Right-click any request in HTTP History and select "Send to Repeater." Now you have a persistent copy of that request that you can:

• Modify any parameter, header, or cookie
• Click Send to fire it
• See the full response on the right
• Click the arrow buttons to step through your modification history

This is how you test for IDOR (change the id parameter), test for SQLi (add a quote to a parameter), test access control (remove the Authorization header), or test header injection (modify the Host header).

Burp Intruder: Automated Fuzzing

Intruder takes a request with marked positions and fires many variations through it. Use it for:

• Password brute-forcing - mark the password field, supply a wordlist
• Parameter fuzzing - mark a parameter, supply an injection payload list (SecLists has dedicated lists for SQLi, XSS, path traversal, etc.)
• Username enumeration - mark the username field, look for response size/time differences

To set up an Intruder attack: send a request from Repeater or History to Intruder (right-click > Send to Intruder). In the Positions tab, clear existing markers (§ symbols) and highlight the value you want to fuzz - Intruder wraps it in § markers. Switch to the Payloads tab, select "Simple list," and load or paste your wordlist. Hit Start attack.

The Basic Testing Workflow

Here is the workflow you will use throughout this module:

Burp's Other Useful Tabs

Target > Site Map - After browsing through an application with Burp running, the site map shows every URL discovered. Great for understanding application scope before drilling down.

Decoder - Convert between URL encoding, Base64, HTML entities, hex, and more. Essential for decoding session tokens, JWT payloads, and obfuscated parameters.

Comparer - Paste two responses side-by-side and diff them. Use this when you have two responses that look similar but need to find the subtle difference (useful for blind SQLi, username enumeration).

Logger (Extensions) - With the Logger++ extension installed, you get richer request logging. Community Edition's built-in logging is sufficient for most tasks.

Practical: Intercepting Your First Request

Here is a minimal workflow against a local DVWA (Damn Vulnerable Web Application) instance:

Key Takeaways

• HTTP is the attack surface. Every method, header, cookie, parameter, and status code is data you use to probe application behavior.
• GET exposes data in URLs (logged everywhere); POST bodies are less visible but equally attacker-controllable. Always test both, and try alternate methods on every endpoint.
• Cookie security attributes - HttpOnly, Secure, SameSite - are what stand between an XSS payload and session hijacking.
• Status codes during fuzzing: 200 = found it, 403 = found it and you are blocked (investigate further), 500 = you broke something (interesting).
• Burp Suite's Proxy captures all traffic; Repeater is for manual iteration; Intruder is for automated payload testing.
• The core workflow: browse fully > review History > send to Repeater > modify and probe > escalate to Intruder or external tools.