JWT Forgery (Leaked Secret)

Un JSON Web Token (JWT) firmado con HMAC (HS256) protege su integridad con una única clave secreta compartida entre quien lo emite y quien lo verifica. Si esa clave se filtra, la garantía desaparece por completo: el atacante puede fabricar tokens arbitrarios (cambiar el usuario, poner is_admin:true, añadir claims) y firmarlos con la clave robada, y el servidor los aceptará como legítimos. Es la diferencia entre un JWT como prueba de identidad y un JWT como simple texto firmado con un secreto que ya no es secreto.

De dónde sale la clave. Casi siempre de un descuido: la clave en el repositorio o en un fichero de configuración (config.py, settings.py, .env) que el atacante llega a leer mediante un LFI, una fuga de código fuente o un secreto en el historial de git. Claves cortas o por defecto también caen a fuerza bruta (hashcat -m 16500).

Cómo se forja. La herramienta de referencia es jwt_tool:

python3 jwt_tool.py '<jwt_original>' -T -S hs256 -p '<leaked-key>'

El modo tamper (-T) permite editar el payload (por ejemplo, añadir "debug": true o subir un role) y -S hs256 -p lo vuelve a firmar con la clave correcta. El token resultante pasa cualquier verificación de firma del servidor.

Relación con alg:none. Es un ataque distinto pero del mismo árbol: en alg:none se anula la firma porque el servidor no la valida; aquí la firma sí se valida, pero el atacante conoce la clave y firma él mismo. La defensa es común: validar el algoritmo esperado y, sobre todo, proteger la clave.

Cómo detectarlo. Un token forjado con la clave correcta pasa la verificación de firma, así que no genera errores: la detección está en el contenido y en la coherencia. Del lado del servidor, una regla útil compara los claims del token contra el estado real: un role/is_admin que no coincide con los permisos que la base de datos tiene para ese usuario, o un token de administrador para una cuenta que nunca lo fue, es la señal. Un mismo sub reutilizado desde IPs dispares, o un iat/exp fuera de las ventanas que emite el servidor, también apuntan a forja. La causa raíz sí es detectable de forma proactiva: buscar la clave HMAC en el código y el historial de git (ver credenciales en el código fuente) la encuentra antes que el atacante.

Defensa. No incrustar la clave en el código ni en ficheros legibles; usar variables de entorno o un gestor de secretos; rotar la clave si se sospecha filtración; preferir algoritmos asimétricos (RS256), donde el verificador solo necesita la clave pública, de modo que filtrarla no permite forjar. Relacionado con JWT e credenciales en el código fuente.