HTTP Traffic Deep Dive: Requests, Responses & Web Attack Patterns

Prerequisites

• FND-K003: Networking Fundamentals for Security Practitioners
• FND-K005: DNS Internals & Anomaly Detection (recommended)

Why This Lesson Matters

HTTP is the protocol of the modern internet. It carries web application traffic, API calls, authentication exchanges, and — when misconfigured — cleartext credentials and sensitive data. Nearly every web-based attack originates in a misunderstood HTTP exchange: an unvalidated parameter, a missing security header, a predictable session token.

This lesson goes deeper than the overview in FND-K003. You will understand every field of an HTTP request and response, learn which headers matter for security, and see how common attacks like SQL injection, XSS, and CSRF manifest in HTTP traffic. This is the foundation for every web application security lesson in the PEN, STE, and COA paths.

1. HTTP Request Anatomy

Every HTTP request has three parts: a request line, headers, and an optional body.

POST /api/login HTTP/1.1                          ← Request line
Host: app.example.com                             ← Required header (HTTP/1.1)
Content-Type: application/json                    ← Describes body format
Content-Length: 42                                ← Body length in bytes
Cookie: session=abc123; csrf_token=xyz789         ← Cookies
Authorization: Bearer eyJhbGci...                 ← Auth token
User-Agent: Mozilla/5.0 (Windows NT 10.0...)      ← Client identification
Accept: application/json                          ← Accepted response formats
Referer: https://app.example.com/login            ← Origin page
X-Forwarded-For: 203.0.113.5                      ← Client IP (via proxy)
                                                  ← Blank line separates headers from body
{"username": "alice", "password": "secret123"}    ← Request body

1.1 HTTP Methods in Security Context

GET vs. POST for sensitive parameters: Using GET for password parameters (e.g., /reset?token=abc123&new_pass=secret) is dangerous because: - The URL (including parameters) appears in server access logs - The URL is stored in browser history - The URL is sent in the Referer header to any third-party resources on the next page - The URL may be cached by proxies and CDNs

POST is not a security boundary — it just means the parameters are in the body instead of the URL. POST requests are equally interceptable by anyone with network access (Wireshark, proxy, etc.).

1.2 Security-Critical Request Headers

2. HTTP Response Anatomy

HTTP/1.1 200 OK                                    ← Status line
Content-Type: application/json; charset=utf-8      ← Response body type
Content-Length: 87                                 ← Body length
Set-Cookie: session=new_token; HttpOnly; Secure; SameSite=Strict  ← Set cookies
Strict-Transport-Security: max-age=31536000; includeSubDomains    ← HSTS
Content-Security-Policy: default-src 'self'        ← CSP
X-Content-Type-Options: nosniff                    ← Prevent MIME sniffing
X-Frame-Options: DENY                             ← Prevent clickjacking
Cache-Control: no-store, no-cache                 ← Prevent sensitive data caching
Access-Control-Allow-Origin: https://trusted.com  ← CORS policy
                                                  ← Blank line
{"status": "ok", "user": "alice", "role": "user"} ← Response body

2.1 Security Response Headers

These headers are not optional extras — missing or misconfigured security headers are reportable findings in every web application security assessment.

Set-Cookie flags:

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=3600

Strict-Transport-Security (HSTS): Instructs the browser to only connect via HTTPS for max-age seconds. Prevents SSL stripping attacks. includeSubDomains extends to all subdomains. Once set, the browser will refuse HTTP connections without a server round-trip.

Content-Security-Policy (CSP): Specifies allowed sources for scripts, styles, images, and other resources. A well-configured CSP is the single most effective XSS mitigation:

Content-Security-Policy: 
  default-src 'self';             ← Only load from same origin
  script-src 'self' cdn.example.com;  ← Scripts only from self and trusted CDN
  style-src 'self' 'unsafe-inline';  ← unsafe-inline weakens the policy
  img-src *;                        ← Images from anywhere
  frame-ancestors 'none';          ← Equivalent to X-Frame-Options: DENY
  report-uri /csp-report;           ← Send violation reports

3. HTTP Status Codes — Security Significance

The difference between 401 and 403 matters: - 401 means "unauthenticated" — you need to provide credentials - 403 means "authenticated but not authorised" — you are logged in but do not have permission - Returning 403 for unauthenticated requests leaks the existence of the endpoint

4. Sessions and Authentication

4.1 How Session Management Works

HTTP is stateless — each request is independent. Sessions tie multiple requests to the same user:

1. Client submits credentials: POST /login {user: alice, pass: secret}
2. Server validates credentials against the database
3. Server generates a cryptographically random session token: "abc123xyz789..."
4. Server stores: {token: "abc123xyz789...", user: alice, expiry: 1hr}
5. Server sends: Set-Cookie: session=abc123xyz789; HttpOnly; Secure
6. Client sends this cookie with every subsequent request
7. Server looks up the token in its session store to identify the user

What makes a session token secure: - Long enough to be unpredictable (>= 128 bits of entropy, typically 32+ hex chars) - Cryptographically random (not sequential, not time-based) - Stored server-side with the user association - Invalidated on logout - Regenerated after login (prevents session fixation) - Short expiry for sensitive applications (15–60 minutes)

What makes a session token insecure: - Sequential integers (easily guessable: if your token is 12345, try 12344 and 12346) - Timestamp-based (predictable by brute-force of time window) - Stored in localStorage (accessible to XSS) - Missing HttpOnly flag (stealable by XSS) - Not invalidated on logout (usable after logout)

4.2 How SQL Injection Breaks Authentication

SQL injection is one of the most critical web vulnerabilities. In an authentication context it can bypass the login entirely.

Vulnerable login (PHP/MySQL):

$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = $db->query($query);
if ($result->num_rows > 0) {
    // Authentication success
}

The attack:

If the attacker inputs username = admin' -- and any password, the query becomes:

SELECT * FROM users WHERE username = 'admin' --' AND password = '
                                             ^^
                                             -- comments out the password check!

The -- is an SQL comment that causes the rest of the query to be ignored. The query only checks if the username admin exists, not whether the password matches. Result: the attacker is authenticated as admin without knowing the password.

Other bypass payloads:

' OR 1=1 --        → returns all rows (first user is usually admin)
' OR 'x'='x        → always true condition
admin'/*            → MySQL block comment
' OR 1=1#           → MySQL hash comment

In a PCAP, SQL injection looks like:

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=admin'%20--&password=anything
         ^^^^^^^^^^^^
         URL-encoded ' --

The percent-encoding %20 = space, %27 = single quote. When you see these in an HTTP POST body targeting an auth endpoint, it is a SQLi probe.

Remediation:

// Safe: parameterised query (prepared statement)
$stmt = $db->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();

With parameterised queries, the database driver treats the user input as literal data — not as SQL syntax. The single quote is sent to the database as a character, not as a string delimiter.

5. Analysing Web Traffic with Burp Suite / tshark

5.1 tshark for HTTP Analysis

# Show all HTTP requests: method, URI, host
tshark -r web.pcap -Y "http.request" 
  -T fields -e ip.src -e http.request.method -e http.host -e http.request.uri

# Show POST request bodies
tshark -r web.pcap -Y "http.request.method == POST" 
  -T fields -e ip.src -e http.request.uri -e http.file_data

# Find 500 errors (possible injection)
tshark -r web.pcap -Y "http.response.code == 500" 
  -T fields -e ip.dst -e http.request.uri

# Find SQL injection patterns in URIs
tshark -r web.pcap -Y "http.request.uri contains "UNION"
  || http.request.uri contains "SELECT"
  || http.request.uri contains "OR+1=1"" 
  -T fields -e ip.src -e http.request.full_uri

# Extract cookies from requests
tshark -r web.pcap -Y "http.cookie" 
  -T fields -e ip.src -e http.cookie

5.2 Identifying Attack Patterns in Traffic

6. Common Mistakes

Mistake 1: Thinking POST is more secure than GET. POST hides parameters from the URL but not from the network (in HTTP), not from the browser developer tools, and not from a proxy. Never treat POST as a security boundary.

Mistake 2: Using 200 OK for authentication failures. Returning 200 OK with a JSON body {"error": "invalid credentials"} is a common mistake. The correct code is 401 Unauthorized. Returning 200 breaks automated security scanners and confuses log analysis.

Mistake 3: Setting Access-Control-Allow-Origin: * on authenticated endpoints. A wildcard CORS policy on an endpoint that returns sensitive data means any website can read that data from a victim's browser (if the victim is authenticated). CORS wildcard is only safe for truly public, unauthenticated data.

Mistake 4: Forgetting that Referer leaks internal paths. If an internal admin page links to an external resource, the Referer header will expose the internal URL (e.g., https://internal.corp.com/admin/secret-panel) to the external server.

Mistake 5: Session tokens in URLs. Passing session tokens as URL parameters (e.g., /dashboard?session=abc123) means the token appears in server logs, browser history, and Referer headers. Tokens belong in cookies with HttpOnly and Secure flags.

7. Guided Example — Spotting a Login Bypass in a PCAP

You are investigating a web server compromise. You have a PCAP from the time of the incident.

Step 1: Find POST requests to the login endpoint

tshark -r incident.pcap -Y "http.request.method == POST && http.request.uri contains "/login"" 
  -T fields -e frame.time -e ip.src -e http.file_data

Output:

2026-06-08 14:32:17  10.0.0.5   username=admin%27+--&password=x
2026-06-08 14:32:18  10.0.0.5   username=admin%27+OR+1%3D1--&password=x
2026-06-08 14:32:19  10.0.0.5   username=admin%27+--&password=anything

The %27 is URL-encoded ' (single quote). The %3D is =. These are classic SQL injection probes.

Step 2: Find the successful login (200 or 302 redirect after successful auth)

tshark -r incident.pcap -Y "ip.src == 10.0.0.5 && (http.response.code == 200 || http.response.code == 302)" 
  -T fields -e frame.time -e http.response.code -e http.location

Step 3: Follow the session after login

Once you identify the session token set in the response cookie, filter for all requests using that token to see what the attacker did post-authentication.

Step 4: Document

• Attack: SQL injection login bypass (T1190 — Exploit Public-Facing Application)
• Source IP: 10.0.0.5
• Payload: admin' -- (comment-based authentication bypass)
• Result: Successful authentication as admin without valid credentials
• Evidence: Frame 47 (POST with SQLi payload), Frame 49 (302 redirect to /dashboard)

8. Practice Exercises

1. Decode the following URL-encoded strings and identify the attack type:
2. username=admin%27+OR+%271%27%3D%271
3. search=%3Cscript%3Ealert(1)%3C%2Fscript%3E

4. file=..%2F..%2F..%2Fetc%2Fpasswd

5. Examine this Set-Cookie header and identify every security issue: Set-Cookie: session=12345; path=/

6. A web application returns the following response to a failed login: HTTP/1.1 200 OK {"success": false, "message": "User alice not found"}

7. What two security problems does this response have?

8. Write a tshark filter that shows all HTTP responses with status code 500 or higher, including the request URI that triggered each error.

9. Lab

Assessment mode: flag

challenge_spec_id: 102 — Login bypass via simple SQLi

A web application has a login form that is vulnerable to SQL injection. Your task:

1. Access the login form
2. Use SQL injection to bypass authentication as the admin user without knowing their password
3. After bypassing authentication, the application displays the flag on the admin dashboard

Hint: Start with a single quote test, then try a comment-based bypass.

10. Framework Alignment

11. Further Reading

• OWASP Top 10 — https://owasp.org/www-project-top-ten/ — The canonical list of most critical web vulnerabilities
• OWASP Testing Guide (v4.2) — Comprehensive methodology for web application security testing
• PortSwigger Web Security Academy — https://portswigger.net/web-security — Free, hands-on labs for every web vulnerability class
• HTTP: The Definitive Guide — Gourley & Totty — Deep reference on HTTP internals
• RFC 9110 — HTTP Semantics (the current HTTP specification)
• SANS Whitepaper: HTTP Response Headers for Security — Concise reference for security header deployment

["Identify every field in an HTTP request and response and explain the security implications of the Cookie, Authorization, and X-Forwarded-For headers", "Describe the security flags available on the Set-Cookie header (HttpOnly, Secure, SameSite) and explain the attack each flag prevents", "Explain how SQL injection breaks authentication by manipulating query structure, and identify a SQLi payload in URL-encoded HTTP traffic", "Use tshark to filter a PCAP for POST requests to a login endpoint and identify SQL injection probe payloads in the request body"]

Prerequisites → Why this matters → HTTP request anatomy (methods, security headers in depth) → HTTP response anatomy (status codes, security response headers: HSTS, CSP, CORS, Set-Cookie flags) → Session management (how sessions work, what makes a token secure, token in URLs vs cookies) → SQL injection in authentication context (mechanism, bypass payloads, how it looks in PCAP, parameterised query remediation) → tshark for HTTP analysis (filters, pattern table) → Common mistakes → Guided example (login bypass identification in PCAP) → Practice exercises → Lab (flag, spec 102) → Framework alignment → Further reading