Caso Real: Cómo una Vulnerabilidad JWT Permitió el Robo Total de Cuentas
Mientras realizaba pruebas de seguridad en example.com a través de la plataforma HackerOne, descubrí una vulnerabilidad crítica relacionada con los JSON Web Tokens (JWT) que se enviaban en las URLs. Este fallo, sorprendentemente simple, me permitió tomar el control total de la cuenta de cualquier usuario.
A continuación, te guiaré a través del proceso de descubrimiento y explotación, y compartiré las lecciones que todos podemos aprender de este incidente.
🔍 Descubrimiento Inicial: La Pista en la URL
Todo comenzó después de registrar una cuenta nueva. Durante el proceso de confirmación de correo electrónico, noté algo muy inusual: la aplicación enviaba un token JWT directamente en la URL de confirmación.
https://id.example.xy/example/sign-up/confirm?token=<JWT_TOKEN>
Esto captó mi atención de inmediato. Exponer tokens en las URLs es una práctica extremadamente peligrosa, ya que pueden filtrarse fácilmente a través del historial del navegador, las cabeceras Referrer al navegar a otros sitios, o quedar registrados en logs de servidores y firewalls.
🔓 Decodificando el Token: Una Sorpresa Peligrosa
Mi siguiente paso fue copiar ese token y pegarlo en jwt.io, una herramienta online para decodificar JWT. Lo que vi en la sección «Payload» (la carga útil del token) fue alarmante: contenía mi correo electrónico y mi contraseña en texto plano.
{
"email": "me@example.com",
"password": "myplaintextpassword"
}
Este hallazgo significaba tres cosas muy graves:
El JWT no estaba cifrado, simplemente estaba codificado en Base64. Cualquiera puede decodificar Base64.
El token incluía credenciales de usuario altamente sensibles, como la contraseña.
Cualquier persona o sistema con acceso a la URL (logs, un administrador de red, etc.) podía extraer estas credenciales sin ningún esfuerzo.
🕵️ Reconocimiento y Explotación: El Robo de la Cuenta
Después de unas 5 horas de reconocimiento, encontré varios de estos tokens JWT filtrados en fuentes públicas. Probablemente fueron compartidos accidentalmente o registrados por algún servicio de terceros que el sitio utilizaba.
Decodifiqué algunos de esos tokens filtrados y, efectivamente, contenían credenciales válidas (email y contraseña) de otros usuarios. Usé uno de esos pares de credenciales para iniciar sesión en la cuenta de una víctima. Para mi sorpresa, pude cambiar la contraseña del usuario con un solo clic, sin necesidad de confirmar la contraseña antigua.
Esto confirmaba el impacto más alto posible: Account Takeover o robo total de la cuenta.
⚠️ El Reporte a HackerOne
Inmediatamente, redacté un informe detallado con una prueba de concepto clara y lo envié al programa a través de HackerOne. Sin embargo, mi reporte fue cerrado como duplicado, haciendo referencia a un informe anterior del 22 de diciembre de 2023.
😱 Una Reflexión Inquietante
Lo más impactante de todo es que esta vulnerabilidad fue reportada por primera vez en 2023 y seguía sin resolverse cuando el programa se relanzó en 2025. Esto significa que las cuentas de los usuarios estuvieron expuestas durante un período de tiempo considerable debido a una cadena de malas prácticas:
Tokens JWT almacenados de forma insegura en las URLs.
Credenciales en texto plano dentro del payload de los JWT.
Prácticas de seguridad de cuenta deficientes (como permitir el cambio de contraseña sin verificación).
🔐 Lecciones Clave de Seguridad (Takeaways)
Esta vulnerabilidad resalta varias lecciones de seguridad fundamentales que todo equipo de desarrollo debería tener presentes:
Nunca incluyas datos sensibles como contraseñas en un JWT. Y mucho menos si ese JWT va a viajar en una URL.
Cifra siempre el payload de un JWT (usando JWE) si contiene información sensible, en lugar de solo codificarlo en Base64 (que es el comportamiento por defecto de JWS).
Exige siempre la verificación de la contraseña actual antes de permitir que un usuario establezca una nueva.
Monitorea la posible fuga de tokens a través del historial del navegador, logs del servidor y las cabeceras
Referrer.Los responsables de los programas de seguridad deben priorizar la solución de fallos críticos de autenticación de inmediato, incluso si han sido reportados previamente.
✅ Pensamientos Finales
Aunque mi informe fue marcado como duplicado, la persistencia de esta vulnerabilidad demuestra cómo incluso los errores ya conocidos pueden pasar desapercibidos o ser despriorizados, con graves consecuencias.
Si eres desarrollador: Toma esto como un recordatorio para auditar regularmente tus flujos de autenticación, especialmente aquellos que utilizan JWT.
Si eres un cazador de recompensas (bug bounty hunter): Sigue investigando. A veces, un informe duplicado sigue siendo valioso, especialmente si el fallo resurge en nuevas áreas de la aplicación o te permite descubrir nuevas formas de abuso.
Este caso de estudio fue documentado originalmente por Umanhonlen. Puedes conectar con él en LinkedIn o X (Twitter).
