Tema 9
Toda aplicación necesita distinguir usuarios, verificar identidades y mantener sesiones seguras. Cuando estos mecanismos fallan, un atacante puede apropiarse de cuentas, suplantar identidades, abusar de credenciales robadas o persistir dentro del sistema con muy poco esfuerzo técnico adicional.
La mayoría de las aplicaciones web dependen de saber quién es el usuario, qué privilegios tiene y cómo mantener su contexto entre múltiples solicitudes. Ese proceso involucra varias capas: identificación, autenticación, emisión o asociación de sesión, protección de credenciales y mecanismos de recuperación cuando algo sale mal.
Si alguna de esas capas es débil, un atacante puede iniciar sesión como otro usuario, secuestrar una sesión válida, abusar de credenciales robadas, automatizar intentos de acceso o tomar control de cuentas mediante flujos auxiliares como la recuperación de contraseña.
OWASP agrupa estos problemas bajo Identification and Authentication Failures porque la autenticación no es solo un formulario de login. Es un sistema completo de confianza que debe resistir errores humanos, abuso automatizado, robo de credenciales y decisiones de diseño débiles.
Aunque están relacionadas, estas tres nociones no son idénticas.
Un diseño seguro necesita que estas tres partes funcionen coordinadamente. No alcanza con verificar una contraseña si luego la sesión es predecible, persistente en exceso o fácilmente robable.
Existe una falla de autenticación cuando la aplicación permite que una identidad sea suplantada, asumida o verificada de forma insuficiente. Esto puede ocurrir por contraseñas débiles, validaciones inconsistentes, sesiones mal protegidas, flujos de recuperación inseguros o ausencia de controles frente a abuso automatizado.
Algunas manifestaciones típicas son:
Desde seguridad, una cuenta autenticada representa mucho más que un nombre de usuario. Puede dar acceso a datos personales, operaciones financieras, configuraciones críticas, trazabilidad histórica, recursos internos o canales de soporte privilegiados. Por eso la apropiación de cuentas es una de las metas más frecuentes de un atacante.
En muchos incidentes, el objetivo no es explotar el sistema completo, sino obtener una identidad válida con suficiente alcance para operar sin levantar sospechas.
Una autenticación basada en contraseña depende en gran medida de la calidad de esa contraseña y de cómo la aplicación gestiona su uso. Políticas demasiado laxas, ausencia de verificación frente a credenciales comprometidas o falta de educación del usuario facilitan ataques de guessing, fuerza bruta o reutilización.
Problemas frecuentes:
No todos los intentos de acceso no autorizado son iguales. Comprender sus diferencias ayuda a diseñar defensas más adecuadas.
| Técnica | Descripción |
|---|---|
| Fuerza bruta | Intentar múltiples contraseñas contra una misma cuenta |
| Credential stuffing | Probar credenciales robadas de otros servicios |
| Password spraying | Probar pocas contraseñas comunes sobre muchas cuentas |
Estas técnicas son muy efectivas cuando no hay límites de intentos, MFA, monitoreo o detección de patrones anómalos.
Una autenticación segura no solo verifica credenciales; también debe resistir abuso automatizado. Si la aplicación acepta intentos ilimitados sin fricción ni control contextual, el atacante puede escalar rápidamente su capacidad.
Controles típicos:
La enumeración ocurre cuando la aplicación revela, de forma directa o indirecta, si un identificador de cuenta existe o no. A veces parece un detalle menor, pero facilita ataques dirigidos porque reduce incertidumbre del atacante.
Puede aparecer en:
La mitigación no siempre exige silencio total, pero sí consistencia suficiente para no convertir el sistema en un oráculo de existencia de cuentas.
Muchas aplicaciones endurecen el login principal pero descuidan los flujos de recuperación, que en la práctica representan una vía alternativa de autenticación. Si recuperar la cuenta es más fácil que iniciar sesión de forma legítima, el atacante tomará ese camino.
Problemas comunes:
La autenticación multifactor agrega una capa importante de seguridad porque exige algo más que la contraseña. Esto reduce impacto de credenciales reutilizadas o filtradas. Sin embargo, MFA no resuelve todos los problemas por sí sola.
Su efectividad depende de:
Una cuenta con MFA pero con recuperación insegura o sesiones mal gestionadas sigue en riesgo.
Después de autenticar a un usuario, la aplicación necesita mantener su contexto. Ese contexto suele materializarse en una cookie de sesión, un token u otro identificador que el cliente reenvía en solicitudes posteriores.
Una sesión segura debería:
Si el atacante obtiene una sesión válida, puede actuar como el usuario sin necesidad de conocer su contraseña. Esa obtención puede provenir de robo, exposición o manipulación del identificador.
Dos conceptos importantes:
Esto explica por qué la seguridad no termina cuando el login fue exitoso. La sesión posterior es parte central del problema.
Cuando la sesión se maneja con cookies, ciertos atributos ayudan a reducir exposición.
Estos atributos no sustituyen un buen diseño de sesión, pero forman parte de la higiene mínima esperable.
Un error habitual es implementar el cierre de sesión solo del lado cliente, borrando visualmente estado o eliminando una cookie, sin invalidar correctamente el contexto en el servidor. Esto puede dejar sesiones reutilizables o inconsistentes.
Del mismo modo, eventos relevantes como cambio de contraseña, cambio de correo principal o detección de acceso riesgoso deberían poder invalidar sesiones previas o exigir reautenticación según el caso.
No todas las operaciones tienen el mismo riesgo. Algunas acciones justifican verificar nuevamente la identidad, aun dentro de una sesión ya autenticada.
Ejemplos típicos:
La ausencia de este control no siempre genera una explotación automática, pero sí aumenta significativamente el riesgo si una sesión fue robada o abusada.
La seguridad de identidad empieza incluso antes del primer login. El proceso de registro define cómo se crea una cuenta, qué datos se consideran confiables y qué pruebas de control sobre esa identidad se exigen.
Problemas que pueden aparecer:
Una sesión que dura demasiado amplía la ventana de oportunidad para abuso. Esto es especialmente delicado en dispositivos compartidos, sesiones olvidadas abiertas o contextos donde el identificador pudo ser interceptado o almacenado indebidamente.
La duración adecuada depende del tipo de aplicación, del nivel de riesgo y del contexto de uso. No existe un valor universal, pero sí una regla general: la persistencia debe ser proporcional al impacto de la cuenta y a la sensibilidad de las acciones permitidas.
Las fallas de identificación y autenticación pueden llevar directamente a compromiso de cuentas, y desde allí a problemas mucho más amplios.
| Falla | Impacto posible |
|---|---|
| Login débil o sin controles | Toma masiva de cuentas |
| Recuperación insegura | Secuestro de identidad sin conocer la contraseña |
| Sesión robable o persistente | Suplantación del usuario autenticado |
| MFA ausente en cuentas críticas | Mayor exposición ante credenciales filtradas |
| Reautenticación ausente | Cambios sensibles ejecutados con sesión comprometida |
Secure o HttpOnly.La prevención de esta categoría combina diseño, controles técnicos y operación continua.
La autenticación segura no termina en el diseño del formulario o la cookie. También exige observabilidad. El monitoreo ayuda a detectar fuerza bruta, credential stuffing, recuperaciones anómalas, accesos desde contextos inusuales o comportamientos incompatibles con el uso normal de la cuenta.
Sin monitoreo, muchas apropiaciones de cuenta pueden pasar desapercibidas durante largos períodos.
Las fallas de autenticación interactúan con varias categorías del curso.
Esto explica por qué la autenticación suele ser una de las capas más críticas de cualquier sistema.
Identification and Authentication Failures muestran que la identidad digital de un usuario puede ser tan valiosa como cualquier dato sensible de la aplicación. Si el sistema no protege bien cómo se inicia sesión, cómo se mantiene la sesión y cómo se recupera una cuenta, un atacante no necesita vulnerar toda la infraestructura: le basta con convertirse en un usuario válido.
En el próximo tema estudiaremos A08: Software and Data Integrity Failures, donde veremos qué ocurre cuando la aplicación confía ciegamente en actualizaciones, datos, integraciones o artefactos cuya integridad no fue adecuadamente validada.