How Sessions Get Stolen (Concepts)

Cross-site scripting (XSS) means an attacker’s JavaScript runs in the origin of a site the victim is using — usually because the app echoed untrusted HTML or a script URL into the page. If a session cookie is readable from JavaScript (no HttpOnly), that script can read document.cookie and send the value elsewhere. That sentence is enough. It is the whole XSS→session story this module needs. You already met XSS as a named web bug in other Cyberlium paths. Here it is only a leak path for the “already logged in” string. The cookie-side mitigation is HttpOnly so the browser will not hand the cookie to script. The app-side mitigation is not echoing raw user input as HTML — output encoding, a Content-Security-Policy you actually ship, frameworks that escape by default. None of that is a payload. Pasting <script>…</script> into a production search box you do not own is unauthorized testing. Pasting it into a classmate’s homework app without writing is the same line.

If you need to see XSS safely, you do it later on a page YOU wrote, in a private lab, with no network exfil and no one else’s cookies. This lesson does not assign that page. Do not “practice” on a live bank, a school portal, a bug bounty out of scope, or a random shop. Do not fetch a cookie-stealer from a cert-acronym blog. Bearer tokens in localStorage have the same XSS problem without an HttpOnly equivalent — script that runs on the origin can read storage. That is why serious SPAs still prefer HttpOnly cookies for the session when the browser is the client, or keep tokens in memory with a short life. Write the pairing: XSS named, HttpOnly named, live payload refused.

cat >> "$NOTES" << 'EOF'
xss_leak: script in the page can read document.cookie unless HttpOnly
fix_flag: HttpOnly
refuse: XSS payloads against others, BeEF
EOF

If the session cookie or Authorization header rides HTTP without TLS, an observer who is allowed to see that path can copy the secret the same way Module 8 copied YOUR GET on loopback. That is why Secure (cookie sent only on HTTPS) and site-wide HTTPS are the transport fixes, not a quieter sniffer. Open café Wi-Fi is the story students want because the radio feels public. The ethics line did not move: you do not capture other guests. “The café had no password” is not consent to their Cookie headers. “I needed to see a real session” is not consent. Your real session is one you caused on 127.0.0.1 or on an app you own, under HTTPS you control. Leftover http:// on a login or cookie path you ship is a finding. Hunting leftover HTTP in a hotel to steal strangers is a crime-shaped homework idea this course will fail.

Mixed content (HTTPS page loading HTTP subresources) can still leak. So can a token in a URL that then appears in a Referer to a third party. So can a proxy or “SSL inspection” you did not agree to on a device that is not yours — you do not MITM a roommate to “demonstrate sniffing.” Module 8 already refused fake CAs. This lesson only adds: the thing you were afraid of sniffing is often the session secret. Encryption of the application data is still the fix. A VPN may hide inner destinations from the café clerk; it does not replace HTTPS to the site; it does not authorize sniffing other people. Write two columns: leak (cleartext session) versus fix (HTTPS + Secure). Do not fill the leak column with a pcap of the floor.

SameSite is not HTTPS and not HttpOnly. It is a rule about when the browser attaches the cookie to cross-site requests (a click from another origin, an embedded form). Lax/Strict shrink a class of cross-site request forgery that rides a cookie the browser already has. SameSite=None requires Secure. Missing SameSite on an old browser default is a named gap, not a CSRF exploit kit against a live bank. Short TTL and idle timeout shrink the window if a value is copied. Predictable ids shrink the work to guess. Session fixation: the attacker wants the victim to log in without the server minting a fresh id, so a known pre-login id becomes an authenticated id. The fix is rotate the session id at login — a server change, not a homework attack on a classmate. Physical access: unlocked laptop, “remember me,” a shared family browser. Log out. Lock the screen. Revoke on password change.

None of these paths needs a proof-of-concept against a stranger to be teachable. If a blog titled with a cert acronym publishes cookie-replay steps, BeEF hooks, or Wireshark filters for Cookie:, that blog is not this course. Skill does not create consent. A public login form is still someone else’s session factory. If you cannot say the token is one you minted on a host you own, you do not touch it. Lesson 4 will mint cookies on 127.0.0.1 or read flags on an app you own. That is the only jar you open.

Date (UTC). XSS → HttpOnly plus output encoding (no live payload). Cleartext / open Wi-Fi story → HTTPS plus Secure (no café capture). Missing SameSite → Lax/Strict (and None only with Secure). Fixation → rotate id at login. Shared browser → logout and revoke. Ethics: never steal cookies, never XSS a live site, never Wireshark café, never replay a token. 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/session-stolen-concepts-notes.txt, chmod 600. Empty files fail. Files that include a payload, a webhook, or someone else’s cookie value fail even if you “did not send it.”

A useful feeling: “I did not pop an account so I did not learn.” That feeling is the leak into unauthorized impersonation. The skill is naming the path and the control. Next lesson writes the flags as a shipping checklist. The lab after that is DevTools or curl on a Set-Cookie YOU sent. Do not add a second origin because localhost felt too kind. Do not paste XSS into a production comment field as “just looking.”

On a computer you own, create cyberlium-lab if needed. Fill the template in your own words. Do not add an XSS string aimed at a hostname you do not own. Do not add a pcap. chmod 600. The block writes notes and a literacy print — it never opens a socket to a shop and never prints a steal script.

cat >> "$NOTES" << 'EOF'
fixation: accept a token the attacker already knows — rotate at login
shared_glass: a borrowed logged-in browser IS the session
refuse: hijack cookbooks
EOF

You now name how session secrets leak — XSS without HttpOnly, cleartext on a path you should have encrypted, flags never set, ids that survive login, glass you left unlocked — without running a hijack kit. 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 — Cookie Flags and Logout Hygiene — writes Secure, HttpOnly, SameSite, short TTL, and revoke-on-password-change as the shipping list, still without a steal.