Authentication & Session - Hunter Knowledge Base

Failures in proving who the user is (vs access-control, which is what they may do). Covers login, sessions, tokens, password handling, and account recovery.

What to hunt

• JWT flaws: alg:none accepted; algorithm confusion (RS256 verified with the public key as an HMAC secret); signature not verified (decode without verify); secret hardcoded/weak (offline-brute-forceable); no exp check; trusting unverified claims for authz. Header-parameter injection: kid used to look up the verification key via a path (traversal to a predictable low-entropy file, e.g. /dev/null -> empty-string HMAC key) or a DB query (SQLi); jwk header lets the server verify against an attacker-embedded public key (attacker signs with the matching private key); jku/x5u header points to an attacker-hosted key set/certificate with no host allowlist.
• Session management: session id not rotated after login (fixation, CWE-384); no server-side invalidation on logout; predictable/low-entropy tokens; missing HttpOnly/Secure/SameSite; overly long/absent expiry (CWE-613); session token in URL.
• Password handling: plaintext or fast-hash storage (md5/sha1/unsalted) instead of bcrypt/scrypt/ argon2 (CWE-256/916); no rate limiting / lockout (credential stuffing, CWE-307); timing-unsafe comparison of secrets (== on tokens); lockout counter keyed by source IP instead of the account (trivially bypassed with distributed attempts) or a lockout with no path to self-recovery (usable as a DoS against a victim).
• Account recovery: guessable/predictable reset tokens, reset token that doesn't expire or isn't single-use, host-header poisoning in reset links, user enumeration via differing responses (CWE-640).
• MFA: verification step skippable, OTP not rate-limited/reusable, backup-code weaknesses.
• Broken "remember me" / trust tokens; OAuth state missing (CSRF on login); redirect_uri not validated.

Sinks / patterns (grep targets)

jwt.decode(/verify(, algorithms=, verify=False, verify_signature, md5(/sha1( near "password", == comparing tokens/HMACs (vs hmac.compare_digest/crypto.timingSafeEqual), session[, set_cookie, SECRET_KEY, random/Math.random for tokens, password_reset, otp, login, authenticate, JWT header parsing that reads kid/jwk/jku/x5u before signature verification.

Detection recipe

1. Find the login, logout, session-issue, password-store, and reset flows from codebase-map.json.
2. For JWT: check the verify call actually verifies signature + exp + expected alg, and the secret's source.
3. For sessions: is the id regenerated on privilege change/login? cookie flags set? entropy adequate?
4. For passwords: which hash + salt? is comparison constant-time? is there lockout/rate limiting?
5. For reset: token entropy, expiry, single-use, and whether the reset link host comes from a request header.

Payloads / PoC

• JWT none: set header {"alg":"none"}, drop signature, change sub/role. Confusion: sign with RS256 public key as HMAC secret. Expired token still accepted -> no exp check.
• JWT header injection: kid -> ../../../../dev/null (then sign with empty-string HMAC key) or a SQLi string if kid feeds a key-lookup query; jwk -> attacker's own public key embedded in the header, token signed with the matching private key; jku/x5u -> attacker-controlled URL serving a malicious key set/certificate.
• Fixation: set a session id pre-login, authenticate, check it's unchanged.
• Reset poisoning: POST /forgot with Host: attacker.com -> link points to attacker.
• Enumeration: compare responses/timing for known vs unknown usernames.

False-positive filters

• Vetted library with defaults (Django auth, Devise, Spring Security, NextAuth, Passport) used correctly.
• JWT verified with the right algorithm+secret and exp/nbf enforced; secret from env/secret manager.
• kid resolves only against a fixed in-memory/config map of known key ids (no path/DB use); jwk header ignored in favor of a pinned server-side key; jku/x5u restricted to a strict host allowlist.
• Passwords via bcrypt/argon2/scrypt with per-user salt; constant-time compares for secrets.
• Session id from a CSPRNG; cookie flags set; rotation on login present in middleware.
• Lockout counter keyed by account (not just source IP) with a bounded exponential delay, and a working self-recovery path so lockout can't be used to lock out a victim.

CWE / OWASP / severity

CWE-287/384/613/620/640/307/916. OWASP A07:2021. Auth bypass / token forgery -> critical; weak hashing or missing lockout -> high; missing cookie flags / enumeration -> medium.

Chaining hints

Weak session/JWT + xss or open-redirect/Referer leak -> token theft -> takeover; user enumeration + no lockout -> credential stuffing; reset-token flaw -> account takeover; access-control IDOR that leaks tokens feeds this. Auth bypass unlocks every authenticated finding.

Mitigation

Use a maintained auth framework; verify JWT signature+alg+exp (never none); pin/allowlist the verification key rather than trusting kid/jwk/jku/x5u from the token itself; store passwords with argon2/bcrypt+salt; constant-time secret comparison; rotate session id on login and invalidate on logout; set HttpOnly/Secure/SameSite; CSPRNG single-use expiring reset tokens; rate-limit + lockout keyed by account with exponential backoff and a DoS-safe recovery path; enforce MFA.