Los tokens web JSON (JWT) se han convertido en el método de autenticación preferido por muchas organizaciones. Son fáciles de implementar, lo que los convierte en una opción popular para proteger API y aplicaciones web. Sin embargo, si no se gestionan adecuadamente, los JWT pueden introducir vulnerabilidades de seguridad, poniendo en riesgo sus sistemas. Probablemente usted mismo los haya utilizado.
Pero, ¿los ha implantado y gestionado con seguridad?
Una entrada de blog de Akamai puso de relieve varias vulnerabilidades de seguridad comunes asociadas a las JWT. Fue una llamada de atención sobre los riesgos potenciales de una gestión inadecuada de los JWT. En esta entrada de blog, quiero seguir en esta línea, centrándome en una vulnerabilidad adicional que a menudo se pasa por alto: los JWT que no caducan. Veremos cómo surge este problema junto con las vulnerabilidades de seguridad asociadas. A continuación, ofreceré algunos consejos para que sepas cómo protegerte de estas vulnerabilidades de seguridad.
Descripción general de las vulnerabilidades JWT más comunes
Antes de entrar en materia, repasemos brevemente las vulnerabilidades de las JWT destacadas en la entrada del blog que he mencionado anteriormente. Las seis amenazas a las JWT que mencionaba el autor eran:
- Permitir que el servidor utilice un token sin validación: Esto puede ocurrir cuando el servidor no comprueba la integridad del token, facilitando a los atacantes su manipulación y explotación. Los atacantes también pueden establecer el algoritmo de verificación (alg) en ninguno, intentando manipular el servidor para que no valide el token en absoluto.
- Utilizar la misma clave privada para diferentes aplicaciones: Esta práctica puede comprometer múltiples aplicaciones si la clave queda expuesta.
- Utilizar un algoritmo de firma débil: Los algoritmos de firma débiles pueden descifrarse más fácilmente, lo que da lugar a accesos no autorizados.
- Elegir una clave privada corta y/o de baja entropía: Las claves demasiado cortas o carentes de aleatoriedad son más susceptibles a los ataques de fuerza bruta.
- Guardar información sensible en la carga útil de un JWT: La información sensible almacenada en la carga útil puede quedar expuesta si se intercepta el token.
- Confundir las claves: Una mala gestión de las claves puede conducir a una validación incorrecta, permitiendo accesos no autorizados.
Para obtener información detallada sobre estas vulnerabilidades, consulte la entrada del blog. A continuación, veamos una vulnerabilidad adicional: el JWT que no caduca.
Vulnerabilidad adicional: JWTs no expirados
Echemos un vistazo a la siguiente JWT, que se basa en un ejemplo del mundo real que me encontré no hace mucho tiempo:
Se trata de un JWT utilizado para autenticar y autorizar el acceso de un usuario a una API. Está firmado con un secreto seguro para evitar la suplantación. A primera vista, parece correcto. Pero veamos más de cerca la carga útil:
{ |
Cuando veas esa afirmación ttl, probablemente pienses en tiempo de vida, porque eso es lo que TTL típicamente significa. Entonces, esto probablemente tiene que ver con cuánto tiempo es válido el JWT. Este debe ser el tiempo de expiración.
Podemos hacer algunos cálculos sencillos. Tal vez 86.400.000 es el número de segundos, en cuyo caso el emisor pretende que este JWT sea válido durante 1000 días. O quizá se refieran a milisegundos, en cuyo caso pretenden que este JWT sea válido durante 1 día. Eso también podría tener sentido.
Pero aquí está el problema: La especificación JWT dice que el tiempo de expiración se especifica como exp, no ttl:
| La declaración "exp" (tiempo de expiración) identifica el tiempo de expiración en o después del cual el JWT NO DEBE ser aceptado para su procesamiento. El procesamiento de la reivindicación "exp" requiere que la fecha/hora actual sea anterior a la fecha/hora de expiración indicada en la reivindicación "exp". Los implementadores PUEDEN prever un pequeño margen de maniobra, normalmente no superior a unos minutos, para tener en cuenta las desviaciones del reloj. Su valor DEBE ser un número que contenga un valor NumericDate. El uso de esta declaración es OPCIONAL. |
Entonces, tenemos un par de problemas aquí.
En primer lugar, el emisor de este JWT está utilizando ttl para especificar la caducidad, pero ttl no es una instrucción JWT estándar. La mayoría de las bibliotecas diseñadas para manejar JWTs no reconocerán ttl como una instrucción relacionada con la expiración del token. Esto provocará problemas de compatibilidad, y lo más probable es que el token sea tratado como no caducado.
En segundo lugar, la alegación exp requiere una marca de tiempo real de expiración, no un número relativo de milisegundos (o segundos) desde la hora de emisión. Es probable que esta confusión se deba al uso de ttl en lugar de exp. No obstante, el emisor debe comprender el formato esperado para la solicitud de expiración a fin de garantizar la correcta expiración del token.
Tanto si olvidas establecer el tiempo de caducidad de un JWT como si lo estableces incorrectamente (como en nuestro ejemplo), tu JWT será tratado como no caducado. Y esto presenta un fallo de seguridad importante.
| Sin una caducidad adecuada, un JWT puede ser reutilizado por atacanteso filtrarse más allá de su vida útil prevista,aumentando el riesgo de acceso no autorizado. |
Mitigación de las vulnerabilidades de seguridad de JWT
Ahora que hemos cubierto las posibles vulnerabilidades de seguridad, la siguiente pregunta es: ¿qué debe hacer al respecto? Afortunadamente, mitigar esta vulnerabilidad es sencillo y directo.
Utilice siempre el reclamoexp. Establezca una fecha de caducidad para cada token que genere. Cuando lo hagas, asegúrate de utilizar la declaración exp estándar con el formato de valor esperado para garantizar que se ajusta a las especificaciones JWT y caduca según lo previsto.
Actualice aplicaciones y bibliotecas. Asegúrese de que su aplicación y las bibliotecas que utiliza están actualizadas y cumplen las normas JWT más recientes. Las actualizaciones periódicas ayudan a corregir vulnerabilidades de seguridad y mejorar la compatibilidad.
Eso es todo. Siga estas sencillas directrices y reducirá significativamente el riesgo de acceso no autorizado a través de una JWT que no caduca. Esto mejorará la seguridad general de sus implementaciones JWT.
Conclusión
Comprender y abordar las vulnerabilidades JWT es crucial para mantener la seguridad de sus aplicaciones. En este post, destacamos el riesgo de los tokens que no caducan. Utilizando correctamente el exp claim y manteniendo tus librerías actualizadas, puedes mitigar este riesgo de forma efectiva.
Para más soluciones de seguridad y mejores prácticas, explore los recursos disponibles en la documentación de Linode . Linode ofrece guías completas para ayudarle a eliminar las vulnerabilidades de seguridad de sus aplicaciones.
Comentarios