Cómo utilizar el enriquecimiento de peticiones con nuestro WAF de última generación para ayudar a identificar datos de usuario no seguros

Lamentablemente, las filtraciones de datos que acaban revelando nombres de usuario o contraseñas son cada vez más habituales. Los piratas informáticos saben que muchos usuarios suelen utilizar la misma contraseña en diferentes sitios web. Si cotejan listas de credenciales robadas, son capaces de averiguar datos de inicio de sesión para realizar ataques de apropiación de cuentas (ATO) cuyo alcance va mucho más allá del sitio web desde el que se filtraron los datos. Este mismo mes, se ha divulgado el listado de contraseñas más extenso de la historia, lo cual ha puesto en peligro la seguridad de millones de cuentas de usuario. Sin embargo, si utilizas peticiones enriquecidas y las enrutas a través de Fastly, podrás saber si los inicios de sesión de usuario emplean credenciales no seguras.

En el Developer Hub hemos publicado un tutorial sobre enriquecimiento en el que se explica cómo añadir datos desde una API de terceros a las peticiones que se enrutan a través de Fastly. El tutorial utiliza la API de Have I Been Pwned, sitio de código de abierto que te permite verificar si un nombre de usuario específico o una contraseña concreta forman parte de alguna base de datos cuya seguridad consta que haya sido vulnerada. Si se añade el encabezado «fastly-password-status» a la petición, el servidor de origen establece el veredicto de HIBP respecto al contenido de esta.

Aunque nuestra edge cloud da libertad a tu origen para que decida qué hacer con esa información, ¿qué ocurriría si ejecutas nuestro WAF de última generación (anteriormente, Signal Sciences) en tu origen? ¿Se pueden utilizar los datos adicionales relativos a la petición a modo de señal en el WAF? Bueno, pues sí que se puede, y hoy te voy a mostrar cómo vincularlos.

Tu configuración de Fastly

Envío de peticiones a puntos de conexión de inicio de sesión

Inicia sesión en la consola de administración del WAF de última generación para verificar si las peticiones que se van a enrutar a través del servicio Compute pasan controles en busca de contraseñas no seguras conocidas. La regla que se indica a continuación comprueba si la petición contiene el encabezado «fastly-password-status». Es recomendable añadir este encabezado a todas las peticiones si se tiene constancia de que se ha vulnerado la seguridad de la contraseña. Sabrás que la contraseña se ha verificado si añades una señal cada vez que se detecte la presencia del encabezado «fastly-password-status».

Peticiones con contraseñas no seguras conocidas

Se puede comprobar si hay constancia de que la contraseña no es segura a partir del par clave-valor del encabezado de la petición, como se indica en el tutorial del Developer Hub. Para ello, crea una regla adicional que verifique la existencia del encabezado «fastly-password-status» y que este tenga el valor «compromised-credential». Si este par clave-valor de encabezado existe, es una confirmación de que el servicio Wasm configurado ha identificado una contraseña no segura.

Análisis de un caso hipotético

Si implantas esta configuración, obtendrás una visión más completa ante cualquier posible ataque. Por ejemplo, un elevado número de intentos de inicio de sesión, inicios de sesión erróneos y señales de credenciales no seguras relacionadas con peticiones durante un periodo concreto podrían ser indicativos de un intento de apropiación de cuentas mediante fuerza bruta.

En este sentido, estos datos te permitirán tomar decisiones mejor fundamentadas. Para esta demo, he creado la tarjeta «Compromised Passwords» (Contraseñas no seguras) y las señales «checked-pw» (contraseña verificada) y «compromised-pw» (contraseña no segura). Si combinamos la serie temporal con la tarjeta de inicio de sesión, se percibe que ha habido numerosos intentos y errores de inicio de sesión. Sin embargo, no ha habido inicios de sesión correctos: la mayoría de los intentos de inicio de sesión realizados durante el periodo dado emplearon contraseñas no seguras conocidas.

Gracias a esta información, puedo saber que es muy probable que mi punto de conexión de inicio de sesión esté sufriendo un ataque de inicio de sesión mediante fuerza bruta.

Toma decisiones mejor fundamentadas

Nuestro WAF de última generación te permitirá adoptar una estrategia de mitigación de conductas indebidas basada en umbrales. La regla de límite de volumen que presentamos a continuación bloquea mediante la señal «All Requests» (Todas las peticiones) las peticiones que provengan de una IP tras haberse alcanzado un número determinado de intentos de inicio de sesión con contraseñas no seguras.

Este tipo de mitigación permite a tu equipo de Seguridad o Prevención de Fraude investigar los comportamientos pertinentes y determinar si estos responden a un ataque a escala reducida (centrado en un solo usuario o en un pequeño conjunto de usuarios) o de amplio espectro (dirigido a muchos usuarios diferentes mediante la pulverización de contraseñas). 

Si se trata de un ataque a escala reducida, la respuesta que suele adoptar el equipo de Seguridad es garantizar que los usuarios afectados utilicen contraseñas seguras que no hayan sido vulneradas y la autenticación de doble factor. Y, si se producen inicios de sesión correctos desde esas IP, cerrar esas sesiones de usuario y forzar el restablecimiento de contraseñas.

Conclusión

Al suministrar datos de la API de Have I Been Pwned a nuestro WAF de última generación, podrás visualizar qué volumen de intentos de inicio de sesión en tu sitio web se hacen con contraseñas no seguras conocidas. Esta información podría servir para facilitar las tareas de mitigación de ataques de apropiación de cuentas y mejorar la seguridad de las cuentas de tus usuarios. Y esto es solo una pequeña muestra de las posibilidades que tienes a tu alcance si combinas las peticiones enriquecidas con Fastly. ¿Conoces otras posibilidades? ¡Cuéntanoslo en Twitter!