Vulnerabilidades de JWT: alg=none y confusión de claves

Los JWT están firmados criptográficamente, pero muchas bibliotecas tuvieron vulnerabilidades graves. Las más explotadas son: el ataque alg=none, el ataque de confusión RS256→HS256 y la fuerza bruta contra secretos débiles. Todas se deben a confiar en campos del encabezado controlados por el atacante.

La especificación de JWT permite alg:"none" para tokens no protegidos. Las bibliotecas defectuosas aceptaban esta opción y omitían por completo la verificación de la firma. Un atacante modifica la carga útil (por ejemplo, "role":"admin"), establece alg:"none", elimina la firma y el servidor lo acepta.

Original: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG Ataque: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (firma vacía, punto final). Un servidor vulnerable verifica correctamente el token y concede acceso de administrador.

Nunca acepte alg:"none" en producción. Incluya explícitamente en una lista blanca los algoritmos permitidos: jwt.decode(token, key, algorithms=["HS256"]). La mayoría de las bibliotecas modernas (PyJWT 2+, jsonwebtoken 9+) rechazan alg=none de forma predeterminada.

Si un servidor usa RS256 y un cliente cambia alg a HS256, el servidor podría verificar usando su clave pública RSA como secreto HMAC. Dado que la clave pública es... pública, el atacante firma cargas útiles arbitrarias con ella y el servidor las verifica.

Pasos: 1) Obtenga la clave pública desde el endpoint JWKS. 2) Cree una carga útil maliciosa. 3) Fírmela con HMAC-SHA256 usando los bytes PEM sin modificar de la clave pública como secreto HMAC. 4) Establezca alg:"HS256" en el encabezado. 5) La ruta HS256 del servidor verifica correctamente el token.

Especifique siempre el algoritmo esperado explícitamente en la llamada de verificación. Nunca derive el algoritmo del encabezado del token. Use rutas de código separadas para RS256 y HS256 que el llamador no pueda intercambiar.

HS256 con secretos débiles (menos de 256 bits de entropía) puede atacarse mediante fuerza bruta sin conexión. Herramientas como hashcat permiten descifrar JWT: hashcat -a 0 -m 16500 token.txt wordlist.txt. Use secretos criptográficamente aleatorios de al menos 32 bytes.

El encabezado kid (identificador de clave) selecciona qué clave se debe usar. Si el servidor utiliza kid como parámetro de una consulta SQL o como ruta del sistema de archivos sin sanitizarlo: kid="../../dev/null" → HMAC con una clave vacía → se acepta el token falsificado. Sanitize siempre kid.

El encabezado jwk incluye una clave pública para la verificación. Un servidor vulnerable podría usar directamente la clave incluida, lo que permitiría al atacante proporcionar su propio par de claves, firmar el token con la clave privada e incluir la clave pública. Verifique únicamente contra claves registradas.

Algunas implementaciones olvidaron comprobar la declaración exp o usaron la hora del servidor de forma incoherente. Valide siempre explícitamente exp, nbf e iat. Use una biblioteca que compruebe estas declaraciones de forma predeterminada y nunca desactive la validación de declaraciones en producción.

En el ataque de confusión de claves RS256→HS256, ¿qué utiliza el atacante como secreto HMAC?

Las vulnerabilidades de JWT surgen de confiar en el encabezado alg, aceptar alg=none y usar secretos débiles. Solución: fije los algoritmos en el verificador, use secretos robustos y sanee kid. Siguiente: prácticas para implementar JWT de forma segura.