A propos Skills
Interactive Sandbox Web3 Engineering Security Lab Engineering Infrastructure Portfolio Audit Publications Changelog Veille Techno CTF Writeups Uses / Setup Blog Stats Now
Projets Contact

JWT Algorithm Confusion Explained

Comment les attaques par confusion d'algorithme JWT fonctionnent, scénario d'exploitation RS256 vs HS256, exemples de code et stratégies de mitigation.

Table des matières

    What is a JWT?

    JSON Web Tokens (JWT) are a compact, URL-safe means of representing claims to be transferred between two parties. A JWT consists of three Base64URL-encoded parts: Header, Payload, and Signature, separated by dots.

    The header specifies the algorithm used to sign the token (e.g., RS256, HS256), while the payload contains the claims (user ID, roles, expiration). The signature ensures integrity.

    The Algorithm Confusion Attack

    Algorithm confusion occurs when a server accepts a token signed with a different algorithm than intended. The most common scenario exploits the difference between RS256 (asymmetric, RSA) and HS256 (symmetric, HMAC-SHA256).

    If a server expects RS256 but doesn't enforce the algorithm, an attacker can sign a token with HS256 using the server's public key as the HMAC secret.

    Attack Scenario: RS256 to HS256

    The attack works as follows:

    1. The server normally uses RS256: signs with a private key, verifies with the public key
    2. The attacker obtains the server's public key (often exposed via /.well-known/jwks.json)
    3. The attacker crafts a token with "alg": "HS256" in the header
    4. Signs the token using the public key as the HMAC secret
    5. The server's JWT library sees HS256, uses the "verification key" (the public key) as the HMAC secret
    6. Signature matches — token is accepted with arbitrary claims
    exploit.py
    1import jwt
    2
    3# Server's public key (obtained from /jwks.json)
    4public_key = open('server_public.pem').read()
    5
    6# Forge token with HS256 using public key as secret
    7forged = jwt.encode(
    8 {"sub": "admin", "role": "superadmin"},
    9 public_key,
    10 algorithm="HS256"
    11)

    Why Libraries Are Vulnerable

    Many JWT libraries accept the algorithm specified in the token header rather than enforcing a server-side whitelist. When a library sees HS256, it uses the provided verification key as an HMAC secret — but that key is the RSA public key, which is publicly known.

    Mitigation Strategies

    • Always enforce the algorithm server-side: pass algorithms=["RS256"] explicitly
    • Never trust the alg header from the token
    • Use separate key objects for RSA and HMAC (different types prevent confusion)
    • Reject tokens with alg: "none"
    • Keep JWT libraries updated (most modern libraries have fixed this)
    • Use kid (Key ID) to explicitly map to the correct key and algorithm

    Real-World Impact

    This vulnerability class has affected major platforms and frameworks. Auth0, Azure AD, and several open-source JWT libraries have all had algorithm confusion bugs. The root cause is always the same: trusting client-provided metadata for security-critical operations.

    Partager cet article

    Commentaires

    Les commentaires utilisent GitHub Discussions via Giscus. Connectez-vous avec GitHub pour participer.

    Activez Giscus sur votre repo GitHub pour afficher les commentaires.