Step‑by‑Step Guide to Exploiting JWT Vulnerabilities

1. JWT Overview and Use Cases

JSON Web Token (JWT) is widely used for authentication in web applications, APIs, and single‑page apps. Typical scenarios include refresh tokens, password‑reset or email‑verification tokens, shared/invitation links, and temporary access keys for data objects.

2. JWT Structure

JWT consists of three Base64‑url‑encoded parts: Header, Payload, and Signature.

2.1 Header

The Header carries metadata such as the signing algorithm (e.g., HS256, RS256), token type, and optional identifiers like kid.

2.2 Payload

The Payload holds the claims required by the application. Best practice advises against placing sensitive data (e.g., PII) unless the token is encrypted (JWE).

2.3 Signature

The Signature guarantees integrity; without the signing key the token cannot be altered.

3. None Algorithm Attack

When developers enable the none algorithm, the token can be issued without a signature, often for testing. In production, an attacker can decode the Header and Payload, set alg to none, modify claims (e.g., change role to owner and swap organizationId), and omit the signature, thereby impersonating any organization owner.

4. Missing Signature Verification Attack

Some implementations skip signature verification entirely, treating unsigned tokens as valid. An attacker can remove the signature, alter claims, and send only the Header and Payload, gaining elevated privileges or triggering injection attacks.

5. Algorithm/Key Confusion Attack

If a server supports algorithms beyond the default, an attacker can change alg to a different algorithm (e.g., HS256) and sign the modified Payload with the server’s public key, effectively forging a valid token.

6. Parsing Vulnerability (CVE‑2018‑0114)

The node‑jose library allows an attacker to supply a custom jwk object in the Header, causing the library to verify the token with the attacker‑controlled key pair. Example Header:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "example-key-id",
  "jwk": {
    "kty": "RSA",
    "kid": "example-key-id",
    "use": "sig",
    "n": "uAPuSn1MG6nFYKjiIcfke-nyMfsZM_Wrea7wlv1l553UrUM8P9VjZ0kTKYX3iyWLDXgyokLsZtqicE5q3c71cQ",
    "e": "AQAB"
  }
}

Attackers must generate a matching key pair and encode the n and e values accordingly.

7. kid Injection Attacks

Improper handling of the kid attribute can lead to path‑traversal, SSRF, or SQL/NoSQL injection.

7.1 Path Traversal via kid

Vulnerable code concatenates the kid value directly into a file‑read operation. Supplying a payload such as "../../../dev/null" forces the application to load an attacker‑controlled file as the signing key.

{
  "alg": "RS256",
  "kid": "../../../dev/null"
}

7.2 SQL Injection via kid

If the kid value is interpolated into an unprepared SQL query, an attacker can inject a payload like "example-key' OR UNION SELECT 'intigriti'; --" to replace the original signing key.

{
  "alg": "RS256",
  "kid": "example-key' OR UNION SELECT 'intigriti'; --"
}

8. Weak Key Brute‑Forcing

When JWTs are signed with weak or commonly used keys, tools such as John the Ripper or jwt_tool can brute‑force the secret. Example command:

$ john --wordlist=/path/to/wordlist.txt jwt.txt

Keys sometimes leak into public repositories or client‑side JavaScript, exposing them to attackers.

9. Conclusion

JWT vulnerabilities stem from misconfiguration, ignored best practices, and library parsing bugs. The article demonstrates several attack vectors—None algorithm, missing signature verification, algorithm/key confusion, CVE‑2018‑0114, kid injection, and weak‑key cracking—providing concrete steps and code snippets for each.