Anteriormente se llamaba Autenticación Rota y baja de la segunda posición. Incluye ahora CWEs más relacionadas con fallas de identificación. La mayor disponibilidad de marcos estandarizados parece estar ayudando a reducir esta categoría.

¿Qué son las Fallas de Identificación?

Confirman la identidad del usuario, la autenticación y la gestión de sesiones como críticas para proteger contra ataques relacionados con la autenticación.

Vulnerabilidades comunes

  • Credenciales débiles o contraseñas por defecto
  • Sesiones expuestas en URLs
  • Sesiones no invalidadas al cerrar sesión
  • Falta de protección contra ataques de fuerza bruta
  • Almacenamiento inseguro de credenciales (texto plano, hash débil)
  • Missing o inefectiva autenticación multifactor (MFA)

¿Cómo prevenir?

  • Implementar MFA siempre que sea posible
  • No usar credenciales por defecto
  • Implementar políticas de contraseñas robustas
  • Usar un gestor de sesiones seguro del lado del servidor
  • Limitar o retrasar intentos de login fallidos
  • Registrar los fallos de autenticación

Archivo de la web anterior

Contenido original publicado

Identificación y autenticación

Resumen

Anteriormente conocida como Autenticación Rota, esta categoría ha descendido desde la segunda posición y ahora incluye Enumeraciones de Debilidades Comunes (CWE) relacionadas con fallos de identificación. Algunas CWE notables incluidas son CWE-297: Validación Incorrecta de Certificado con Desajuste de Host, CWE-287: Autenticación Incorrecta, y CWE-384: Fijación de Sesión.

Descripción

La confirmación de la identidad del usuario, la autenticación y la gestión de sesiones son críticas para protegerse contra ataques relacionados con la autenticación. Pueden existir debilidades en la autenticación si la aplicación:

  • Permite ataques automatizados como el relleno de credenciales, donde el atacante tiene una lista de nombres de usuario y contraseñas válidos.
  • Permite ataques de fuerza bruta u otros ataques automatizados.
  • Permite contraseñas predeterminadas, débiles o bien conocidas, como “Password1” o “admin/admin”.
  • Utiliza procesos de recuperación de credenciales o de olvidó la contraseña que son débiles o ineficaces, como las “respuestas basadas en conocimientos”, que no pueden hacerse seguras.
  • Utiliza almacenes de datos de contraseñas en texto plano, encriptadas o con hash débil (ver A02:2021-Fallos Criptográficos).
  • Carece de autenticación multifactor o esta es ineficaz.
  • Expone el identificador de sesión en la URL.
  • Reutiliza el identificador de sesión después de un inicio de sesión exitoso.
  • No invalida correctamente los ID de sesión. Las sesiones de usuario o los tokens de autenticación (principalmente tokens de inicio de sesión único (SSO)) no se invalidan correctamente durante el cierre de sesión o después de un período de inactividad.

Cómo prevenir

  • Cuando sea posible, implementa autenticación multifactor para prevenir ataques automatizados de relleno de credenciales, fuerza bruta y reutilización de credenciales robadas.
  • No envíes ni despliegues con credenciales predeterminadas, especialmente para usuarios administradores.
  • Implementa verificaciones de contraseñas débiles, como probar las nuevas o modificadas contra la lista de las 10,000 peores contraseñas.
  • Alinea las políticas de longitud, complejidad y rotación de contraseñas con las directrices del Instituto Nacional de Estándares y Tecnología (NIST) 800-63b en la sección 5.1.1 para Secretos Memorizados u otras políticas modernas de contraseñas basadas en evidencia.
  • Asegúrate de que los procesos de registro, recuperación de credenciales y rutas API estén fortalecidos contra ataques de enumeración de cuentas, utilizando los mismos mensajes para todos los resultados.
  • Limita o incrementa gradualmente los retrasos en los intentos de inicio de sesión fallidos, pero ten cuidado de no crear un escenario de denegación de servicio. Registra todos los fallos y alerta a los administradores cuando se detecten ataques de relleno de credenciales, fuerza bruta u otros ataques.
  • Utiliza un administrador de sesiones seguro y basado en el servidor que genere un nuevo ID de sesión aleatorio con alta entropía después del inicio de sesión. El identificador de sesión no debe estar en la URL, debe almacenarse de forma segura y debe invalidarse después del cierre de sesión, la inactividad y los tiempos de espera absolutos.

Ejemplos de escenarios de ataques

Escenario #1: El relleno de credenciales, que implica el uso de listas de contraseñas conocidas, es un ataque común. Supongamos que una aplicación no implementa protección contra amenazas automatizadas o relleno de credenciales. En ese caso, la aplicación puede ser utilizada como un oráculo de contraseñas para determinar si las credenciales son válidas.

Escenario #2: La mayoría de los ataques de autenticación ocurren debido al uso continuo de contraseñas como único factor. Lo que antes se consideraba una buena práctica, la rotación de contraseñas y los requisitos de complejidad, ahora incentiva a los usuarios a utilizar y reutilizar contraseñas débiles. Se recomienda que las organizaciones dejen de seguir estas prácticas según NIST 800-63 y utilicen autenticación multifactor.

Escenario #3: Los tiempos de espera de la sesión de la aplicación no están configurados correctamente. Un usuario utiliza una computadora pública para acceder a una aplicación. En lugar de seleccionar “cerrar sesión”, el usuario simplemente cierra la pestaña del navegador y se retira. Un atacante utiliza el mismo navegador una hora después, y el usuario sigue autenticado.

Referencias