Cookie Flags and Logout Hygiene

The Secure attribute tells the browser: attach this cookie only on HTTPS (and other secure contexts the browser defines). Combined with site-wide TLS, it is the Module 8 fix applied to the session jar. If you set a session cookie on http:// in production, you volunteered the secret to any allowed observer on that path. HSTS (HTTP Strict Transport Security) is the extra policy that keeps users from slipping back to http:// after the first HTTPS visit — name it as a cousin, do not treat it as a hijack lab. Localhost HTTP in Lesson 4 is a teaching exception: you will still send a Set-Cookie line that includes Secure so you can read the flag in curl even when a browser may refuse to persist a Secure cookie on plain HTTP. Document the header you sent. Do not “fix” the demo by capturing a café HTTPS session instead.

Secure is not HttpOnly. A Secure cookie can still be readable by JavaScript if you forgot HttpOnly. Secure is not SameSite. A Secure cookie can still be attached to some cross-site requests depending on SameSite. Students who collapse all three flags into “the padlock” fail the checklist. Write three sentences. Ship three attributes. Prefer cookies on the host you mean (avoid overly broad Domain=). Prefer Path=/ only if every path on that host should see the session — tighter paths for CSRF-sensitive cookies if your app design needs that. None of those is a steal. They are how you stop volunteering.

HttpOnly tells the browser: do not expose this cookie to document.cookie or other script APIs. Session cookies should almost always be HttpOnly. If your front end “needs to read the session id,” that is usually a design smell — put non-secret UI state elsewhere. XSS becomes a page-defacement and data-theft problem instead of an instant session export. That is not a promise that XSS is harmless. It is why Lesson 2 paired XSS with HttpOnly. You still encode output. You still do not fire XSS at a live site to “confirm HttpOnly.” Confirmation is: you set HttpOnly on a cookie you control and you inspect the flag (Lesson 4).

SameSite=Strict — cookie stays on same-site navigations you initiated in the tightest common reading; cross-site requests do not get it. SameSite=Lax — top-level GET navigations from another site may still send it (the typical “click a link to the shop” case); many CSRF-style POSTs from other origins will not. SameSite=None — cookie may be sent in cross-site contexts and must be Secure. Default browser behavior has shifted over years; do not rely on “I omitted the attribute.” Set it. SameSite is not a CSRF silver bullet by itself (methods, tokens, Fetch metadata still matter on apps you ship). This course will not give you a CSRF PoC against a live target. Write Lax or Strict for session cookies unless you have a documented cross-site embed you own that needs None+Secure.

Max-Age (seconds) or Expires sets the browser clock. Session cookies with no expiry die when the browser session ends — still copyable until then, still needing server revoke. Prefer a short absolute lifetime plus a refresh path you control over a year-long “remember me” unless the product truly needs it and you accept the stolen-laptop window. Idle timeout is server policy: no requests for N minutes, drop the id even if the cookie is still in the jar. Rotate the session id when the user authenticates (fixation control from Lesson 2) and when privilege changes (password change, MFA step-up, role change). “Log out” must hit the server: delete or blacklist the id, then clear the cookie. “Log out everywhere” walks all ids for that user. Password change should revoke other sessions so a copied cookie dies.

Bearer tokens need the cousin list: short access TTL, rotating refresh tokens stored with care, revoke on password change, no refresh token in a URL, no logging the secret. MFA at login does not replace this list. A stolen session still skips the password until you kill it. Step-up auth for money movement shrinks what a stolen token can do. Write owners: who on your labeled app sets Set-Cookie, who owns logout, who owns the revoke table. Empty “we use JWT” with no expiry and no revoke is not hygiene. A blog that says “just disable SameSite to make the demo work against a third-party shop” is not this course.

Date (UTC). Labeled app you own or a hypothetical you would own — never a classmate shop, never a café. For the session cookie: Secure, HttpOnly, SameSite value, Max-Age you chose, Path/Domain you chose. Logout: server revoke plus clear cookie. Password change: revoke other ids. Rotate at login: yes. HTTPS everywhere on that app: yes. Ethics: never steal cookies, never strip flags on a live site you do not own, never café intercept. Legal: original Cyberlium teaching mapped to the CEH v13 session-hijacking domain — not official EC-Council training, not a cert, not exam dumps. File: $HOME/cyberlium-lab/cookie-flags-notes.txt, chmod 600. Next lab will prove you can see those flags on a Set-Cookie you sent.

A useful feeling: “I should log into a bank and screenshot Application → Cookies.” That is someone else’s jar. If you do not own the app, you do not use their production cookies as homework. Your own staging app, or the loopback page in Lesson 4, is the jar. World-readable notes that contain a live session value fail even if the flags were perfect.

On a computer you own, create cyberlium-lab if needed. Fill the template for a labeled app you own or would own. chmod 600. The block writes a sample Set-Cookie as literacy — it does not contact a shop and does not steal a cookie.

cat >> "$NOTES" << 'EOF'
HttpOnly: JavaScript cannot read the cookie
SameSite: cookie not attached on many cross-site requests (Lax/Strict)
refuse: CSRF PoC against others
EOF

You now have a shipping list: Secure with HTTPS, HttpOnly against script, SameSite against casual cross-site attach, a short TTL, rotate at login, revoke on logout and password change. Notes are locked in cyberlium-lab. This is original Cyberlium teaching mapped to the CEH v13 session-hijacking domain — not official EC-Council training, not a cert, not exam dumps. Next — Lab — Inspect Cookie Flags on a Site You Own — DevTools or curl on a cookie YOU set on 127.0.0.1 or on an app you own. Never intercept café users. Never steal others’ cookies.