WAF

Un WAF se sitúa delante de una aplicación web y examina las peticiones antes de que lleguen a ella, comparándolas con reglas que describen formas de ataque conocidas: las firmas de la inyección SQL, del cross-site scripting, del path traversal y similares. Las peticiones que encajan se bloquean o se les plantea un desafío. Los WAF modernos añaden controles de ritmo y gestión de bots, y vienen a menudo empaquetados con una CDN, de forma que el mismo borde que cachea el contenido también lo filtra. Desplegado y afinado bien, un WAF reduce el ruido de los ataques automatizados y compra tiempo para arreglar un fallo de verdad. Es una capa en el borde que trabaja sobre el tráfico; no cambia la aplicación de debajo.

La creencia peligrosa es que un WAF hace segura la aplicación. No quita la vulnerabilidad; intenta reconocer los ataques contra ella, y reconocer es un juego al que también juega el atacante. Las firmas se esquivan codificando, jugando con las mayúsculas, partiendo una carga, o usando una forma del ataque que las reglas no modelan. Desde el lado ofensivo, un WAF es un obstáculo que se caracteriza y se rodea, no un muro: en nuestros encargos el código vulnerable sigue siendo vulnerable, y el WAF muchas veces convierte un hallazgo limpio en un hallazgo algo más lento. Y peor: un WAF por delante de una inyección sin arreglar puede alimentar la complacencia, porque el equipo trata la alerta como protección en vez de como la prueba de que le están sondeando.

Probamos la aplicación dando por hecho que el WAF se puede esquivar, porque en la práctica se puede. Donde el WAF bloquea una carga, trabajamos hasta colar una equivalente, e informamos igualmente de la vulnerabilidad de fondo con su severidad real, dejando anotado el WAF como control que mitiga pero no remedia. Los controles de ritmo se evalúan aparte, porque el rate limiting en el borde sí es útil de verdad contra ciertos abusos. Esto forma parte de cómo probamos la aplicación que hay detrás del WAF.