CSRF Tokens

## The four steps in PHP A CSRF (cross-site request forgery) token is a secret the server plants in its own pages and requires back on any state-changing request. For a change-email form on a bank portal: 1. **Generate** — a per-session unpredictable value from the CSPRNG: ```php if (empty($_SESSION['csrf'])) { $_SESSION['csrf'] = bin2hex(random_bytes(32)); // 64 hex chars } ``` 2. **Store** — it is already stored: `$_SESSION` is server-side, so the browser never sees the raw session contents, only the session *cookie*. 3. **Emit** — render it into the form the user legitimately loads: ```php echo '<input type="hidden" name="csrf" value="' . htmlspecialchars($_SESSION['csrf'], ENT_QUOTES) . '">'; ``` 4. **Verify** — on the POST that changes the email, before any side effect: ```php if (!hash_equals($_SESSION['csrf'] ?? '', $_POST['csrf'] ?? '')) { http_response_code(400); exit; } ``` ## Why this stops the forgery A change-email endpoint that trusts only the session cookie is forgeable: a hostile page can make the victim's browser POST to it, and the browser attaches the bank's session cookie automatically. The token breaks that because: - it is **stored in the server-side session** and only **echoed into pages the bank itself renders**; - the same-origin policy stops the attacker's page from **reading** the bank's pages, so it cannot learn the token; - the forged POST therefore arrives **without the matching `csrf` field**, and step 4 rejects it. The attacker can replay the cookie but not the token — that asymmetry is the whole point. ## The pieces that are easy to get wrong | Mistake | Consequence | |---|---| | Comparing with `==` or `===` | timing side channel, and `==` can be bypassed by type juggling | | Checking the token *after* updating the email | the side effect already happened | | Storing the token in a hidden field only (no session copy) | nothing server-side to compare against — the attacker supplies both halves | | Putting the token in a GET query string | it leaks via `Referer`, logs, and history | | Forgetting `?? ''` on a missing field | a warning or a type error instead of a clean rejection | ## What belongs to PHP here, and what does not The PHP-specific content is: store in `$_SESSION`, emit in a hidden field, read from `$_POST`, and compare with `hash_equals`. The *concepts* — why the browser sends the cookie, what a synchronizer token proves, how SameSite and Origin checks compare — are owned by the CSRF protocol topics; the CSPRNG behind `random_bytes` is owned by the password/random leaf. An interview answer here is judged on wiring the four steps correctly and using `hash_equals`, not on re-deriving the attack.