The none Algorithm: Forging a JWT a Server Accepts Without a Signature
O desafio
Esta API autentica você a partir das claims dentro do seu JWT. O cabeçalho diz alg:HS256, mas o servidor tem uma falha clássica: ele também aceita um token cujo cabeçalho diz alg:none, tratando-o como já válido, sem assinatura a verificar. Na bancada, troque o algoritmo do cabeçalho para none e reescreva o payload para que role vire admin. O token se reconstrói ao vivo. Copie o token forjado inteiro e envie.
O que você vai aprender
- Understand what the JWT header alg field controls
- Explain why honouring alg:none disables signature verification
- Forge an admin token by switching the algorithm to none and editing the payload
- Recognise alg:none acceptance as a critical authentication bypass
- Know that a server must pin the expected algorithm rather than trust the token's header
Habilidades testadas
Pré-requisitos
- A JWT is three base64url parts: header, payload, signature
- Claims like role and user live in the payload
- Basic JSON editing
Como funciona
A JSON Web Token carries an algorithm name in its header, for example {"alg":"HS256","typ":"JWT"}. The intent is that the server reads alg, then verifies the signature with that algorithm and a secret key. The fatal mistake some implementations make is to trust the attacker-controlled header to choose the algorithm. If the header says alg:none and the library honours it, the server treats the token as legitimately unsigned and performs no verification at all.
That turns the JWT into a plain, editable list of claims. Because nothing checks the signature, you can rewrite any claim you like. Here the access decision is the role claim, so you switch the header to {"alg":"none","typ":"JWT"} and change "role":"user" to "role":"admin". The workbench re-encodes both segments and rebuilds the token. The third (signature) segment no longer matters; an alg:none token is commonly sent with an empty signature, which is why a trailing dot with nothing after it is also accepted.
The whole class of bug exists because the algorithm should be a server-side decision, never something the caller can downgrade. Pin it.
Erros comuns
- Only editing the payload. If you leave the header as HS256, the original signature is now wrong - this attack needs the header switched to
noneso the server skips the check. - Trying to compute a real signature. The point of
alg:noneis that you do not need one; do not waste time forging a valid HMAC. - Changing the wrong claim. Access here is decided by
role; set it toadmin, notuserorsub. - Submitting the decoded JSON. Submit the rebuilt, re-encoded token (or its admin payload segment), not the human-readable claims.
Como se proteger
Never let the token's own header decide whether or how to verify it. The server must choose the algorithm and reject anything that disables verification.
- Pin the expected algorithm server-side and reject
alg:none(and any unexpected alg) outright before processing claims. - Use a vetted library version and pass the algorithm explicitly to the verify call; never rely on the library's default to read alg from the token.
- Derive authorization only from claims on a token whose signature has been verified with the correct key.
- Prefer short-lived tokens and, for sensitive roles, server-side session checks so one forged token is not total compromise.