// networking basics — module 06

Module 6 — How the Web Works (Because Everything Is Web Now)

Soren Brumbach · · 10 min read

Thesis: The web is the largest attack surface in existence and the busiest source of logs. Both tracks need HTTP in their bones. You met HTTP as a protocol in Module 4 and saw it in a capture in Module 5; here you learn it as a system — request, response, state, sessions, and the browser model — so that web security later becomes learnable instead of overwhelming.

Prerequisite: Module 5 — Reading Traffic: tcpdump & Wireshark. You should be able to read an HTTP exchange in a capture before studying it as a system.

6.1 Why the web gets its own module

Almost everything is a web application now — your bank, your email, your company's internal tools, the API your phone app talks to. That makes HTTP the single most common thing attackers target and defenders monitor. If you can read a request and response fluently — without stopping to think about what a header or a status code means — then the whole enormous field of web security has somewhere to attach. If you can't, it stays a fog. This module builds that fluency.

6.2 HTTP anatomy — request and response

HTTP is a request/response protocol: the client (browser) sends a request, the server sends back a response. That's the whole rhythm. Each has the same three-part shape.

A request:

  GET /login HTTP/1.1                 ← method + path + version   (request line)
  Host: example.com                   ← headers (key: value)
  User-Agent: Mozilla/5.0
  Accept: text/html
                                      ← blank line separates headers from body
  (optional body — form data, JSON…)  ← body (for POST/PUT etc.)

A response:

  HTTP/1.1 200 OK                     ← version + status code + reason   (status line)
  Content-Type: text/html             ← headers
  Content-Length: 1274
  Set-Cookie: session=abc123
                                      ← blank line
  <!DOCTYPE html>...                   ← body (the actual page/data)

Read a few of these and the structure becomes automatic: line 1 is the summary, the headers are metadata, the body is the payload. Every request and response, everywhere, follows this.

6.3 Methods — what the request wants to do

The method (or "verb") states the intent:

  • GET — retrieve a resource. Should not change anything (it's "safe"). Parameters ride in the URL.
  • POST — submit data to be processed (a login, a form, a new record). Changes state. Data rides in the body.
  • PUT — create or replace a resource at a location.
  • PATCH — partially update a resource.
  • DELETE — remove a resource.
  • HEAD — like GET but returns only headers, no body (check existence/metadata cheaply).
  • OPTIONS — ask what methods/capabilities a resource supports.

The security-relevant split: GET and HEAD are "safe" (read-only, no side effects), while POST, PUT, PATCH, DELETE are state-changing. That distinction matters for caching, for what's safe to retry, and for whole classes of attacks (a state-changing action that can be triggered by a simple GET is a classic bug).

6.4 Status codes — how the response reports outcome

The three-digit status code tells you what happened, grouped into families by the first digit:

  • 1xx — informational (rare).
  • 2xx — success. 200 OK, 201 Created, 204 No Content.
  • 3xx — redirection. "Look elsewhere." 301 (permanent), 302/307 (temporary), 304 Not Modified (use your cache).
  • 4xx — client error. You did something wrong. 400 Bad Request, 401 Unauthorized (you're not authenticated), 403 Forbidden (authenticated but not allowed — the AuthN/AuthZ distinction from Module 0!), 404 Not Found, 429 Too Many Requests.
  • 5xx — server error. The server failed. 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.

Know these on sight. A wall of 404s can be someone probing for hidden paths; a spike of 401/403 can be credential guessing; a burst of 500s can be an attack that's breaking the app. The codes are a running commentary on what clients are doing to a server.

6.5 Headers — the metadata that carries the real work

Headers are Key: Value lines that carry everything about the request or response that isn't the body itself. Categories you'll meet constantly:

  • Content — Content-Type (is this HTML, JSON, an image?), Content-Length.
  • Caching — Cache-Control, ETag.
  • Identity/auth — Authorization (credentials/tokens), Cookie and Set-Cookie (§6.7).
  • Client info — User-Agent (which browser), Referer (where you came from).
  • Security headers — Strict-Transport-Security (force HTTPS), Content-Security-Policy (restrict what the page can load), X-Frame-Options (block clickjacking). Their presence or absence is itself a signal about how carefully an app was built.

Headers are a rich signal for both sides: attackers tamper with them (forge a Host, inject via User-Agent, steal via Cookie); defenders read them in logs and set the security ones to harden an app.

6.6 URLs — read one precisely

A URL packs several fields into one string. Learn to decompose it exactly:

   https://user@shop.example.com:443/products/list?category=books&sort=price#reviews
   └─┬─┘   └─┬┘ └──────┬───────┘ └┬┘└─────┬──────┘ └──────────┬──────────┘ └──┬──┘
   scheme  user     host        port     path            query string       fragment
  • scheme — the protocol (https).
  • host — the domain (resolved via DNS, Module 4) or IP.
  • port — defaults to 80 for http, 443 for https if omitted.
  • path — which resource on the server.
  • query string — ?key=value&key=value parameters (where GET data lives — and a prime target for tampering).
  • fragment — #..., handled by the browser only, never sent to the server.

Being able to read a URL precisely is a real skill — a huge amount of web attacking and defending is about what's in that query string and path.

6.7 State on a stateless protocol — cookies and sessions

Here's a fact that surprises beginners: HTTP is stateless. The server does not, by itself, remember you between requests — each request arrives with no memory of the last. So how does a website keep you logged in across dozens of clicks?

Cookies. After you log in, the server sends Set-Cookie: session=abc123. Your browser stores it and automatically sends Cookie: session=abc123 on every subsequent request to that site. The server looks up abc123 in its session store and goes "ah, that's Alice, still logged in." The cookie is a claim ticket; the session is the coat it's holding.

   login  ──POST creds──►  server: "valid! here's Set-Cookie: session=abc123"
   next request ──Cookie: session=abc123──►  server: "that's Alice — proceed"

This is why stealing a session cookie is as good as stealing the password — often better, because it sidesteps authentication entirely and may dodge MFA. If an attacker copies abc123, they are Alice to the server until that session expires. Session security (how cookies are protected: HttpOnly, Secure, SameSite flags) is a whole topic that hangs off this one fact.

6.8 Web authentication at a glance

Building on §6.7 and previewing Module 9, the common ways a browser proves identity to a server:

  • Cookie-based sessions — the §6.7 model; the most common for websites.
  • HTTP Basic/Bearer auth — credentials or a token in the Authorization header. Basic auth sends base64'd username:password (encoding, not encryption — Module 7!) and is only safe over HTTPS.
  • Tokens / JWT — a JSON Web Token is a self-contained, signed token the client presents on each request; common in APIs and single-page apps. You'll meet the signing (crypto) in Module 7 and the identity role in Module 9. For now: it's a tamper-evident ID card the server can verify without a session lookup.

6.9 HTTPS/TLS in transit — what the padlock does and doesn't mean

HTTPS is HTTP wrapped in TLS encryption (full crypto in Module 7). The padlock in the address bar guarantees exactly two things:

  1. Encryption — nobody on the network path can read or modify the traffic (this is why you can't sniff an HTTPS login the way you sniffed a plaintext one in Module 5).
  2. Server identity — a certificate vouches that you're really talking to example.com and not an impostor.

Crucially, the padlock does not mean the site is safe, honest, or not malicious. A phishing site can have a perfectly valid certificate. "HTTPS" means "the connection is private and you're talking to who the URL says" — not "you can trust these people." Beginners conflate these constantly; don't.

6.10 The browser model and same-origin policy

The web is client/server: the server sends HTML/CSS/JavaScript, and the browser renders it into the DOM (Document Object Model — the live, in-memory tree of the page that JavaScript can read and change).

The single most important browser security rule is the same-origin policy: scripts running on one "origin" (scheme + host + port) generally cannot read data from a different origin. Without it, a malicious page you visit could quietly read your open webmail or bank tabs. Most web attacks are, in one way or another, about violating or abusing this boundary — and understanding it conceptually now makes those attacks comprehensible later.

6.11 APIs and JSON

Not all web traffic is pages for humans. APIs (Application Programming Interfaces) let programs talk to servers directly. The dominant style is REST: you make HTTP requests (GET/POST/…) to endpoints (URLs like /api/users/42), and the server responds with data — almost always JSON:

{ "id": 42, "name": "Alice", "roles": ["user", "admin"] }

JSON is the structured data format you'll parse endlessly — from API responses, from tool output, from logs. It ties directly into scripting (Module 10, where you'll parse it in Python) and telemetry (Module 11, where logs are often JSON). Get comfortable reading its { key: value } and [ list ] structure now.

6.12 Infrastructure at a glance

Real web systems aren't one server. Requests often pass through a reverse proxy or load balancer (which distributes traffic across many backend web servers) before reaching the application. Each of these tiers generates logs — the reverse proxy and web server logs are among the richest telemetry a defender has (every request, its path, its status code, its source). Knowing this layering explains where logs come from and why a source IP in a log might be the load balancer, not the real client (which is why headers like X-Forwarded-For exist).

6.13 → Red/Blue

Web apps are the most common entry point, so red teams probe requests, tamper with query strings and headers, hijack sessions by stealing cookies, and abuse APIs — everything in this module is a lever. Blue teams read web-server and reverse-proxy logs, watch for anomalous requests (path-probing 404 storms, injection patterns, credential-stuffing bursts of 401s), set security headers, and protect session cookies. Both sides need to read an HTTP exchange without hesitation — which is exactly the fluency this module builds.

Lab 6

Use your browser's dev tools and curl. No special lab target needed for most of these, but stay within your own accounts and sites.

  1. Read a real exchange. Open your browser's developer tools (Network tab), load a website, click one request, and read the full request and response — method, path, status code, and headers on both sides. Find the Content-Type and any Set-Cookie.

  2. Make requests by hand. Use curl -v https://example.com to make a GET and inspect exactly what's sent and received (the -v shows headers). Then make a POST: curl -v -X POST -d 'a=1&b=2' https://httpbin.org/post and read how the body is sent and echoed back.

  3. Find and reason about a session cookie. In dev tools (Application/Storage → Cookies), find a session cookie on a site you're logged into. Explain, in writing, what would happen if someone copied that exact value into their own browser — and connect it to §6.7.

  4. Read a URL cold. Take a long URL with a query string and label every part (scheme, host, port, path, query params, fragment) from §6.6.

  5. Call a JSON API. curl https://api.github.com/users/torvalds (or any public JSON API) and read the response structure — objects, keys, arrays. This is the data you'll parse in Module 10.

  6. Watch status codes. Request a page that 404s, one that redirects (watch the 3xx and the Location header), and note a 200. Explain what each family means.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

  1. Describe the three-part shape of an HTTP request and of a response.
  2. Which HTTP methods are "safe" versus state-changing, and why does the distinction matter?
  3. What do the 2xx, 3xx, 4xx, and 5xx families mean? What's the difference between 401 and 403, and how does it map to Module 0's AuthN/AuthZ?
  4. HTTP is stateless — so how does a site remember you're logged in? Walk through cookies and sessions, and explain why stealing a session cookie is so powerful.
  5. Decompose a full URL into its parts.
  6. What exactly does the HTTPS padlock guarantee, and what does it not guarantee?
  7. What is the same-origin policy and why does it exist?
  8. What is a REST API and why will you be parsing JSON constantly?

And perform cold:

  • Use curl -v to make a GET and a POST and read the full headers and body of each.
  • Find a session cookie in your browser and explain the impact of it being stolen.

When all of that is effortless: Module 7 — Cryptography Fundamentals