Serie OWASP Top 10 API: Coders Conquer Security - Autenticación rota

No es de extrañar que la autenticación rota aparezca 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 una pequeña ventaja porque, por su propia naturaleza, la mayoría de los desafíos de autenticación deben estar expuestos a los usuarios, lo que les da 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 probabilidades de que los atacantes descubran esa debilidad y la exploten.

Así que, en este capítulo, aprenderemos a cerrarles el paso a los atacantes 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 analizamos los detalles.

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

Un ejemplo donde el problema podría no ser tan obvio es cuando un método de autenticación es vulnerable al relleno de credenciales (credential stuffing), o al uso de listas de nombres de usuario y contraseñas conocidos para vulnerar la seguridad. Incluso un método de autorización normalmente muy seguro, como la autenticación multifactor, podría ser vulnerable si las solicitudes no están limitadas, restringidas o supervisadas de alguna otra manera.

Por ejemplo, un atacante podría activar una solicitud de recuperación de contraseña enviando una solicitud POST a /api/system/verification-codes y proporcionando un nombre de usuario en el cuerpo de la solicitud. Si una aplicación utiliza un desafío mediante SMS donde 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 solo unos minutos. Un atacante simplemente necesita enviar todas las combinaciones posibles de seis dígitos a la aplicación hasta dar con la correcta.

En ese escenario, superficialmente parece que tener autenticación de dos factores mantendrá segura la aplicación. Pero como la entrada del usuario no tiene límite de tasa, la autenticación está rota y es vulnerable.

En otro ejemplo, una aplicación podría usar 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 las sesiones y los usuarios ante la aplicación. Por ejemplo, al decodificarla, podría ver el siguiente JSON:

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

En ese punto, el usuario malintencionado podría cambiar su nombre de usuario, su rol o ambos. Podría convertirse en otro usuario con un nivel de privilegios más alto cambiando un par de valores:

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

En ese momento, si el atacante vuelve a codificar la información y la establece como el valor de la cookie, esencialmente se convierte en el nuevo usuario con un nivel de permisos superior. A menos que existan métodos para evitar un cambio así, hay muchas probabilidades de que la aplicación acepte la transformación.

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

Si la autenticación falla, es muy probable que la seguridad general se vea comprometida. Pero seguir algunas pautas importantes al programar 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 estará perdida desde el principio.

En cuanto a las mejores prácticas, algo bueno a tener en cuenta es evitar exponer los ID de sesión en la URL a la que tienen acceso los usuarios. En el segundo ejemplo anterior sobre autenticación rota, evitar que un atacante intente decodificar la cookie de sesión es mucho más fácil si nunca se le expone.

También es recomendable implementar la autenticación multifactor. Esto puede hacerse de forma segura mediante tokens de hardware que generan contraseñas algorítmicamente en intervalos breves. Si no puede proporcionar estos dispositivos a sus usuarios, los mensajes SMS también funcionan. No obstante, debe limitar los intentos de los usuarios a un número razonable, como tres o cuatro en un periodo de 30 segundos, y asegurarse de que los códigos expiren en pocos minutos. Usar códigos alfanuméricos también mejora 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 IDs de sesión. En su lugar, utilice un gestor de sesiones seguro en el servidor que genere un ID de sesión aleatorio cada vez.

Implementar métodos de autenticación seguros es algo más complejo que combatir una vulnerabilidad común. Sin embargo, dado que la autorización es fundamental para cualquier aplicación, programa o API, merece la pena dedicar tiempo extra a asegurarse de hacerlo correctamente.

Consulte las páginas del blog de Secure Code Warrior para obtener más información sobre esta vulnerabilidad y 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 de Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.