How the Web Works

The Chain of Events: Typing a URL #

When you type https://example.com/login and press Enter, the system executes a precise multi-layer sequence. Understanding this at a technical depth is non-negotiable — every attack class maps directly to one or more steps in this chain.

1. Browser Cache Check: Before any network activity, the browser checks its local cache. If a valid cached resource exists (and hasn't expired per cache-control headers), it is used directly. This step is relevant because cache-poisoning attacks manipulate what gets stored and served here.
What is Browser Cache?
The cache is a local storage closet where your browser saves static website files—like images, logos, HTML files, CSS stylesheets, and JavaScript files. When you visit a website for the first time, your browser has to download every single image and script. That takes time. The next time you visit, the browser thinks, "Hey, I already have that heavy logo saved in my cache," and loads it instantly from your hard drive instead of downloading it over the internet again.Why it matters for Security: As your notes mention, a Cache Poisoning attack happens when an attacker forces the server to send a malicious response, which then gets saved in this "storage closet." Every time a normal user visits the site, their browser grabs the malicious cached file, thinking it’s legitimate.
2. DNS Resolution: The browser queries the Domain Name System to convert example.com into a routable IP address (e.g., 93.184.216.34). See the DNS deep-dive below.
3. TCP Three-Way Handshake: Client sends SYN → server responds SYN-ACK → client completes with ACK. This establishes a reliable transport channel on port 443.
4. TLS Cryptographic Handshake: Both parties negotiate cipher suites, exchange certificates, and derive session keys. All subsequent data is encrypted in transit.
5. HTTP Request Transmission: The browser structures a formatted HTTP payload and dispatches it over the encrypted socket.
🏗️ 1. Structuring the Format (The HTTP Payload)
Before sending anything, the browser has to write a "letter" that the web server will understand. This letter follows a strict format dictated by the HTTP protocol.
A standard HTTP request payload is broken down into three main sections:
A. The Request Line
This is the very first line of the letter. It tells the server what the browser wants to do and where. It contains three things:
The Method: The action (e.g., GET to fetch data, POST to submit data, DELETE to remove data).
The Path: The specific page or resource being requested (e.g., /index.html or /api/login).
The Version: The protocol version being used (usually HTTP/1.1 or HTTP/2).
B. The Headers
These are key-value pairs that provide metadata about the request. They give the server crucial context. Common headers include:
Host: example.com (Tells a server hosting multiple sites which one you want).
User-Agent: Mozilla/5.0... (Tells the server what browser and OS you are using).
Cookie: session_id=xyz123 (As we discussed, this proves to the server who you are).
Accept-Language: en-US (Tells the server you prefer English).
C. The Body (Optional)
This is the actual data being sent to the server. For a simple GET request (like loading a homepage), the body is completely empty. But if you are filling out a login form, a POST request will put your username and password inside this body.




HTTP
GET /profile HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Cookie: session_id=xyz123
Accept: text/html




[Body is empty because this is a GET request]
📨 2. Dispatches it over the Encrypted Socket Once the browser finishes formatting this plain-text "letter," it doesn't just throw it into the open internet. If it did, anyone sitting on your local Wi-Fi network could read your cookies or passwords. Instead, it hands the payload down to the Encrypted Socket (the TLS layer running on Port 443). Encryption: The TLS software takes the plain-text HTTP layout and scrambles it using the cryptographic keys established right after the TCP handshake. The plain text turns into unreadable garbage data (ciphertext). Segmentation: The encrypted data is chopped up into smaller, manageable chunks called packets. Dispatch: These encrypted packets are handed down to the network hardware and fired across the internet toward the target server. When the server receives these packets, it uses its matching cryptographic key to decrypt the data back into the clean HTTP format, reads the headers, and figures out how to respond.


🎯 Bug Bounty Relevance: Attack Possibilities As a security researcher, manipulating the "HTTP Payload" before it gets dispatched is your bread and butter. This is where tools like Burp Suite come into play. Burp acts as a proxy, intercepting the payload after the browser structures it, but before it gets encrypted and dispatched. By tampering with this payload, you can test for major vulnerabilities: Insecure Direct Object References (IDOR): You change a header or path parameter like /api/user?id=1001 to id=1002 to see if you can view another user's private data. SQL Injection (SQLi) / Cross-Site Scripting (XSS): You inject malicious payloads into the HTTP request Body or input fields to see if the server processes them unsafely. Header Injection: You inject malicious values into headers (like X-Forwarded-For or Host) to trick the server's backend routing logic.
6. Application Processing: The server application (Node.js, Django, Laravel, etc.) parses the request, executes business logic, queries databases, and formulates a response.
7. HTTP Response: The server returns status code, headers, and the response body.
8. DOM Rendering: The browser parses HTML → builds DOM, parses CSS → builds CSSOM, executes JavaScript → may trigger more HTTP requests (sub-resources, APIs).

DNS Resolution — Deep Dive #

DNS is the internet's phone book. It resolves human-readable domain names to machine-routable IP addresses. Understanding this process reveals multiple attack surfaces: DNS Hijacking, Subdomain Takeover, DNS Cache Poisoning.

Key DNS Record Types

TCP Handshake & TLS Encryption #

Before any HTTP data is exchanged, the transport layer must be established. For HTTPS, this is a two-part process: TCP establishes the connection, TLS secures it.

TCP Three-Way Handshake

TCP Handshake DiagramClient                        Server
  |                              |
  |──── SYN (seq=x) ────────────>|   "I want to connect"
  |                              |
  |<─── SYN-ACK (seq=y,ack=x+1)─|   "Acknowledged, here's my seq"
  |                              |
  |──── ACK (ack=y+1) ──────────>|   "Connected."
  |                              |
  |    [Connection Established]  |

TLS 1.3 Handshake (Modern Standard)

HTTP vs HTTPS #

Common Ports Reference #

Ports are logical endpoints on a host. A server can run multiple services on one IP by using different ports. During recon, an open port is a potential attack surface. Know these by heart.

Deconstructing the HTTP Request #

Every outbound request intercepted inside a proxy follows this precise architectural template. You need to be able to read and modify every line fluently.

Raw HTTP Request — AnnotatedPOST /api/v1/login HTTP/1.1                  ← [1] Method + Path + Version
Host: app.example.com                        ← [2] Target virtual host
User-Agent: Mozilla/5.0 (Windows NT 10.0)   ← [3] Client identification
Accept: application/json                     ← [4] Expected response format
Content-Type: application/json               ← [5] Body format declaration
Content-Length: 47                           ← [6] Body size in bytes
Authorization: Bearer eyJhbGc...            ← [7] Auth token (JWT here)
Cookie: session=abc123; csrftoken=xyz        ← [8] State / CSRF tokens
X-Forwarded-For: 127.0.0.1                  ← [9] Custom header (often trusted blindly)
Connection: keep-alive                       ← [10] Persistent connection
                                             ← [11] Blank line separates headers/body
{"username":"admin","password":"secret"}     ← [12] Request body (POST data)

Request Header Deep Reference

HTTP Methods & Attack Vectors #

Methods declare what action is being requested on a target resource. Servers frequently misconfigure access control validation on non-standard methods.

Deconstructing the HTTP Response #

The server's answer carries both metadata (headers) and content (body). The headers are often more interesting than the body from a security perspective.

Raw HTTP Response — AnnotatedHTTP/1.1 200 OK                                        ← [1] Version + Status
Date: Mon, 01 Jan 2025 12:00:00 GMT                    ← [2] Server timestamp
Server: nginx/1.18.0                                   ← [3] ⚠ Version disclosure
Content-Type: application/json; charset=UTF-8          ← [4] Body content type
Content-Length: 312                                    ← [5] Body size
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Strict   ← [6] Cookie flags
X-Content-Type-Options: nosniff                        ← [7] MIME sniff protection
X-Frame-Options: DENY                                  ← [8] Clickjacking protection
Content-Security-Policy: default-src 'self'            ← [9] XSS mitigation header
Strict-Transport-Security: max-age=31536000            ← [10] HSTS — forces HTTPS
Access-Control-Allow-Origin: https://trusted.com       ← [11] CORS policy
X-Powered-By: PHP/7.4.3                                ← [12] ⚠ Tech stack leak

{"status":"ok","user":{"id":42,"role":"user"}}         ← [13] Response body

Security Headers — Present vs Missing

Critical Status Codes Matrix #

Anatomy of a URL Target #

Every URL component is a potential attack surface. Understanding each part is foundational for injection testing, path traversal, and parameter manipulation.

HTTP Versions — What Changed #

Protocol version matters. Different versions have different performance characteristics and, critically, different security behaviours and attack surfaces.

How the Browser Renders a Page #

Understanding the render pipeline is critical for DOM-based XSS, CSP bypass, and understanding where JavaScript execution contexts exist.

1. Parse HTML → Build DOM: Browser parses HTML top-to-bottom, constructing the Document Object Model tree. A <script> tag with no defer or async blocks parsing and executes immediately.
2. Parse CSS → Build CSSOM: CSS rules are applied to DOM nodes. This is where CSS injection attacks live (stealing data via attribute selectors).
3. Execute JavaScript: JS can modify the DOM, read cookies (if not HttpOnly), make fetch requests to APIs, and redirect the page. This is the primary XSS execution environment.
4. Sub-resource Requests: Images, scripts, stylesheets, fonts, API calls all trigger new HTTP requests. Each is a potential attack surface (CSP bypass via script-src, SRI bypass).
5. Render Tree + Paint: Final visual output. CSS injection can overlay UI elements for phishing/clickjacking.

DOM-Based XSS — Conceptual Example// Vulnerable JavaScript:
const name = location.hash.slice(1);    // reads URL fragment
document.getElementById('msg').innerHTML = name;  // ← sinks into innerHTML

// Attacker sends:
https://example.com/page#<img src=x onerror=alert(document.cookie)>

// Result: JavaScript executes in victim's browser context
// No server interaction required — purely client-side

Same-Origin Policy & CORS #

The Same-Origin Policy (SOP) is the browser's primary isolation mechanism. Understanding it is foundational for XSS, CSRF, and CORS vulnerability classes.

SOP restricts JavaScript from reading responses from cross-origin requests. CORS (Cross-Origin Resource Sharing) is the mechanism that selectively relaxes SOP. Misconfigured CORS is a high-severity finding — it allows attacker-controlled origins to read authenticated responses. This is covered in depth in Chapter 4.

Chapter 1 — Operational Drills #

Complete all five verification drills before advancing to Chapter 2. Each builds foundational muscle memory for proxy interception work.