Cybersecurity

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Ch 3: How the Internet Works ======

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

===== Client-Server Model =====

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

===== DNS Record Types =====

| Record | Purpose | Attack Relevance |
|---|---|---|
| A | domain -> IPv4 | - |
| AAAA | domain -> IPv6 | - |
| CNAME | alias to another domain | subdomain takeover |
| MX | mail server | - |
| TXT | arbitrary text (SPF, DMARC) | verification bypass |
| NS | name server | dangling NS = takeover |

===== HTTP =====

**Request:**
<code>
METHOD /path HTTP/1.1
Host: example.com
Cookie: session=abc123

[body for POST/PUT]
</code>

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

**Status codes:**

| Code | Meaning |
|---|---|
| 200 | OK |
| 301/302 | Redirect |
| 401 | Need auth |
| 403 | Auth present but no permission |
| 404 | Not found |
| 500 | Server error |

===== Cookies =====

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 vs Token Auth =====

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

===== JSON Web Tokens (JWT) =====

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:**

=== alg:none ===

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.

<code>
{"alg":"none","typ":"JWT"} . {"user":"admin"} . [empty]
</code>

=== 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 |