JWT Authentication Attack Sectors

I spend a lot of time looking at JWTs at my my day job. I started to write down with help of AI some attack vectors that could be used against JWT. This is a summary of those notes. JWT vulnerabilities typically stem from three areas: 1) Implementation Flaws, 2) Cryptographic Weaknesses, and 3) Design Misconfigurations. Unlike a single “bug,” JWT security requires a holistic understanding of the entire token lifecycle, from generation to validation.

---

Core Attack Sectors & Vectors

Sector 1: Token Tampering & Algorithm Manipulation

1. The “alg”: “none” Attack

• Description: An attacker alters the JWT header to specify the alg parameter as none, indicating no cryptographic signature. If the verification library is not configured to reject this, it will accept any token.
• Prerequisites: A vulnerable JWT library that permits the none algorithm.
• Research Tip: Test with: {"alg":"none","typ":"JWT"}.{"user":"admin"}. (Note the empty signature).

2. Algorithm Confusion (Key Confusion)

• Description: The most common and critical JWT vulnerability. An attacker creates a token signed using an asymmetric algorithm (like RS256) but the server’s verification logic is tricked into using a symmetric algorithm (HS256).
• How it works:
  1. The server normally uses RS256 (private/key for signing, public key for verifying). The public key is often easily accessible.
  2. The attacker changes the header to {"alg": "HS256", "typ": "JWT"}.
  3. The attacker uses the public key (as if it were an HMAC secret) to sign the forged token.
  4. If the server’s verification code blindly uses the alg from the token and verifies the HMAC signature using the public key, the verification will succeed.
• Prerequisites: The server uses a mixed or flawed verification logic that trusts the alg header from the client. The public key must be known to the attacker.
• Research Tip: Tools like jwt_tool can automate this attack. The challenge is often finding the public key (e.g., /.well-known/jwks.json, /protocol/openid-connect/certs).

3. Algorithm Downgrade

• Description: Similar to confusion, but the attacker forces a downgrade from a strong algorithm (e.g., RS256) to a weaker one (e.g., HS256 with a weak secret) that the server still accepts for legacy reasons.

Sector 2: Signature Verification Bypasses

1. No Signature Verification

• Description: Shockingly, some developers implement JWT parsing but forget to call the verification function entirely. The application simply decodes the token and trusts the payload.
• Research Tip: Modify the payload (e.g., change "user":"bob" to "user":"admin"), keep the signature invalid or remove it, and see if the application still accepts it.

2. “Kid” (Key ID) Parameter Manipulation

• Description: The kid (Key ID) in the header tells the server which key to use for verification. This parameter can be a source of several vulnerabilities.
  • Path Traversal: "kid": "../../../dev/null" – If the server constructs a file path based on kid, an attacker can point to a known file (like /dev/null or /etc/passwd) and then sign the token with a null byte or the known file content.
  • SQL Injection: "kid": "key1; SELECT 'abc' -- " – If the kid is used in a database query to fetch the key.
  • Command Injection: "kid": "key1 | whoami" – If the kid is passed to a shell command.

Sector 3: Claims & Payload Manipulation

1. “exp” (Expiration Time) Claim

• Description: If the server does not validate the expiration time, tokens can be used indefinitely.
• Research Tip: Take an old, valid token and resend it.

2. “nbf” (Not Before) Claim

• Description: Similar to exp, this claim defines when a token becomes valid. It can be bypassed if not validated.

3. “iss” (Issuer) and “aud” (Audience) Claims

• Description:
  • Issuer: The entity that created the token. If multiple issuers are trusted, an attacker might use a token from a weak issuer.
  • Audience: The intended recipient of the token. If the server does not check the aud claim, a token generated for one service (e.g., aud: serviceA) might be accepted by another (serviceB).

4. “cty” (Content Type) Attack

• Description: A more complex attack where setting "cty":"JWT" in the header can trick the server into processing a nested JWT, potentially bypassing validation in a different part of the code. This is less common but sophisticated.

Sector 4: Cryptographic Weaknesses

1. Weak HMAC Secrets

• Description: If the server uses a symmetric algorithm (HS256/HS384/HS512), the security relies entirely on the strength of the secret. Attackers can brute-force weak secrets.
• Research Tip: Use tools like hashcat (-m 16500 for JWT) or jwt_tool to brute-force the secret if you have a valid JWT.

2. JWK (JSON Web Key) Injection

• Description: The JWT header can contain a jwk parameter to embed the public key directly. A flawed server might use this attacker-provided key to verify the signature instead of its own trusted keys.
• Research Tip: Generate an RSA key pair, place the public key in the jwk header, and sign the token with your private key.

3. “jku” (JWK Set URL) Header Injection

• Description: The jku header points to a URL where the server should fetch the keys for verification. An attacker can change this to a server they control, hosting their own public key. The server fetches the attacker’s key and uses it to verify the attacker’s token.
• Prerequisites: The server allows and fetches from arbitrary URLs provided in jku. It may only allow certain domains, which could be bypassed via open redirects or subdomain takeovers.

Research Methodology & Tooling

1. Information Gathering:

• Capture a valid JWT from the application (via Burp Suite, browser dev tools).
• Decode it using jwt.io or the command line to understand its structure, algorithm, and claims.

2. Manual Testing Checklist:

• Change the algorithm to none.
• Try algorithm confusion (RS256 -> HS256).
• Tamper with kid for path traversal, SQLi, etc.
• Modify critical claims (sub, user, role) and check if the signature is validated.
• Check if expired tokens are still accepted.
• Test for weak HMAC secrets.

3. Essential Tools:

• Burp Suite Extensions: “JWT Editor” is indispensable for manual testing and exploitation.
• Standalone Tools:
  • jwt_tool: The Swiss Army knife for JWT testing (https://github.com/ticarpi/jwt_tool).
  • jwt-heartbreaker: A script to check for the “none” algorithm and test secrets.
• Cracking:
  • hashcat (mode 16500) for brute-forcing HS256/384/512 secrets.
  • A custom wordlist with common JWT secrets (e.g., “secret”, “password”, “key”).

4. Advanced Research Areas:

• Logic Flaws in Multi-Step Flows: (e.g., OAuth 2.0 / OpenID Connect) where JWT is just one component.
• CVE Research: Follow CVEs for specific JWT libraries (e.g., jsonwebtoken for Node.js, pyjwt for Python, java-jwt). Many historic vulnerabilities were in the libraries themselves.
• Stateful vs. Stateless: Research the security implications of using stateless JWTs vs. stateful sessions. Statelessness makes instant logout impossible and can increase the impact of token theft.

JWT security is a process, not a feature. The “set-it-and-forget-it” mentality is a major source of vulnerabilities. Robust JWT implementation requires:

• Strict Algorithm Whitelisting: Only allow specific, strong algorithms (e.g., RS256, ES256). Never trust the alg header from the client.
• Comprehensive Claim Validation: Enforce checks on exp, nbf, iss, and aud.
• Sanitization of All Inputs: Treat header parameters like kid and jku as untrusted user input and sanitize them rigorously.
• Secure Secret Management: Use strong, randomly generated secrets for HMAC and protect private keys for RSA/ECDSA.