domains / families / security / hunt-session

hunt-session

combined

Hunt Session Management vulnerabilities Hunt Session Management vulnerabilities — session fixation (no regeneration on login), insufficient invalidation on logout / password-change / email-change, predictable or low-entropy session IDs, JWT-as-session with no exp/revocation, refresh-token rotation/reuse-detection gaps, OAuth/SSO session linkage, device-bound-session (DBSC) downgrade, and cookie attribute issues (Secure/HttpOnly/SameSite/__Host-). Validate with TWO real sessions (attacker A + victim B), body-diff every 200, and OOB confirmation for theft chains. Medium to Critical (fixation→admin hijack, no-invalidation→persistent ATO).

When to use

• You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
• You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.

When not to use

• Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
• Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
• Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.

Skill page

Conflict

The uphiago copy is the more complete, executable procedure (two-session rule, curl jar helpers, phased methodology), while the sickn33 copy adds a mandatory authorization gate, an autonomous testing priority, and three concise lifecycle patterns (logout, fixation, password-change) that the uphiago copy does not explicitly front-load. Neither copy is a pure reproduction of the other; crowning one would hide the authorization gate and the concise pattern list, or the detailed two-session proof method.