EXERCISE 3 — Real defence in depth vs fake defence in depth
============================================================

THE PROPOSAL:
  "Defence in depth" = session cookie + a second auth cookie + a CSRF cookie,
  all checked server-side.

WHY THIS IS NOT REAL DEFENCE IN DEPTH:
  - All three are COOKIES, and cookies share ONE failure mode: the browser
    sends them AUTOMATICALLY on requests to the domain, including forged
    cross-site ones (ambient authority). They all rest on the SAME
    assumption ("a value carried in a cookie proves legitimacy").
  - So a single weakness defeats all three at once:
       * A forged cross-site request carries ALL THREE cookies automatically
         -> if the server just checks they're present/match, it passes.
       * Cookie injection from a subdomain (Chapter 6) can plant values in
         any of them.
  - Stacking three things that fail for the SAME reason adds NO depth -- it's
    one layer wearing three hats. Real depth requires INDEPENDENT assumptions,
    so that defeating one doesn't defeat the rest.

A GENUINELY INDEPENDENT 3-LAYER STACK:

  Layer A -- SameSite=Lax (or Strict) on the session cookie.
     Distinct assumption: the BROWSER'S cross-site cookie-sending rules.
     Fails only if: browser ignores SameSite / same-site sibling / state-
     changing GET. (Browser-level.)

  Layer B -- Anti-CSRF token (synchronizer or signed double-submit) in a
             body field or custom HEADER, validated server-side.
     Distinct assumption: the attacker CANNOT READ your page/token
     cross-site (Same-Origin Policy) and cannot set a custom header without a
     blocked preflight.
     Fails only if: XSS, or token misimplementation. (Request-content level.)

  Layer C -- Re-authentication / MFA on sensitive actions.
     Distinct assumption: the attacker does NOT KNOW a user secret (current
     password / live OTP) and can't obtain it via CSRF (write-only).
     Fails only if: the user's secret is separately compromised. (User-secret
     level.)

WHY THIS IS REAL DEPTH:
  - Each layer rests on a DIFFERENT assumption (browser rules / page-read
    barrier / user secret). An attacker must break all three by different
    means simultaneously. A failure in one (e.g. a misconfigured SameSite)
    is caught by the others.
  - Optional 4th independent layer: Origin/Referer allowlist check
    (assumption: browser-set, unforgeable Origin header on cross-site
    requests).

THE CEILING (state it):
  - None of these survives XSS: same-origin injected script can read tokens,
    set headers, and act with the cookie -- defeating A, B, and even
    re-using a live session for C in some flows. So XSS PREVENTION (output
    encoding, CSP, HttpOnly session cookie) sits BENEATH the whole stack as
    the foundation.

ONE-LINE TEST:
  When adding a layer, ask "does this fail for a DIFFERENT reason than the
  others?" If yes, it adds depth; if no (e.g. another cookie), it doesn't.