Cloudflare probó su firewall de aplicaciones web (WAF) utilizando modelos avanzados de inteligencia artificial capaces de modificar las solicitudes ofensivas después de cada intento, en lugar de limitarse a un conjunto fijo de pruebas. La empresa llevó a cabo el experimento en un entorno de staging privado de un cliente y con autorización previa, y registró 1.107 intentos en 45 escenarios.
La idea principal es simular una parte del comportamiento de un atacante capaz de probar distintas codificaciones, trasladar la carga útil a otras posiciones dentro de una solicitud HTTP o cambiar la forma de representar el destino, y después utilizar la respuesta para elegir el siguiente intento. El modelo no recibió el código de la aplicación, las reglas internas del WAF ni los números de las reglas, sino que solo trabajó con el contexto de la solicitud y datos específicos de la respuesta HTTP.
¿Cómo funcionó la prueba adaptativa?
Cada escenario comenzó con una solicitud que se sabía que el WAF bloqueaba, y después el modelo propuso una nueva modificación. Tras enviar la solicitud, otro modelo o una llamada de revisión del modelo examinaba la respuesta, antes de que el sistema determinara el siguiente paso dentro de un límite máximo de intentos. El código se encargó de ejecutar las solicitudes y registrar las pruebas; además, antes de cada intento verificaba el nombre de dominio mediante una lista permitida, detenía las redirecciones e impedía que el sistema cambiara o implementara reglas de protección.
44 de los escenarios abarcaron seis categorías: secuencias de comandos entre sitios (XSS), inyección SQL, inyección de comandos, falsificación de solicitudes del lado del servidor (SSRF), recorrido de rutas o inclusión de archivos locales (LFI) y ataques Log4j. El escenario número 45 abordó por separado la inyección de registros.
De 1.107 intentos a 49 resultados investigables
El WAF tuvo un rendimiento sólido en general, con una cobertura casi completa de las categorías XSS, LFI, SQLi y Log4j. Tras la revisión humana, quedaron 49 resultados que merecían investigación, de los cuales 48 pertenecían a las categorías de inyección de comandos y SSRF. El número de solicitudes bloqueadas fue de 558, mientras que otros intentos fueron excluidos por ser inválidos, benignos, duplicados o por no haber llegado al objetivo.
Cloudflare no consideró que una solicitud no bloqueada fuera una vulnerabilidad confirmada. Exigió que la solicitud fuera válida y llegara al objetivo, que siguiera siendo claramente maliciosa, que el comportamiento pudiera atribuirse al WAF y que los ingenieros pudieran reproducirlo de forma segura. Esta distinción es importante porque eludir el WAF, por sí solo, no demuestra que la explotación de la aplicación haya tenido éxito ni que se haya accedido a datos sensibles.
Ejemplo de una brecha en la detección de SSRF
En uno de los escenarios, el sistema cambió la forma de escribir la dirección del servicio de metadatos en la nube, utilizó distintas representaciones numéricas y colocó la dirección en varias partes de la solicitud. La mayoría de los intentos fueron bloqueados, pero uno que utilizó una representación con un punto final provocó una redirección en lugar de ser bloqueado por el WAF. Cloudflare consideró esto una señal que merecía investigación, no una prueba de acceso a credenciales ni de éxito de la explotación.
¿Qué cambió en la práctica?
Cloudflare revisó los resultados para determinar si necesitaba una nueva regla, mejorar la normalización de las solicitudes o recurrir a otra capa de seguridad. Los resultados contribuyeron a tres cambios en Managed Ruleset: la incorporación de las detecciones SSRF - Obfuscated Host y SSRF - Restricted Protocol en la versión del 21 de julio, y la mejora de la detección SSRF - Cloud. La detección del host ofuscado surgió directamente de solicitudes que utilizaban formatos numéricos inusuales para direcciones internas.
El experimento demuestra que la inteligencia artificial es aquí una herramienta para ampliar el espacio de pruebas, no un sustituto del criterio de ingeniería. Dos modelos de la misma familia produjeron variaciones diferentes, pero los problemas fundamentales aparecieron en ambos. Además, aumentar los intentos dentro de un mismo escenario no garantizó el descubrimiento de resultados adicionales; algunas secuencias comenzaron a repetir ideas, mientras que aumentar los puntos de partida, las categorías de ataque y las ubicaciones de entrada proporcionó una cobertura más amplia.
Los límites del WAF siguen presentes: una carga útil que atraviesa el firewall solo tiene éxito si la propia aplicación es explotable, por lo que mantener el software actualizado y corregir las vulnerabilidades sigue siendo esencial. Cloudflare también recomienda activar primero las reglas en modo de registro, revisar las solicitudes coincidentes y los eventos de seguridad, y pasar después al bloqueo tras verificar que el tráfico legítimo no se vea afectado. Más adelante, la empresa planea presentar una prueba de white-box en la que el modelo conozca simultáneamente las vulnerabilidades de la aplicación y las reglas del WAF.