No es de extrañar que la autenticación rota haya entrado en la lista de problemas de API de OWASP: los mecanismos de autenticación son notoriamente difíciles de implementar correctamente. Además, los atacantes tienen un poco de ventaja porque, por su propia naturaleza, la mayoría de los desafíos de autenticación deben ser expuestos a los usuarios, lo que da a los atacantes la oportunidad de estudiarlos y buscar patrones o vulnerabilidades que puedan explotar.

Por último, dado que la autenticación suele actuar como puerta de entrada tanto a una aplicación como potencialmente al resto de una red, son objetivos tentadores para los atacantes. Si un proceso de autenticación está roto o es vulnerable, hay muchas posibilidades de que los atacantes descubran esa debilidad y la exploten.

Así que, en este capítulo, vamos a aprender a dejar fuera a los malos cuando se trata de problemas de autenticación. Si quieres poner a prueba tus habilidades primero, dirígete a nuestro desafío gamificado:

¿Quieres mejorar tu puntuación? Quédate conmigo mientras lo desglosamos.

¿Cuáles son algunos ejemplos de autenticación rota o mal configurada?

Un ejemplo en el que el problema puede no ser tan obvio es cuando un método de autenticación es vulnerable al relleno de credenciales, o al uso de listas de nombres de usuario y contraseñas conocidas para romper la seguridad. Incluso un método de autorización normalmente muy seguro, como la autenticación multifactor, puede ser vulnerable si las solicitudes no están limitadas, estranguladas o supervisadas de alguna manera.

Por ejemplo, un atacante podría activar una solicitud de recuperación de contraseña enviando una solicitud POST a /api/sistema/códigos de verificación y proporcionando un nombre de usuario en el cuerpo de la solicitud. Si una aplicación utiliza un desafío por mensaje de texto SMS en el que se envía un código de seis dígitos al teléfono del usuario, pero el campo de entrada no está limitado, la aplicación puede ser vulnerada en pocos minutos. Un atacante sólo tiene que enviar todas las combinaciones posibles de seis dígitos a la aplicación hasta dar con la correcta.

En ese escenario, a primera vista, parece que tener una autenticación de dos factores mantendrá una aplicación segura. Pero como la entrada del usuario no está limitada por la tasa, la autenticación está rota y es vulnerable.

En otro ejemplo, una aplicación podría utilizar objetos de usuario codificados como cookies de autenticación. Pero si un atacante con acceso de usuario de bajo nivel decodifica esa cookie usando Base64, podría descubrir cómo la cookie define sesiones y usuarios a la aplicación. Por ejemplo, podrían ver el siguiente JSON una vez decodificado:

{
"username" : "ShadyGuy",
"role" : "user"
{

En ese momento, el usuario malicioso podría cambiar su nombre de usuario, su rol o ambos. Podrían convertirse en otro usuario con un nivel de privilegio superior cambiando un par de valores:

{
"username" : "GoodGuy",
"role" : "admin"
{

En ese momento, si el atacante recodifica la información y la establece como valor de la cookie, se convierte esencialmente en el nuevo usuario con un nivel de permiso más alto. A menos que existan métodos para evitar un cambio como ese, hay muchas posibilidades de que la aplicación acepte la transformación.

Eliminación de la autenticación rota o mal configurada

Si la autenticación falla, hay muchas posibilidades de que la seguridad en todo el tablero se vea comprometida. Pero seguir algunas pautas importantes mientras se codifican las aplicaciones puede ayudar a mantener todo seguro.

En primer lugar, asegúrate de incluir comprobaciones de autenticación en todos los lugares que permitan a los usuarios acceder a la funcionalidad del programa. Si la comprobación de autenticación no existe en absoluto, la batalla está perdida desde el principio.

En términos de mejores prácticas, una buena cosa a tener en cuenta es evitar exponer los IDs de sesión en la URL que es accesible a los usuarios. En el segundo ejemplo anterior sobre la autenticación rota, evitar que un atacante intente descifrar la cookie de sesión es mucho más fácil si nunca está expuesta a ellos.

También es una buena idea implementar la autenticación multifactor. Esto se puede hacer de forma segura utilizando tokens de hardware que generan algoritmos de contraseñas en horarios ajustados. Si no puedes proporcionar a tus usuarios dispositivos de este tipo, los mensajes de texto SMS también pueden funcionar. Pero hay que asegurarse de que las solicitudes de los usuarios se limiten a algo razonable, como tres o cuatro intentos en un periodo de 30 segundos, y que los códigos expiren todos juntos después de unos pocos minutos. El uso de un código alfanumérico también puede mejorar la seguridad al añadir letras y números a las posibles contraseñas.

Por último, si es posible, evite depender de nombres de usuario o valores secuenciales predecibles como ID de sesión. En su lugar, utiliza un gestor de sesiones seguro del lado del servidor que genere un ID de sesión aleatorio cada vez.

Implementar métodos de autenticación seguros es un poco más complicado que combatir la vulnerabilidad promedio. Pero como la autorización es tan importante para todas las aplicaciones, programas y API, vale la pena tomarse un tiempo extra para asegurarse de hacerlo bien.

Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.