JWT STRUCTURE:
Header.Payload.Signature

Example:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

ALGORITHM CONFUSION FLOW:
1. Server expects RS256 (RSA + SHA256)
2. Attacker changes alg to HS256 (HMAC + SHA256)
3. Server's public RSA key used as HMAC secret
4. Attacker generates valid HMAC signature
5. Server verifies with same key -> bypass

HMAC BRUTE FORCE WITH HASHCAT:
hashcat -a 0 -m 16500 <JWT_TOKEN> /path/to/jwt.secrets.list

Mode 16500 = JWT signature cracking
Use --show to display previously cracked results
Wordlists: SecLists/Passwords/scraped-JWT-secrets.txt

COMMON VALIDATION ERRORS:
├── Missing Algorithm Verification
│   ├── Accept any algorithm in header
│   ├── No algorithm allowlist
│   └── Default to insecure algorithms
├── Improper Key Handling
│   ├── Same key for multiple algorithms
│   ├── Public key reuse
│   └── Key confusion attacks
├── Logic Bypasses
│   ├── Empty signature acceptance
│   ├── Null signature handling
│   └── Exception swallowing
└── decode() vs verify()
    ├── Using jwt.decode() instead of jwt.verify()
    ├── Decoding without signature check
    └── Trusting decoded payload as authenticated

// VULNERABLE: direct file path from kid
const keyPath = `/keys/${kid}`;
const key = fs.readFileSync(keyPath);

// SECURE: allowlist mapping
const allowedKeys = {
  'key-2024-01': '/secure/keys/2024-01.pem',
  'key-2024-02': '/secure/keys/2024-02.pem'
};
if (!allowedKeys.hasOwnProperty(kid)) throw new Error('Invalid key');
const key = fs.readFileSync(allowedKeys[kid]);

// VULNERABLE: string concatenation
String query = "SELECT key FROM keys WHERE kid = '" + kidValue + "'";

// SECURE: parameterized query
PreparedStatement stmt = conn.prepareStatement("SELECT key FROM keys WHERE kid = ?");
stmt.setString(1, kidValue);

JKU ATTACK CHAIN:
1. Attacker controls jku parameter
2. Points to malicious JWK Set (hosted on attacker server)
3. Server fetches attacker's keys without URL validation
4. Token validates with attacker's key
5. Complete authentication bypass

SSRF CLASSIFICATION: jku fetching = server-side request to attacker URL

JWK INJECTION ATTACK:
1. Attacker generates own RSA key pair
2. Modifies JWT payload (e.g., role: "admin")
3. Adds own public key in jwk header parameter
4. Sets kid to match the embedded jwk
5. Signs token with own private key
6. Server uses embedded public key to verify -> bypass

REQUIRES: Server accepts jwk parameter without key allowlisting

PAYLOAD ATTACK PATTERNS:
├── Privilege Escalation
│   ├── Role claim modification (user -> admin)
│   ├── Permission array tampering
│   └── Group membership changes
├── Time-Based Attacks
│   ├── Expiry extension (exp)
│   ├── Not-before bypass (nbf)
│   └── Issued-at manipulation (iat)
├── Cross-Application Attacks (Substitution)
│   ├── Audience switching (aud)
│   ├── Issuer spoofing (iss)
│   ├── Token reuse across services
│   └── Cross-JWT confusion (RFC 8725 Section 2.8)
└── Indirect Server Attacks
    ├── Claims used in LDAP lookups (injection)
    ├── Claims used in database queries (SQLi)
    └── Claims containing URLs (SSRF)

FRAMEWORK VULNERABILITIES:
├── Express.js/Node.js
│   ├── jsonwebtoken algorithm confusion
│   ├── jwt.decode() vs jwt.verify() misuse
│   ├── Middleware bypass techniques
│   ├── CVE-2022-23529 (secretOrPublicKey object injection)
│   └── Error handling flaws
├── Django/Python
│   ├── PyJWT verification bypasses
│   ├── Algorithm None attacks
│   ├── Key handling issues
│   └── Flask-JWT-Extended misconfiguration
├── Spring Boot/Java
│   ├── JJWT library flaws
│   ├── Algorithm validation bypass
│   ├── CVE-2022-21449 (EC Psychic Signatures)
│   ├── Token sidejacking defenses (OWASP)
│   └── Key injection vulnerabilities
├── ASP.NET/C#
│   ├── System.IdentityModel flaws
│   ├── Algorithm confusion
│   └── Certificate validation bypass
└── Go
    ├── dgrijalva/jwt-go audience bypass
    ├── Master branch vs tagged release divergence
    └── VerifyAudience empty string acceptance

CTF EXAMPLE: JWT None Algorithm -> Admin Panel -> SSTI -> RCE

Chain:
1. Decode JWT, identify role claim ("user")
2. Set alg to "none", change role to "admin", strip signature
3. Access admin panel with forged token
4. Discover input field vulnerable to Jinja2 SSTI
5. Execute RCE via Python class hierarchy traversal:
   {​% for x in ().__class__.__base__.__subclasses__() %}
     {​% if "warning" in x.__name__ %}
       {​{x()._module.__builtins__["__import__"]("os").popen('whoami').read()}}
     {​% endif %}
   {​% endfor %}
6. Read flag from filesystem

Impact: JWT auth bypass -> privilege escalation -> code execution

TOKEN FINGERPRINTING:
1. On authentication, generate random string (50 bytes, SecureRandom)
2. Send raw value as hardened cookie:
   __Secure-Fgp=<value>; SameSite=Strict; HttpOnly; Secure
3. Store SHA-256 hash of value in JWT claim (userFingerprint)
4. On each request:
   a. Read fingerprint cookie
   b. Hash it with SHA-256
   c. Compare to JWT claim
   d. Reject token if mismatch

BENEFIT: Even if JWT is stolen, attacker lacks the HttpOnly cookie
NOTE: Avoid IP-based fingerprinting (changes on mobile networks, GDPR concerns)

SECURE KEY PRACTICES:
├── Key Generation
│   ├── Cryptographically random (SecureRandom, os.urandom)
│   ├── Sufficient entropy (256+ bits for HMAC)
│   ├── Algorithm-specific requirements
│   └── Never use human-memorizable passwords as HMAC keys
├── Key Storage
│   ├── Hardware security modules (HSM)
│   ├── Cloud KMS (AWS KMS, Azure Key Vault, GCP KMS)
│   ├── Environment variables (development only)
│   └── Never hardcode in source code
├── Key Rotation
│   ├── Regular rotation schedule
│   ├── Grace periods for old keys (support both during transition)
│   └── Emergency rotation procedures
├── Key Distribution
│   ├── Secure channels only (HTTPS)
│   ├── JWK Set endpoints (/.well-known/jwks.json)
│   └── Certificate-based PKI
└── Key-Algorithm Binding
    ├── Each key used with exactly one algorithm
    ├── Separate keys for signing vs encryption
    └── Validated at cryptographic operation time

ATTACK SEQUENCE:
├── Token Acquisition
│   ├── Login with valid credentials
│   ├── Social engineering
│   └── Token leakage (logs, URLs, Referer headers)
├── Token Analysis
│   ├── Decode header and payload (base64url)
│   ├── Identify critical claims (role, sub, aud)
│   ├── Determine algorithm
│   └── Check for optional header params (kid, jku, jwk)
├── Vulnerability Testing
│   ├── Algorithm none (with case variants)
│   ├── Algorithm confusion (RS256 -> HS256)
│   ├── Signature removal / empty signature
│   ├── Weak secret brute force (hashcat -m 16500)
│   ├── kid injection (path traversal, SQLi)
│   ├── jku/jwk injection
│   ├── Claim manipulation (role, sub, exp)
│   └── decode() vs verify() check
├── Escalation
│   ├── Forge admin tokens
│   ├── Chain with other vulns (SSTI, SSRF, SQLi)
│   └── Cross-service token reuse
└── Impact Assessment
    ├── Authentication bypass
    ├── Privilege escalation
    ├── Data access
    └── Remote code execution (via chaining)

RFC 8725 / draft-sheffer-oauth-rfc8725bis KEY REQUIREMENTS:
├── Algorithm Verification
│   ├── Libraries MUST let caller specify supported algorithms
│   ├── MUST NOT use algorithms not in the specified set
│   ├── Each key MUST be used with exactly one algorithm
│   └── MUST be checked at cryptographic operation time
├── Cryptographic Hygiene
│   ├── Validate all cryptographic operations (including nested JWTs)
│   ├── Validate elliptic curve inputs (invalid curve attacks)
│   ├── Keys MUST have sufficient entropy (256+ bits)
│   ├── Avoid compression before encryption
│   └── Use UTF-8 encoding exclusively
├── Claim Validation
│   ├── Validate issuer and subject
│   ├── Use and validate audience
│   ├── Do NOT trust received claims for server-side operations
│   └── Use explicit typing (typ header) to prevent cross-JWT confusion
├── Format Safety (RFC 8725bis additions)
│   ├── Limit hash iteration count (PBES2 p2c parameter)
│   ├── Check JWT format type (JWS vs JWE)
│   └── Limit JWE decompression size
└── General
    ├── Use RSAES-OAEP instead of RSA-PKCS1 v1.5
    ├── Implement ECDSA with deterministic nonces (RFC 6979)
    └── Use mutually exclusive validation rules for different JWT types

SECURE IMPLEMENTATION PATTERNS:
├── Node.js/Express
│   ├── Use jsonwebtoken with explicit algorithms option
│   ├── ALWAYS use jwt.verify(), NEVER jwt.decode() for auth
│   ├── Implement proper error handling (no stack traces)
│   ├── Validate all claims explicitly
│   └── Keep jsonwebtoken >= v9.0.0
├── Python/Django/Flask
│   ├── PyJWT with algorithms parameter (whitelist)
│   ├── Always verify signature before trusting claims
│   ├── Custom middleware for validation
│   ├── Secure key storage (environment variables / KMS)
│   └── Flask-JWT-Extended with secure cookie configuration
├── Java/Spring Boot
│   ├── Spring Security JWT support with algorithm validation
│   ├── Token sidejacking with fingerprint cookies (OWASP pattern)
│   ├── Token denylist for revocation
│   ├── JWK Set endpoints for key distribution
│   ├── Ensure JDK patched for CVE-2022-21449
│   └── Use auth0/java-jwt or nimbus-jose-jwt (latest)
├── .NET/ASP.NET Core
│   ├── Microsoft.IdentityModel.JsonWebTokens
│   ├── TokenValidationParameters (strict configuration)
│   └── Strict algorithm validation
└── Go
    ├── Use golang-jwt/jwt (not dgrijalva/jwt-go)
    ├── Validate audience explicitly
    └── Pin to tagged releases, not master branch