OWASP Top Ten 2017 (es)

A2:2017-Pérdida de Autenticación

 Languages: en de [es]
Agente de amenaza / Vector de ataque Debilidades de seguridad Impacto
Específico
de la Apl.		 Explotabilidad: 3 Prevalencia: 2 Detectabilidad: 2 Técnico: 3 ¿Negocio?
Los atacantes tienen acceso a millones de combinaciones de pares de usuario y contraseña conocidas (debido a fugas de información), además de cuentas administrativas por defecto. Pueden realizar ataques mediante herramientas de fuerza bruta o diccionarios para romper los resúmenes (hashes) de las contraseñas. Los ataques al manejo de la sesión, son bien entendidos, en particular respecto a la relación con los testigos de sesión no expirados.
Los errores de pérdida de autenticación son comunes debido al diseño y la implementación de la mayoría de los controles de acceso. La gestión de sesiones es la piedra angular de los controles de autenticación y está presente en las aplicaciones. Los atacantes pueden detectar la autenticación defectuosa utilizando medios manuales y explotarlos utilizando herramientas automatizadas con listas de contraseñas y ataques de diccionario.
Los atacantes solo tienen que obtener el acceso a unas pocas cuentas o a una cuenta de administrador para comprometer el sistema. Dependiendo del dominio de la aplicación, esto puedo permitir lavado de dinero, robo de identidad o la divulgación de información altamente sensible protegida legalmente.
¿La aplicación es vulnerable?
La confirmación de la identidad y la gestión de la sesión del usuario son fundamentales para protegerse contra ataques relacionados con la autenticación. Pueden existir debilidades de autenticación si la aplicación:
* Permite ataques automatizados como la reutilización de credenciales robadas, cuando el atacante ya posee una lista de pares de usuario y contraseña válidos.
* Permite ataques de fuerza bruta y/o ataques automatizados.
* Permite contraseñas por defecto, débiles o muy conocidas, como “Password1”, “Contraseña1”o “admin/admin”.
* Posee procesos débiles o inefectivos para la recuperación de credenciales, tales como “respuestas basadas en el conocimiento”, que no puedan implementarse de manera segura.
* Almacena las contraseñas en texto claro o cifradas o con resúmenes (hashing) de claves débiles (vea A3:2017-Exposición de Datos Sensibles).
* No posee autenticación multi-factor o fue implementada de forma ineficaz.
* Expone IDs de la sesión en las URL (e.g reescritura de URL).
* No rota la ID de la sesión tras el inicio de una sesión.
* No invalida correctamente la ID de la sesión. La sesión del usuario o los testigos de autenticación (en particular los testigos de un soló inicio –single sign-on - SSO) no son invalidados satisfactoriamente al cierre de sesión o tras un periodo de tiempo determinado de inactividad.
Cómo se previene
* Implemente autenticación multi-factor para evitar ataques automatizados, de fuerza bruta o reúso de credenciales robadas.
* No despliegue con credenciales por defecto en su software, particularmente en el caso de administradores.
* Implemente controles contra contraseñas débiles. Cuando el usuario ingrese una nueva clave, la misma puede verificarse contra la lista del top 10.000 de peores contraseñas.
* Alinee las políticas de longitud, complejidad y rotación de contraseñas con las recomendaciones de la Sección 5.1.1 para Secretos Memorizados de la Guía NIST 800-63 B u otras políticas de contraseñas modernas, basadas en evidencias.
* Mediante la utilización de los mensajes genéricos iguales en todas las salidas, asegúrese que el registro, la recuperación de credenciales y las rutas de la API haga más difíciles los ataques de enumeración de usuarios.
* Limite o incremente el tiempo frente a intentos fallido de inicio de sesión. Registre en bitácoras todos los fallos y alerte a los administradores cuando se detecten ataques de fuerza bruta, reutilización de contraseñas u otros ataques.
* Utilice un gestor de sesión en el servidor, integrado, seguro y que genere un nuevo ID de sesión aleatorio con alta entropía después del inicio de sesión. El ID de sesión no debe incluirse en la URL, debe almacenarse de forma segura y debe ser invalidado después del cierre de sesión o de un tiempo de inactividad, y de un tiempo absoluto.
Ejemplos de escenarios de ataque
Escenario #1: la reutilización de credenciales robadas, y el uso de listas de contraseñas conocidas son ataques comunes. Si una aplicación no implementa protecciones frente a amenazadas automatizadas o frente a la reutilización de credenciales robadas, la aplicación podría ser usada como oráculo de contraseñas para determinar si unas credenciales son válidas.
Escenario #2: la mayoría de los ataques de autenticación ocurren debido al uso continuado de contraseñas como único factor. Las que una vez se consideraron mejores prácticas, como rotación de claves y requerimientos de complejidad, se ven como motivadoras para que los usuarios usen y reusen, claves débiles. Se recomienda a las organizaciones detener el uso de tales prácticas y según el NIST 800-63 usar autenticación multi-factor.
Escenario #3:los tiempos de vida de las sesiones de 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 aleja. Un atacante usa el mismo navegador una hora más tarde, la sesión continúa activa y el usuario se encuentra autenticado.
Referencias