Common JWT Vulnerabilities

// Vulnerable token
{
  "alg": "none",
  "typ": "JWT"
}

// Attacker can modify payload without signature
// Server accepts it because algorithm is "none"

// Server expects RS256 (asymmetric)
// But accepts HS256 (symmetric) if not validated

// Attacker:
// 1. Gets public key (often exposed in JWKS endpoint)
// 2. Changes algorithm to HS256
// 3. Signs token with public key as secret
// 4. Server verifies with public key as secret - SUCCESS!

// Weak secrets
secret = "secret"
secret = "password"
secret = "123456"

// Attacker can brute force these easily

// NEVER do this
{
  "sub": "user123",
  "password": "plaintext_password",  // ❌
  "credit_card": "1234-5678-9012",  // ❌
  "ssn": "123-45-6789"              // ❌
}

// Only include non-sensitive data
{
  "sub": "user123",
  "name": "John Doe",
  "role": "admin"
}

// Vulnerable header
{
  "alg": "RS256",
  "kid": "../../../etc/passwd",  // Path traversal
  "jku": "https://attacker.com/keys.json",  // External key source
  "x5u": "https://evil.com/cert.pem"  // Malicious certificate
}

// Attack scenarios:
// 1. kid injection: Point to a predictable or weak key
// 2. jku spoofing: Redirect to attacker's JWKS endpoint
// 3. x5u manipulation: Use attacker's certificate

// Attacker creates token with malicious jku
{
  "alg": "RS256",
  "jku": "https://attacker.com/.well-known/jwks.json"
}

// Attacker hosts their own JWKS endpoint with their private key
// Server fetches the key and verifies the token - SUCCESS!

// Prevention:
// - Only allow JWKS from trusted domains
// - Use CORS and certificate pinning
// - Cache JWKS responses

// Server expects RS256, but doesn't validate algorithm
// Attacker:
// 1. Obtains public key (often from /.well-known/jwks.json)
// 2. Changes algorithm from RS256 to HS256
// 3. Signs token with public key as HMAC secret
// 4. Server verifies with public key as secret - accepts!

// Vulnerable verification:
jwt.verify(token, publicKey);  // ❌ Doesn't check algorithm

// Secure verification:
jwt.verify(token, publicKey, { algorithms: ['RS256'] });  // ✅

// Claim injection
{
  "sub": "user123",
  "role": "admin",  // Injected claim
  "isAdmin": true,  // Privilege escalation
  "permissions": ["*"]  // Overly permissive
}

// Replay attack:
// 1. Attacker captures a valid token
// 2. Token is expired but server doesn't check
// 3. Attacker replays the token indefinitely

// Prevention:
// - Validate all claims
// - Check jti (JWT ID) for replay prevention
// - Use short expiration times
// - Implement token blacklisting

// Scenario:
// 1. Token references jku: "https://keys.example.com/.well-known/jwks.json"
// 2. Subdomain "keys.example.com" is not properly secured
// 3. Attacker takes over subdomain (expired DNS, misconfigured hosting)
// 4. Attacker hosts their own JWKS with their private key
// 5. Server accepts tokens signed with attacker's key

// Prevention:
// - Secure all subdomains
// - Use certificate pinning
// - Monitor subdomain status
// - Whitelist specific JWKS endpoints

// Vulnerable (timing attack possible):
if (signature === expectedSignature) {  // ❌
  return true;
}

// Secure (constant-time comparison):
if (crypto.timingSafeEqual(signature, expectedSignature)) {  // ✅
  return true;
}

// Attack:
// Attacker measures response time for different signatures
// Timing differences reveal information about the secret