Common JWT Attack Techniques

Here are the most common attack techniques targeting JWT implementations:

Algorithm Confusion Attack

How It Works

Algorithm confusion (also known as algorithm substitution) attacks exploit implementations that don't properly validate the algorithm specified in the JWT header. The attack involves changing the algorithm from an asymmetric algorithm (like RS256) to a symmetric one (like HS256).

Example Attack

// Original JWT header (RS256)
{
  "alg": "RS256",
  "typ": "JWT"
}

// Modified JWT header (HS256)
{
  "alg": "HS256",
  "typ": "JWT"
}

// The attacker then signs the token with HS256 using the public key as the secret

Prevention

• Always validate the algorithm and reject tokens with unexpected algorithms
• Use a whitelist approach to only accept specific algorithms
• Implement strict type checking for keys based on the algorithm
• Use libraries that prevent algorithm confusion by design

None Algorithm Attack

How It Works

The "none" algorithm attack exploits implementations that accept tokens with the "none" algorithm, which indicates that the token is not signed. If a server accepts such tokens, an attacker can forge tokens without needing any secret keys.

Example Attack

// Original JWT header
{
  "alg": "HS256",
  "typ": "JWT"
}

// Modified JWT header
{
  "alg": "none",
  "typ": "JWT"
}

// The signature part is either empty or removed entirely
// Format: header.payload.  (note the trailing dot with nothing after it)

Prevention

• Explicitly reject tokens with the "none" algorithm
• Use a whitelist of allowed algorithms
• Ensure your JWT library doesn't accept "none" algorithm by default
• Always verify signatures regardless of the algorithm specified

Weak Secret Keys Attack

How It Works

When JWTs are signed with HMAC algorithms (HS256, HS384, HS512) using weak secrets, attackers can brute-force the secret and forge valid tokens. Common weak secrets include dictionary words, short strings, or predictable patterns.

Tools Used

• JWTAuditor Secret Bruteforcer: Our tool for testing JWT secrets against common dictionaries
• Hashcat: A popular password cracking tool that supports JWT cracking
• John the Ripper: Another password cracking tool with JWT support

Prevention

• Use strong, randomly generated secrets of at least 256 bits (32 bytes)
• Consider using asymmetric algorithms (RS256, ES256) instead of HMAC
• Rotate secrets regularly
• Use a secret manager to generate and store strong secrets

Token Tampering

How It Works

Token tampering involves modifying the payload of a JWT to change claims like user roles, permissions, or identities. This attack is only possible if the attacker can also create a valid signature, which might be achieved through other attacks like algorithm confusion or weak secrets.

Example Attack

// Original JWT payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "role": "user",
  "iat": 1516239022,
  "exp": 1516242622
}

// Tampered JWT payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "role": "admin",  // Changed from "user" to "admin"
  "iat": 1516239022,
  "exp": 1516242622
}

Prevention

• Use strong signature algorithms and keys
• Implement proper server-side validation of claims
• Don't rely solely on JWT claims for critical authorization decisions
• Consider using encrypted JWTs (JWE) for sensitive data
• Implement additional server-side checks for sensitive operations

Token Replay Attack

How It Works

Token replay attacks involve capturing a valid JWT and reusing it after it should have been invalidated, such as after logout or expiration. This is particularly problematic in systems that don't properly track token usage or don't implement token revocation.

Prevention

• Use short expiration times for tokens
• Implement token blacklisting for logged-out tokens
• Use the JWT ID (jti) claim to track and revoke specific tokens
• Implement refresh token rotation
• Use secure, HttpOnly cookies for token storage to mitigate XSS risks

Key ID (kid) Injection

How It Works

The "kid" (Key ID) parameter in the JWT header is used to indicate which key should be used to verify the signature. If this parameter is not properly validated, attackers can manipulate it to point to a key they control or to exploit path traversal vulnerabilities.

Example Attack

// Original JWT header
{
  "alg": "HS256",
  "typ": "JWT",
  "kid": "key1"
}

// Modified JWT header with path traversal
{
  "alg": "HS256",
  "typ": "JWT",
  "kid": "../../public/key"
}

// Modified JWT header pointing to a known weak key
{
  "alg": "HS256",
  "typ": "JWT",
  "kid": "weak_key"
}

Prevention

• Validate and sanitize the "kid" parameter
• Use a whitelist approach for allowed key IDs
• Avoid using file paths in the "kid" parameter
• Implement proper access controls for key storage
• Use a key management system with secure key rotation

Practical Testing with JWTAuditor

JWTAuditor provides several tools to help you test your JWT implementation for these vulnerabilities:

Conclusion

JWT security depends on proper implementation and validation. By understanding these attack techniques, you can better protect your applications from potential vulnerabilities.

Always follow security best practices, use up-to-date libraries, implement proper validation, and regularly test your JWT implementation for vulnerabilities.