Ch 3: How the Internet Works

Source: Bug Bounty Bootcamp by Vickie Li (No Starch Press, 2021)

Web apps operate on a client-server model. The client (browser) sends HTTP requests; the server processes them and returns responses.

Request:

METHOD /path HTTP/1.1
Host: example.com
Cookie: session=abc123

[body for POST/PUT]

Common methods: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD

Status codes:

Cookies are key-value pairs sent automatically with each request to the matching domain. Security attributes:

• 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

Missing HttpOnly or Secure on session cookie = reportable finding.

• 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)

Three base64url-encoded parts separated by dots: `header.payload.signature`

• Header: `{“alg”:“HS256”,“typ”:“JWT”}`
• Payload: `{“user_name”:“admin”}`
• Signature: HMAC or RSA of header.payload using the secret key

Attack vectors:

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.

{"alg":"none","typ":"JWT"} . {"user":"admin"} . [empty]

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.

If the HMAC key is weak, brute-force offline with hashcat or jwt_tool using the known header, payload, and signature.

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).

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.