Sessions

TL;DR

A session attack is any path from “anonymous attacker outside the application” to “logged-in user inside it” that doesn’t require knowing the victim’s password. The session identifier (a cookie, almost always) is the only thing the server checks for every request after login - so anything that puts a valid identifier in the attacker’s hands grants the victim’s identity.

# 1. Identify the session identifier
#    Browser DevTools → Storage → Cookies; look for HttpOnly, Secure, SameSite flags

# 2. Harvest it via one of:
#    - Sniffing plaintext HTTP            (network position required)
#    - XSS that exfiltrates document.cookie (HttpOnly absent)
#    - Open redirect that leaks tokens in URL parameters
#    - Post-exploit retrieval from /var/lib/php/sessions or the DB

# 3. Ride it
#    Browser: open private window, paste cookie, navigate, you are logged in
#    curl:    curl -b 'session=ABC...' http://target/account
#    Burp:    swap cookie in Repeater/Intercept

# 4. Chain when sessions are well-defended
#    XSS → bypasses SameSite (request originates from the target's own origin)
#    Open redirect → leaks tokens included in redirect URLs
#    CSRF token theft via HTML injection → bypasses anti-CSRF on POST

Success indicator: the attacker’s browser, curl, or Burp lab is making authenticated requests on the victim’s behalf - the server treats the requests as the victim’s own.

The session model in one paragraph

HTTP is stateless. Every request stands alone - the server has no way to know it’s the same user from one request to the next except by what the request itself carries. Web apps solve this by issuing a session identifier (random string) at login, storing it as a cookie in the browser, and looking up the user’s state in a server-side store on every subsequent request that presents that identifier. The session identifier is therefore equivalent to the user’s authenticated identity for the duration of the session. Steal it, and you’re them.

A “session attack” is any of:

Attack	What it does	When it works
Hijacking	Take a session identifier you already have, use it	Always - the question is how you got the identifier
Fixation	Force the victim to use an identifier you set, then ride it after they log in	When the app reuses pre-login session IDs after auth
Sniffing	Read identifiers off the wire	Plaintext HTTP traffic + network position
XSS exfiltration	JavaScript in the victim’s browser reads document.cookie and sends it to you	XSS + HttpOnly not set on cookies
CSRF	Issue authenticated requests in the victim’s name without needing the cookie value	The server checks cookies but no anti-CSRF token (or you can bypass it)
Open redirect token leak	Coerce the app to include the token in a URL pointing to attacker-controlled domain	App’s redirect doesn’t validate target + tokens travel in URLs or POST bodies that follow redirects
Post-exploitation retrieval	Read session-store files from a server you’ve already compromised	RCE on the app server
Database session theft	Read session table from a compromised database	DB compromise + sessions stored in DB

The TL;DR’s flow - identify → harvest → ride → chain - is the four-step lens you apply to every engagement.

Where session state lives

Knowing where the identifier is stored tells you which attacks are viable:

Storage	Stealable via	Survives across
Cookie (HTTP Cookie: header)	XSS (unless HttpOnly), sniffing (unless Secure+TLS), CSRF without needing the value	Tabs, restarts (if persistent)
URL parameter	Referer header leak, browser history, server logs, screen-share recordings	URL navigation only
Hidden form field	XSS (read the DOM), HTML injection (leak via crafted markup)	Page reload only - gone on navigation
localStorage	XSS (any script can read it; HttpOnly doesn’t apply)	Browser restart
sessionStorage	XSS (same scope as localStorage)	Tab close
HTTP Authorization: header (Bearer token)	XSS + JS reads from app state, sniffing without TLS, RCE on app server	Session lifetime
Server-side file	Post-exploit RCE on app server	Until session expires server-side
Server-side DB row	DB compromise (SQLi, credential theft)	Until session expires server-side

The cookie with HttpOnly + Secure + SameSite=Strict is the strongest browser-side configuration. Cookies without these flags are XSS-readable, sniff-able, and CSRF-rideable respectively. Tokens stored in localStorage are always JavaScript-accessible - moving a token from a HttpOnly cookie to localStorage for “convenience” downgrades security.

What this cluster covers

Page	Focus
Hijacking	The mechanics of riding a stolen identifier - DevTools cookie swap, Burp swap, curl with -b/-c
Fixation	Forcing a known identifier on the victim; auth-doesn’t-regenerate detection
Obtaining tokens	Sniffing (Wireshark, mitmproxy, ARP poisoning context), post-exploit retrieval (PHP/Java/.NET paths), DB extraction
XSS to session	XSS as a cookie-stealing primitive; cookie-logger PHP server; HttpOnly check; XSSHunter/Collaborator/Interactsh callback infra
CSRF	CSRF fundamentals; HTML auto-submit forms; GET vs POST; SameSite; anti-CSRF tokens
CSRF token bypass	Weak token analysis (md5(username)), null/blank/random token bypass, cross-account tokens, Referer regex bypass, method tampering
XSS + CSRF chain	When SameSite blocks cross-origin requests: stage the request from the target’s own origin via XSS; the XMLHttpRequest token-extract pattern
Open redirect	Discovery patterns (?url=, ?redirect=, ?next=…); leaking session tokens that travel with redirects; phishing chains
Chaining final	End-to-end engagement: XSS in profile + open redirect on admin endpoint → admin session theft, the canonical real-world chain

Cross-cluster references

This cluster overlaps with several others; each link gives the operator-level details the sessions material assumes:

Topic	Page
Cookie attributes deep-dive	Auth: cookie tampering
Session fixation fundamentals	Auth: session fixation
JWT-specific attacks	Auth: JWT
Password reset flows	Auth: reset tokens
File upload that delivers XSS	Uploads
Server-side compromise to access sessions	LFI, Server-side
SQL injection to dump session tables	SQLi cluster

A philosophical note on scope

XSS and CSRF have full pentest curricula of their own - XSS especially has its own taxonomy (reflected, stored, DOM-based, mutation, blind). This cluster covers them through the lens of what makes them useful for stealing or hijacking sessions specifically, which is one of the highest-impact outcomes of those vulnerabilities. The page on XSS-to-session doesn’t try to be a complete XSS reference; it covers cookie exfiltration patterns and callback infrastructure. Similarly, CSRF coverage focuses on session-effective abuse (state-changing actions on the user’s behalf), not on every CSRF defense or weird edge case.

When a finding turns out to deserve fuller treatment beyond session-attack utility - e.g., a DOM-based XSS chain that requires deep prototype-pollution understanding - that’s the moment to escalate beyond this cluster.