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)