Cybersecurity

User Tools

Site Tools

Trace: • 03_how_internet_works
bbc:03_how_internet_works

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

bbc:03_how_internet_works [2026/05/14 10:05] – bbc article from bug bounty bootcamp drewbbc:03_how_internet_works [2026/05/14 10:11] (current) – bbc article -- updated with full content drew
Line 5: Line 5:
 ===== Client-Server Model ===== ===== Client-Server Model =====
  
-Web apps operate on a **client-server** model: +Web apps operate on a client-server model. The client (browser) sends HTTP requests; the server processes them and returns responses.
-  * **Client** (browser) sends HTTP requests +
-  * **Server** processes requests and returns HTTP responses +
-  * Everything in between (DNS, CDNs, load balancers, proxies) is part of the network path+
  
-===== DNS =====+===== DNS Record Types =====
  
-  * DNS maps domain names to IP addresses +| Record | Purpose | Attack Relevance | 
-  * **A record** -- domain to IPv4 +|---|---|---| 
-  * **AAAA record** -- domain to IPv6 +| A | domain -> IPv4 | - | 
-  * **CNAME** -- alias to another domain (important for subdomain takeover) +| AAAA | domain -> IPv6 | - | 
-  * **MX** -- mail server +| CNAME | alias to another domain | subdomain takeover | 
-  * **TXT** -- arbitrary text (SPF, DMARC, verification tokens) +| MX | mail server | - | 
-  * **NS** -- name server records (dangling NS = takeover vector)+| TXT | arbitrary text (SPF, DMARC) | verification bypass | 
 +| NS | name server | dangling NS = takeover |
  
-===== HTTP Basics =====+===== HTTP =====
  
-**Request structure:**+**Request:**
 <code> <code>
 METHOD /path HTTP/1.1 METHOD /path HTTP/1.1
 Host: example.com Host: example.com
-Header-Name: value+Cookie: session=abc123
  
-[optional body]+[body for POST/PUT]
 </code> </code>
  
-**Common methods:** +**Common methods:** GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD
-  * GET -- retrieve resource +
-  * POST -- submit data +
-  * PUT -- replace resource +
-  * PATCH -- partial update +
-  * DELETE -- remove resource +
-  * OPTIONS -- list allowed methods +
-  * HEAD -- like GET but no body+
  
-**Response structure:** +**Status codes:**
-<code> +
-HTTP/1.1 200 OK +
-Content-Type: text/html +
-Set-Cookie: session=abc123 +
- +
-[body] +
-</code> +
- +
-===== Status Codes =====+
  
 | Code | Meaning | | Code | Meaning |
 |---|---| |---|---|
 | 200 | OK | | 200 | OK |
-| 301/302 | Redirect (permanent/temporary) | +| 301/302 | Redirect | 
-| 400 | Bad request | +| 401 | Need auth | 
-| 401 | Unauthorized (need auth) | +| 403 | Auth present but no permission |
-| 403 | Forbidden (have auth, no permission) |+
 | 404 | Not found | | 404 | Not found |
 | 500 | Server error | | 500 | Server error |
  
-===== Ports =====+===== Cookies =====
  
-  * HTTP: 80 +Cookies are key-value pairs sent automatically with each request to the matching domain. Security attributes:
-  * HTTPS: 443 +
-  * SSH: 22 +
-  * FTP: 21 +
-  * Common non-standard: 8080, 8443, 3000, 8888+
  
-Always scan for open ports during recon -- admin panels and dev services often run on alternate ports.+  * **HttpOnly** -- JS cannot read this cookie; prevents XSS session theft 
 +  * **Secure** -- only sent over HTTPS 
 +  * **SameSite** (Strict/Lax/None) -- controls cross-site sending 
 +  * **Domain / Path** -- scope
  
-===== Content Encoding =====+Missing HttpOnly or Secure on session cookie = reportable finding.
  
-Servers declare content type with **Content-Type** header. Common types: +===== Session vs Token Auth =====
-  * `text/html` -- HTML pages +
-  * `application/json` -- API responses +
-  * `application/x-www-form-urlencoded` -- form submissions +
-  * `multipart/form-data` -- file uploads +
-  * `application/xml` -- XML data+
  
-===== Cookies =====+  * **Session-based:** server stores session state server-side, issues a session ID in a cookie 
 +  * **Token-based:** identity info is embedded in the token itself; server verifies the signature on each request (no session store)
  
-Cookies are key-value pairs stored in the browser and sent automatically with every request to the matching domain.+===== JSON Web Tokens (JWT) =====
  
-Security attributes: +Three base64url-encoded parts separated by dots: `header.payload.signature`
-  * **HttpOnly** -- JS cannot read the cookie (prevents XSS cookie theft) +
-  * **Secure** -- only sent over HTTPS +
-  * **SameSite** -- controls cross-site sending (Strict/Lax/None) +
-  * **Domain** -- which domain receives the cookie +
-  * **Path** -- which path receives the cookie+
  
-Missing HttpOnly or Secure flags = findings worth reporting.+  * **Header:** `{"alg":"HS256","typ":"JWT"}` 
 +  * **Payload:** `{"user_name":"admin"}` 
 +  * **Signature:** HMAC or RSA of header.payload using the secret key
  
-===== Security Controls =====+**Attack vectors:**
  
-  * **Same-Origin Policy (SOP)** -- browser blocks cross-origin reads of responses +=== alg:none ===
-  * **CORS** -- server opts certain origins into cross-origin access via headers +
-  * **HTTPS/TLS** -- encrypts traffic in transit +
-  * **Content Security Policy (CSP)** -- restricts which scripts/resources can load +
-  * **HSTS** -- forces HTTPS for a domain for a specified duration+
  
-===== Sessions =====+Set `"alg":"none"` in the header. If the server doesn't validate signatures, an empty signature is accepted. Any token with an arbitrary payload becomes valid.
  
-HTTP is stateless. Sessions layer stateful identity on top: +<code> 
-  * Server issues a **session token** after login +{"alg":"none","typ":"JWT"} . {"user":"admin"} . [empty] 
-  * Token stored in cookie or localStorage +</code>
-  * Sent with each request to identify the user +
-  * Server-side: token maps to a user record+
  
-Attack surface: weak tokens, token fixation, token leakage in logs/referrers, insecure storage.+=== HMAC-RSA Confusion === 
 + 
 +If the app signs with RSA (private key) but an attacker changes `alg` to HMAC, the server may verify using the RSA public key -- which is public. The attacker can sign forged tokens with the public key. 
 + 
 +=== Brute-Force the Key === 
 + 
 +If the HMAC key is weak, brute-force offline with hashcat or jwt_tool using the known header, payload, and signature. 
 + 
 +=== Reading the Payload === 
 + 
 +JWTs are base64url-encoded, not encrypted. Decode the payload with `base64 -d` or jwt.io to check for sensitive data (PII, privilege flags, internal IDs). 
 + 
 +===== Same-Origin Policy (SOP) ===== 
 + 
 +Scripts can only read responses from the same origin (protocol + hostname + port). 
 + 
 +Relative to `https://medium.com/@user`: 
 +  * `https://medium.com/` -- same origin (path doesn't matter) 
 +  * `http://medium.com/` -- different (protocol) 
 +  * `https://twitter.com/@user` -- different (hostname) 
 +  * `https://medium.com:8080/@user` -- different (port) 
 + 
 +SOP prevents a malicious script on attacker.com from reading your bank's response even if your browser includes your session cookie automatically. CORS is the mechanism by which servers loosen this restriction for trusted origins. 
 + 
 +===== Security Controls Summary ===== 
 + 
 +| Control | What it does | 
 +|---|---| 
 +| SOP | Browser blocks cross-origin reads | 
 +| CORS | Server opts origins into cross-origin access | 
 +| HTTPS/TLS | Encrypts traffic in transit | 
 +| CSP | Restricts which scripts/resources can load | 
 +| HSTS | Forces HTTPS for domain for a set duration |
  
bbc/03_how_internet_works.txt · Last modified: by drew
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki