Los JSON Web Tokens se han convertido en el estándar de facto para la autenticación y autorización en aplicaciones modernas. Sin embargo, su aparente simplicidad esconde múltiples vulnerabilidades que, explotadas de forma correcta, pueden terminar comprometiendo por completo la seguridad de un sistema. En Q2BSTUDIO, como empresa especializada en aplicaciones a medida, hemos auditado decenas de proyectos donde la implementación de JWT presentaba fallos críticos, a menudo pasados por alto incluso por equipos con experiencia. Este artículo analiza tres vectores de ataque clásicos y, lo más importante, revela la única regla defensiva que los bloquea a todos. Además, veremos cómo esta regla se integra de forma natural en arquitecturas cloud (AWS/Azure), soluciones de BI con Power BI y sistemas con agentes de IA.
Antes de entrar en materia, conviene recordar que un JWT está compuesto por tres partes codificadas en base64url: el header, el payload y la firma. El header especifica el algoritmo usado para firmar; el payload contiene las reclamaciones (como el rol del usuario); y la firma se calcula sobre las dos primeras partes. Cualquiera que posea el token puede leer el payload, porque solo está codificado, no cifrado. Este hecho, sumado a una verificación delegada al propio token, da pie a los ataques que describiremos.
Ataque 1: Algoritmo 'none'El primer ataque es casi insultante por su simpleza. Si el servidor confía en el algoritmo declarado en el header, un atacante puede modificar el token para que indique 'alg':'none', alterar el payload con privilegios de administrador y eliminar la firma. El servidor, si no valida explícitamente que el algoritmo sea seguro, aceptará el token como auténtico. Este fallo, documentado en CVE-2015-9235 para la librería jsonwebtoken de Node.js, afectó a muchas implementaciones por defecto. En proyectos de ciberseguridad que hemos revisado en Q2BSTUDIO, encontramos que incluso equipos que usaban frameworks modernos olvidaban configurar una lista blanca de algoritmos, dejando la puerta abierta a este vector.
Ataque 2: Secreto débil (offline brute force)Los algoritmos HS256, HS384 y HS512 usan HMAC con una clave secreta compartida. Si esa clave ha sido elegida por un humano (como 'secret' o 'changeme'), un atacante puede descargar un diccionario como rockyou.txt y probar cada candidato contra el token original, sin necesidad de interactuar con el servidor. No hay límite de intentos ni bloqueo de cuenta. Una vez hallada la clave, el atacante puede firmar cualquier token. La solución es usar claves generadas por un generador criptográfico seguro (CSPRNG) de al menos 256 bits. En las soluciones cloud (AWS/Azure) que desarrollamos en Q2BSTUDIO, recomendamos almacenar estas claves en servicios gestionados como AWS Secrets Manager o Azure Key Vault, y rotarlas periódicamente.
Ataque 3: Confusión de algoritmos (RS256 a HS256)Este ataque es más sofisticado y aprovecha que el servidor confía en el algoritmo del header. Si el servidor usa RS256 (firma asimétrica con clave privada y verificación con clave pública), el atacante cambia el algoritmo a HS256. Entonces el servidor usará la clave pública (que es, por definición, pública) como clave HMAC para verificar. El atacante descarga esa clave pública, firma un token falso con HS256 usando los bytes de la clave pública como secreto, y el servidor lo acepta. Un detalle sutil es que los saltos de línea al final del archivo PEM pueden cambiar el resultado. Por eso, al auditar tokens, es importante probar variantes. En Q2BSTUDIO, cuando implementamos sistemas con agentes IA que intercambian tokens entre microservicios, aseguramos que la verificación no delegue la elección del algoritmo al token entrante.
La única regla que los detiene a todosLos tres ataques comparten una misma raíz: confiar en los datos del propio token para decidir cómo verificarlo. La solución es sencilla y se implementa en una línea de código: fijar en el servidor una lista blanca de algoritmos aceptados y rechazar cualquier otro, incluyendo 'none'. Por ejemplo:
ALLOWED = {'RS256'}claims = jwt.decode(token, public_key, algorithms=list(ALLOWED))
Ese único argumento algorithms elimina de golpe el ataque del algoritmo 'none' y el de confusión RS/HS. Combinado con una clave secreta robusta (para HS256) o un par de claves asimétricas bien gestionadas, se cierra la tercera puerta. Además, conviene establecer expiraciones cortas, no incluir datos sensibles en el payload (recordemos que está solo codificado) y auditar periódicamente los tokens en producción.
En Q2BSTUDIO, aplicamos esta regla en todos nuestros desarrollos, ya sea en aplicaciones a medida, en soluciones de BI con Power BI que autentican mediante tokens, o en arquitecturas cloud con AWS o Azure donde los servicios se comunican mediante JWT. La cultura de seguridad no es un añadido, sino un pilar del diseño. Nuestros equipos de ciberseguridad realizan auditorías de tokens como parte integral del proceso de pentesting, y formamos a los desarrolladores para que no dependan de configuraciones por defecto.
Recomendamos a cualquier organización que utilice JWT que revise sus tokens con herramientas como jwt-auditor (open source y offline). Basta con ejecutar jwt-auditor audit <token> para detectar si el algoritmo es inseguro, si la clave es adivinable o si el token verifica con la clave pública como HMAC. Veinte segundos de comprobación pueden ahorrar un incidente de seguridad mayúsculo.
Los ataques descritos no son nuevos, pero siguen siendo efectivos porque muchos equipos asumen que el propio token se verifica a sí mismo. La realidad es que la seguridad de un JWT depende enteramente de cómo el servidor lo valida. Adoptar la regla de no delegar la elección del algoritmo es el primer paso hacia una autenticación robusta. En Q2BSTUDIO, ayudamos a las empresas a construir sistemas seguros desde el diseño, integrando ciberseguridad, inteligencia artificial y cloud de forma coherente. Si tu organización utiliza JWT, no esperes a que un atacante te demuestre lo vulnerables que son.
