Authentication & Sessions

TL;DR

Authentication is “prove you’re someone.” Sessions are “keep being them.” Bugs in either category give the attacker either someone else’s account or someone else’s privileges - usually with a payload no bigger than one HTTP request.

# Username enumeration (different responses for valid vs. invalid users)
POST /login   username=admin       password=wrong  → "Invalid password for admin"
POST /login   username=nope        password=wrong  → "Unknown username"

# Reset-token brute-force (short, time-based, or weak crypto)
GET  /reset?user=admin&token=00000 … 99999          → eventually one returns success

# Session cookie tampering (decode → modify → re-encode)
Cookie: SESSIONID=757365723A6874623B726F6C653A75736572
        ↓ hex decode
        user:htb;role:user
        ↓ change role
        user:htb;role:admin
        ↓ re-encode and send

Success indicator: access to an account or privileges you weren’t issued.

Where to look

Anywhere the application takes a credential, hands out a token, or trusts a token on subsequent requests:

• Login forms - username/password, OTP step, “remember me” checkbox
• Registration forms - username availability checks leak which users exist
• Password reset / forgot password - generates a token, often weakly
• Profile and settings pages - password change, MFA enrollment, security questions
• Session cookies - SESSIONID, auth, token, jwt, framework-specific names (PHPSESSID, JSESSIONID, ASP.NET_SessionId)
• JWT in Authorization: Bearer ... headers - signature scheme, expiry, claims
• Magic-link emails - single-use authentication URLs
• Cookie-based auth on legacy admin panels - older apps with custom session handling

If the application has any concept of “who you are” between requests, this section applies.

Decision flow

A typical engagement against a login surface walks these steps in order. Skip ahead where the bug pattern’s already obvious.

1. Default or guessable credentials? Vendor logins, demo accounts, common patterns (admin:admin, tech:tech) → Default credentials
2. Bruteforce protections in place? CAPTCHA, rate limits, lockouts - assess whether they’re tamperable → Bruteforce protections
3. Can you tell valid usernames from invalid ones? Error messages, response timing, password-reset replies, registration-form availability checks → Username enumeration
4. What’s the password policy? Determines wordlist filtering and brute-force feasibility → Password policy inference
5. Reset tokens predictable? Time-based, short numeric codes, weak crypto, never-expiring → Reset tokens
6. Security questions in the reset flow? “Mother’s maiden name” / “city of birth” - OSINT and rotating-question scraping → Security questions
7. Reset form trusts user-supplied identity? userid in $_REQUEST overriding the session - change someone else’s password from your account → Username injection
8. Session cookie contains identity or role? Decode and tamper → Cookie tampering
9. Same session token persists across login states? Pre-auth token reused post-auth → Session fixation
10. JWT in use? Check alg, expiry, signature handling → JWT

Attack categories

The bugs in this section break down by what the operator is attacking:

Category	What you’re attacking	What you get
Credential brute-force	Authentication endpoint	Access to one specific account
Username enumeration	Error message / response semantics	List of valid users for further targeting
Reset-token weaknesses	Forgot-password flow	Account takeover without knowing the password
Identity injection	Reset / change-password flow	Account takeover by overriding the session’s user
Session cookie tampering	Cookie format / encoding	Privilege escalation within your own session
Session fixation	Token issuance / invalidation logic	Hijack a session you can predict
JWT abuse	Token signature, claims, expiry	Forged identity claims accepted by the server

The last column is the operationally important one. The brute-force and enumeration paths are stepping-stones; the tampering and injection paths are the win.

Authentication background

Most of this section is about the knows domain - passwords, security answers, tokens that prove the user knows a secret. Two other authentication categories exist but are out of scope for a web reference:

• HAS domain - physical tokens (hardware keys, badges, OTP devices). Attacks include cloning, OTP-algorithm breaks, theft. Not web-app exploitable.
• IS domain - biometrics (fingerprint, face, retina). Attacks include lifted prints, deepfakes, leaked biometric databases. Also not web-app exploitable.

The web layer can interact with HAS / IS authentication (e.g., FIDO2 / WebAuthn over HTTPS), but the attacks themselves happen at the device or hardware level.

MFA / 2FA combines two of these categories. When MFA is in place, the bugs below are still useful - they just don’t give a full account takeover until the second factor is also handled (separately, usually by phishing or social engineering for the OTP).

Authentication mechanisms in scope

Mechanism	Where it appears	What the bugs look like
Form-based (FBA)	The dominant pattern - username/password POST, session cookie response	Everything in this section
HTTP Basic / Digest / NTLM	Often internal apps, admin panels, legacy systems	Credentials sent every request → easier to capture; weak realm separation
Token-based (JWT, opaque tokens)	APIs, SPAs, mobile backends	Signature attacks, claim tampering, replay → JWT
Source-IP-based	Localhost-trust, “trusted network” admin panels	X-Forwarded-For spoofing → Bruteforce protections
SSO (SAML, OIDC)	Enterprise apps, federated logins	Separate attack class - assertion replay, signature bypass, issuer confusion

SSO attacks are their own discipline and have their own page family that will exist eventually - for now, the SSO sinks present in apps that also have form-based fallback often share enough surface with the bugs below.

Operating notes

The single most useful habit: register your own account first. Knowing what a valid login response looks like, what cookies get set, what the success message reads as - that becomes the oracle for everything else. Every page in this section assumes you have a working comparison point.

The second most useful habit: read the source of the login response. Hidden form fields, anti-CSRF tokens, response-time differences, framework names in error messages, the exact phrasing of “wrong username” vs. “wrong password” - all of it is information disclosure that the per-page techniques convert into access.

Caution

Authentication attacks are noisy by default. Brute-force generates obvious traffic patterns, account lockouts irritate real users, and a successful takeover leaves logs naming the compromised account. Coordinate with the blue team or limit to authorized testing windows. The “stealth” path here is account-takeover via reset-token weaknesses or cookie tampering - those produce a single anomalous successful login rather than a wall of failed attempts.

The detection-style pages (username enumeration, policy inference) are the right starting points on most engagements. The exploitation pages (cookie tampering, username injection, JWT) assume you’ve done enumeration first and know which user you’re targeting.