Las aplicaciones web suelen ser el objetivo de los atacantes malintencionados. Estas aplicaciones son de acceso público -o, al menos, sus páginas de inicio de sesión lo son- y no es difícil para un atacante decidido encontrar sitios con fallos de seguridad. Los atacantes a menudo tratan de explotar las vulnerabilidades de seguridad de la página de inicio de sesión en una aplicación web para causar una carga excesiva y potencialmente hacer caer el sitio.
Una de estas vulnerabilidades puede encontrarse en la página de preguntas de seguridad que forma parte de muchos flujos de inicio de sesión. En este post, vamos a ver este escenario, examinar por qué es un problema, y proporcionar orientación sobre cómo mitigar ese riesgo de seguridad.
Página de inicio de sesión con una pregunta de seguridad en blanco
Las vulnerabilidades de seguridad de las páginas de inicio de sesión son más comunes de lo que se cree. En el proceso de inicio de sesión de muchos sitios web y aplicaciones, una salvaguarda de verificación adicional amplía el paso tradicional de nombre de usuario/contraseña para aumentar la seguridad. Imagine un flujo de inicio de sesión en dos pasos. En el primer paso, el sitio le pide una combinación de nombre de usuario y contraseña. Si introduce estas credenciales correctamente, en el segundo paso se le pide que responda a una pregunta de seguridad (que especificó cuando configuró su cuenta por primera vez).
Este segundo paso se construye típicamente a partir de una plantilla de vista de página que inserta la pregunta de seguridad basada en el usuario que ha completado con éxito el primer paso. Todo el flujo de inicio de sesión en dos pasos funciona básicamente así:
- Alice visita la página de inicio de sesión en https://www.example.com/login.
- Alice envía una combinación de nombre de usuario y contraseña.
- El servidor verifica las credenciales enviadas.
- Como las credenciales eran correctas, el servidor redirige el navegador a la página de seguimiento en https://www.example.com/login2, incluyendo un token único en la cabecera de la petición para verificar que Alice ha superado el primer paso del flujo de inicio de sesión.
- El servidor crea esta página basándose en una plantilla, insertando la pregunta de seguridad obtenida para Alice, junto con la entrada de texto para una respuesta y un botón de envío.
- Alice envía la respuesta a su pregunta de seguridad.
- El servidor verifica que Alice ha respondido correctamente a su pregunta de seguridad y la conecta.
Centrémonos en esa segunda página del flujo, en https://www.example.com/login2. Imagina qué pasaría si visitaras esa página directamente en tu navegador, sin pasar por el primer paso.
En un escenario, es posible que el servidor compruebe si no hay un token válido en la cabecera de la solicitud (lo que significa que no has superado con éxito el primer paso del flujo de inicio de sesión), y simplemente te redirige de nuevo a https://www.example.com/login para empezar de nuevo.
Sin embargo, en otro escenario posible, el servidor sigue mostrando la página basándose en la plantilla. Al no poder encontrar una pregunta de seguridad correspondiente para el usuario (ya que no hay ningún token que indique al servidor de qué usuario medianamente autenticado se trata), la página resultante podría tener este aspecto:
Te quedas con una incómoda página de pregunta de seguridad que no tiene... ninguna pregunta de seguridad. Hablando de una página sin sentido.
Inútil, sí. ¿Pero inofensivo? No estés tan seguro.
Implicaciones para la seguridad
Siguiendo con este escenario, ¿qué ocurriría cuando tú (o una persona más malintencionada que tú) enviara una respuesta a esta "pregunta de seguridad"? El servidor dedicará ciclos de CPU a evaluar tu respuesta. Procesará la entrada de texto, buscará el token único en la cabecera de la solicitud y posiblemente incluso ejecute una consulta a la base de datos en un intento de validar su respuesta.
Una página de inicio de sesión con una pregunta de seguridad en blanco puede parecer insignificante(¿qué hay de malo en malgastar unos cuantos ciclos de CPU aquí y allá?), pero puede dar lugar a graves problemas de seguridad.
- Recursos de procesamiento de backend desperdiciados: El procesamiento de formularios inútiles consume recursos informáticos y de red, y posiblemente también recursos de bases de datos.
- Posibilidad de ataques de denegación de servicio (DoS): Un atacante podría crear una red de bots para enviar formularios repetidamente, sobrecargando el sistema.
- Mayor vulnerabilidad: Un ataque DoS exitoso podría hacer caer todo su sistema.
Si los atacantes pueden explotar esta debilidad para malgastar la capacidad de procesamiento de un servidor, podrían interrumpir los servicios para los usuarios legítimos y exponer el sistema a nuevos ataques.
No tan inofensivo después de todo.
Veamos cómo abordar vulnerabilidades como éstas para mantener la seguridad y fiabilidad de sus aplicaciones.
Cómo defenderse
Para este escenario específico, el servidor que gestiona el endpoint login2 debería verificar la existencia de un token válido en la cabecera de la petición. Sin un token válido, no debería realizarse ningún otro procesamiento, y el usuario debería ser redirigido al primer paso del flujo de inicio de sesión. De esta manera, se minimizan los recursos utilizados para manejar la solicitud con gracia, de la misma manera que para un 404 o un 401.
Sin embargo, este escenario pone de relieve una preocupación de seguridad más general a la que deberías prestar atención: las peticiones repetidas que sobrecargan tu servidor con una carga excesiva. Ciertamente, explotar una página de inicio de sesión sin sentido con una pregunta de seguridad en blanco puede sobrecargar su servidor más rápidamente debido a la cantidad de recursos de procesamiento utilizados. Pero una red de bots también puede atacar su página de inicio de sesión de nombre de usuario/contraseña perfectamente normal con peticiones excesivas.
Para proteger sus aplicaciones web de este tipo de ataques, aplique las siguientes medidas:
- Utilice un cortafuegos de aplicaciones web (WAF): Un WAF puede proporcionar protección DoS y detectar y bloquear bots maliciosos, reduciendo el riesgo de ataques automatizados. LinodeEl marketplace de aplicaciones de Google incluye Haltdos Community WAF, que puede ayudarte en esta tarea.
- Implemente la limitación de velocidad: Limite el número de peticiones que puede realizar una única dirección IP en un periodo de tiempo determinado. Con la limitación de velocidad, evitarás que los atacantes (y los bots) inunden tu sistema de peticiones.
- Activar la supervisión y las alertas: Las herramientas de supervisión continua pueden detectar patrones de solicitud sospechosos y alertarle en tiempo real de posibles ataques. Cuando se le notifica de inmediato, puede responder y mitigar un problema rápidamente.
Conclusión
Hemos visto el caso de una página de inicio de sesión con una pregunta de seguridad en blanco. A primera vista, parece una extraña página de caso límite que, en última instancia, no tiene sentido. Pero los atacantes pueden explotar vulnerabilidades como estas para malgastar tus recursos y potencialmente hacer caer tu sistema. La página de pregunta de seguridad es sólo un ejemplo de este tipo de vulnerabilidad.
Si diseña sus aplicaciones pensando en la seguridad y adopta prácticas de codificación seguras, habrá empezado con buen pie. Sin embargo, sus aplicaciones también necesitan medidas de seguridad implementadas a nivel de sistema e infraestructura, como el uso de un WAF, la limitación de velocidad, la supervisión continua y las alertas. Con las medidas de seguridad adecuadas, puede reducir significativamente el riesgo de ser blanco de este tipo de ataques.
Para obtener más orientación y consejos sobre cómo proteger tus aplicaciones, consulta la documentación deLinode , con su rica biblioteca de guías relacionadas con la seguridad. Allí encontrarás recursos útiles que te orientarán sobre cómo proteger tus sistemas y a tus usuarios.
Comentarios