Laboratorio de ataque y defensa de JWT
Construye y rompe JSON Web Tokens con Web Crypto real: falsifica tokens alg:none, descifra secretos HMAC débiles con diccionario y logra la confusión de claves HS/RS.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
Casi todas las roturas de JWT tienen la misma causa de fondo: el verificador confía en algo que controla el atacante (el alg de la cabecera, la pista de clave kid) o en un secreto de firma tan débil que se puede adivinar. Este laboratorio ejecuta lo real: HS256 (HMAC-SHA256), RS256 (RSASSA-PKCS1-v1_5) y ES256 (ECDSA P-256) con la API Web Crypto de tu navegador, sin servidor y sin simulaciones. Un banco de trabajo en directo firma un JWT con un secreto compartido, lo decodifica y muestra cómo la firma falla en cuanto manipulas el token o la clave. Después ejecutas los ataques evaluados: falsificas un token alg:none que acepta un servidor laxo, descifras con diccionario un secreto HMAC débil y emites un token de administrador, y sustituyes RS256 por HS256 firmando con la clave pública. Cada ronda te califica dos veces: identificar bien el exploit y elegir el bastionado correcto del lado del servidor (fijar el algoritmo, usar un secreto aleatorio fuerte, validar las claims, usar una lista de kid permitidos). Los niveles de dificultad añaden casos más sutiles: listas de palabras más largas, inyección en la cabecera kid y casos límite de nbf/exp. Es un laboratorio Pro: con una cuenta gratuita tienes 3 usos de herramientas Pro en total y después necesitas Pro.
- Usa el banco de trabajo para firmar un JWT HS256, decodificarlo y ver cómo falla la firma al manipularlo.
- Ejecuta cada ataque evaluado: alg:none, secreto HMAC débil y confusión de claves HS/RS.
- Nombra el exploit y elige el bastionado correcto del lado del servidor.
- Sube de nivel para la inyección en kid y los casos límite de nbf/exp.
Preguntas frecuentes
¿Qué es el laboratorio de ataque y defensa de JWT?
Un ejercicio en el navegador que enseña la seguridad de los JSON Web Tokens haciéndote atacar tokens reales y después corregir el verificador. Un banco de trabajo firma y verifica tokens HS256 con la API Web Crypto, y una partida evaluada recorre las roturas clásicas de JWT (el truco alg:none, un secreto HMAC que se puede descifrar por fuerza bruta, la sustitución de algoritmo HS/RS o confusión de claves, la falta de validación de claims y la inyección en la cabecera kid), cada una demostrada con criptografía real y emparejada con el bastionado correcto del lado del servidor. Sin subir nada ni instalar nada.
¿Es criptografía real o una simulación?
Real. Las firmas y verificaciones HS256 usan HMAC de crypto.subtle sobre SHA-256; la ronda de confusión de claves genera un par de claves RSA real y verifica RS256 con él, además de un par de claves ECDSA P-256 para ES256; el ataque de diccionario recalcula un HMAC real para cada secreto candidato. Las cabeceras y los payloads de los tokens se codifican en base64url exactamente como exige la especificación JWT. Nada se falsea ni se precalcula en un servidor: todo se ejecuta localmente en tu navegador.
¿Qué es el ataque alg:none y cómo se detiene?
A un verificador que lee el algoritmo de la cabecera del token se le puede entregar un token con la cabecera {"alg":"none"} y una firma vacía. Si trata «none» como «ya es de confianza», acepta un token que cualquiera puede emitir. La corrección es decidir el algoritmo esperado en el servidor (por ejemplo, HS256) y rechazar cualquier token cuyo alg sea distinto: nunca aceptar «none». El alg de la cabecera es una entrada controlada por el atacante, no una instrucción.
¿Qué es la confusión de claves HS/RS?
Cuando una librería deja que la cabecera del token elija entre verificación simétrica (HS256) y asimétrica (RS256) con la misma clave configurada, un atacante cambia el alg a HS256 y firma el token falsificado usando la clave pública RSA como secreto HMAC: un valor que tiene legítimamente, porque es pública. El servidor verifica el HMAC con esa misma clave pública y cae en el engaño. La defensa es fijar el algoritmo por clave fuera de banda: una clave de verificación RSA solo debe verificar RS256.
¿Por qué validar las claims si la firma es válida?
Una firma demuestra integridad y origen; no dice nada sobre si el token sigue siendo válido, si está destinado a tu servicio o si procede de un emisor de confianza. Un verificador debe comprobar por su cuenta exp y nbf frente al reloj, confirmar que aud coincide con esta API y confirmar que iss es una autoridad de confianza. Saltarse esas comprobaciones convierte un único token filtrado o mal emitido en una puerta trasera permanente, que es lo que demuestra la ronda de higiene de claims.
¿Es gratis?
No, es un laboratorio Pro. Con una cuenta gratuita tienes 3 usos de prueba de herramientas Pro en total; después necesitas Pro.