What a Session Token Is

Login proves who you are once: password, passkey, SSO, MFA. The site then needs a cheaper proof for every click. That cheaper proof is the session token. Stateful apps often mint a long random identifier, store “this id maps to user 42 until Tuesday” in a database or cache, and send the id to the browser in a Set-Cookie header. Stateless apps may put claims in a signed bearer token (JWT is one named format) and trust the signature plus expiry. Either way, the next GET /inbox does not retype the password. The token rides along. If the token is guessable, leakable, or copy-pasteable, an allowed observer who holds it can look like you without cracking the password. Module 6 already said hashes beat stored passwords. This module says: after login, the live proof is the session string. Protect it like a short-lived password.

Where it rides matters. A cookie scoped to your site, marked HttpOnly and Secure, is the usual web design: the browser attaches it to later requests to that site, and page JavaScript should not be able to read it. An Authorization: Bearer header is common in APIs: your app stores the string and sends it on purpose. A token in a URL (https://shop.example/account?sid=…) is a volunteer: it lands in history, screenshots, server logs, and Referer headers. This course will not give you a recipe to harvest those URLs from other people. It will tell you never to put a live session id in a query string on a service you run. Local storage and sessionStorage are readable by JavaScript on that origin — useful for non-secret UI state, a poor vault for “this is me.” Write the locations in your notes. Do not collect other people’s locations from a café.

sudo apt install python3

brew install python3

python3 - << 'PY'
import secrets
tok = secrets.token_urlsafe(16)
print('standin_token_len', len(tok))
print('meaning: already-logged-in proof — not the password, still a secret')
print('ethics: never paste a real session from a stranger')
PY

The scary accurate sentence: many apps treat “holds a valid token” as “is that user” for the lifetime of the token. That is not magic. That is a lookup or a signature check. It is why logout must mean more than deleting a cookie in one browser: the server should forget or blacklist that id. It is why password change and “log out everywhere” should mint a new id and kill the old ones. It is why a screenshot of DevTools Application → Cookies from a shared PC is a credential leak. It is why pasting a Cookie header into a group chat is handing out a login. You do not need a hijack PoC to understand that. You need the model: secret string in, identity out, until the server says no.

Expiry is not optional decoration. A token that lives forever is a password you cannot rotate by logging out. Short time-to-live (TTL) plus refresh on a path you control is defender design. Idle timeout is the cousin: if nobody used the session, forget it. Absolute timeout is the other cousin: even an active session dies after a day so a stolen copy has a clock. None of those sentences is a bypass. They are why Lesson 3 will demand Max-Age / Expires you chose, and why Lesson 4 will make you document the TTL on a cookie YOU set. Guessable ids (incrementing integers, usernames, “admin”) fail the model because possession is too easy. Cryptographically random, long ids are the literacy fix. Do not write a session-guessing loop against a live shop. Do not brute a classmate’s cookie. Name the property. Use it on software you ship.

cat >> "$NOTES" << 'EOF'
possession_equals_identity: until expiry, logout, or server revoke
control_names: short TTL, rotate at login, revoke on logout
EOF

Cookie: the browser stores name=value for a host (and maybe Domain/Path). On later requests to that host, it may attach Cookie: … if flags allow. Set-Cookie is the server’s instruction. You will inspect YOUR Set-Cookie in Lesson 4. You will not intercept a café guest’s Cookie header. Bearer header: the client sends Authorization: Bearer <token> because your code put it there. If XSS can read where you stored it, XSS can send it — Lesson 2 names that path; HttpOnly cookies are the web mitigation for the cookie case; do not store bearer tokens in a place script on a shady page can read if you can avoid it. URL: treat query-string session ids as a finding on apps you own. Rotate them out. Do not harvest them off hotel Wi-Fi.

Shared computers and “remember me” are part of the same secret. A library PC with a still-valid session is a token on a disk you do not control. Log out. Do not leave DevTools open on an account that is not a throwaway. “Remember me” that sets a year-long cookie is a long-lived secret — sometimes wanted, always a revoke problem when the laptop is stolen. MFA at login does not erase a stolen session if the app never re-checks. Step-up (ask MFA again for a wire or a password change) is how serious apps shrink what a stolen token can do. Write that as defender language. Do not write a tool that replays tokens into a victim origin. Replaying someone else’s cookie in your browser is the hijack this course will not assign.

A session-token note is boring on purpose. Date (UTC). Definition in your own words: the “already logged in” string. Where it should live on a site you would ship (cookie with flags Lesson 3 will name, not a URL). Possession sentence: valid token ≈ identity until expiry or server revoke. Ethics: never steal cookies, never replay a classmate’s token, never café Wireshark, never XSS against a live site. Legal: original Cyberlium teaching mapped to the CEH v13 session-hijacking domain — not official EC-Council training, not a cert, not exam dumps. Path: $HOME/cyberlium-lab/session-token-notes.txt, chmod 600. Empty files fail. Files that contain other people’s cookie values fail even if you “only looked.” World-readable 777 on a shared PC fails.

A useful feeling: the lesson is “too small” because you did not become someone else. That feeling is how people graduate into unauthorized impersonation. The skill is stopping at the model. Lesson 2 will name leak paths without a payload. Lesson 4 will let you see Set-Cookie flags on 127.0.0.1 or on an app YOU own. Until then, a filled definition file is a complete Lesson 1. Do not add a stranger’s Cookie header because loopback felt later. Do not gist a production session id as “research.”

On a computer you own, create cyberlium-lab if needed. Fill the template in your own words. Do not add a captured cookie. Do not add a replay script. chmod 600. The block below writes the file and refuses to become a hijack kit — there is no cookie sniffer, no extra host, no XSS.

You now treat the “already logged in” string as a secret: a cookie or bearer proof, not a password, still enough for many apps to treat the holder as you until expiry or server-side revoke. Notes are locked in cyberlium-lab. This is original Cyberlium material covering the same domain as CEH v13 session hijacking — not official training, not a cert, not an exam dump. Next — How Sessions Get Stolen (Concepts) — names XSS, open Wi-Fi, and missing flags as leak paths. It will not give you a hijack proof-of-concept, a café capture, or an XSS payload against a live site.