Lab Web: JWT sin firma robusta

Contexto

Objetivo de laboratorio: entender como una mala validacion de JWT puede convertir una cuenta normal en acceso administrativo. No es una guia contra un objetivo real; el flujo esta pensado para entornos CTF y pruebas autorizadas.

Reconocimiento

Primero levanto superficie HTTP y tecnologias:

nmap -sC -sV -p- 10.10.10.10
whatweb http://10.10.10.10
ffuf -u http://10.10.10.10/FUZZ -w /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt

La aplicacion expone login, perfil y un endpoint /api/me. Tras autenticar como usuario basico aparece una cookie session.

Analisis del token

El token tiene tres segmentos y decodifica como JWT. El payload incluye role: "user" y un identificador interno.

python3 - <<'PY'
import base64, json
token = "HEADER.PAYLOAD.SIGNATURE"
payload = token.split(".")[1] + "=="
print(json.dumps(json.loads(base64.urlsafe_b64decode(payload)), indent=2))
PY

La comprobacion importante no es si se puede leer el token, sino si el servidor valida la firma y los claims criticos.

Validacion controlada

Modifico solo un claim en entorno de laboratorio y observo la respuesta. Si el servidor acepta role: "admin" sin rechazar la firma, el fallo esta confirmado.

{
  "user": "amis13",
  "role": "admin"
}

Impacto

Con el rol alterado aparece /admin, que permite leer un secreto de laboratorio. En un reporte real, el impacto se escribiria como fallo de autorizacion y validacion criptografica, no como “JWT roto” sin contexto.

Fix

Las defensas minimas:

• Firmar con algoritmo fuerte y clave fuera del repositorio.
• Rechazar alg: none y no confiar en claims editables por cliente.
• Validar autorizacion en servidor para cada accion sensible.
• Rotar sesiones despues de cambios de privilegio.

Lecciones

Los JWT no son estado de confianza por si mismos. Son contenedores firmados. Si la verificacion falla, todo el modelo de roles cae con ellos.

- EOF -

<< back_to_index