EXERCISE 1 — Inspecting SameSite and predicting cookie behaviour ================================================================ INSPECTING IN DEVTOOLS: - Open DevTools -> Application tab -> Storage -> Cookies -> pick a site. - The columns show Name, Value, Domain, Path, Expires, HttpOnly, Secure, and SameSite. You'll typically see "Lax" on modern session cookies (often blank-shown-as-Lax due to the 2020 default), "Strict" on some, and "None" on third-party / embed cookies (always paired with Secure). FOR A SameSite=Lax SESSION COOKIE, WHICH REQUESTS CARRY IT: (a) Clicking a link from another site (top-level GET navigation). CARRIES THE COOKIE: YES. Lax permits the cookie on top-level navigations that use a safe method (GET) -- i.e. the user clicking a link that changes the address bar to your site. This is exactly the UX Lax preserves: arriving via an external link, you're still logged in. (b) Cross-site auto-submitting POST form (Chapter 3's classic attack). CARRIES THE COOKIE: NO. Lax does NOT send the cookie on cross-site POSTs (it's not a safe-method top-level GET). The forged POST arrives with no session cookie -> the server sees a logged-out request -> the classic CSRF is blocked. This is the single most important effect of Lax. (c) Cross-site GET (subresource request). CARRIES THE COOKIE: NO. Although it's a GET, an load is a SUBRESOURCE request, not a TOP-LEVEL navigation. Lax only sends on top-level navigations, so a background/embedded cross-site GET does NOT get the cookie. (This is why a forged to a state-changing GET is blocked by Lax -- though you must STILL not change state on GET, because a top-level GET navigation window.location/link WOULD carry it. See Exercise 3.) SUMMARY (SameSite=Lax): link click (top-level GET) .... cookie SENT cross-site POST form .......... cookie NOT sent (classic CSRF blocked) cross-site GET .......... cookie NOT sent (subresource) top-level GET navigation to a state-changing GET endpoint .. cookie SENT (the residual GET gap)