Desaconsejar el uso de firewalls de aplicaciones web

Artículo original ↗ Discusión en Hacker News ↗

Los firewalls de aplicaciones web (WAF) son criticados como herramientas costosas que inducen latencia, dan una falsa sensación de seguridad, son fáciles de eludir para atacantes decididos y, a menudo, se despliegan principalmente para cumplir casillas de cumplimiento como PCI-DSS o HIPAA. Los comentaristas sostienen que el diseño seguro, las consultas parametrizadas, el análisis estático y el aislamiento adecuado de servicios suelen ofrecer mejor protección, y que los WAF mal ajustados incluso pueden introducir nuevas vulnerabilidades o romper tráfico legítimo. Otros responden que los WAF todavía tienen un papel como defensa en profundidad: manejar ataques volumétricos, proteger aplicaciones heredadas o de terceros, proporcionar “parches virtuales” rápidos para amenazas emergentes y filtrar grandes volúmenes de tráfico basura automatizado.

Cumplimiento, auditorías y seguridad de casillas de verificación

  • Muchas implementaciones existen principalmente para satisfacer PCI-DSS, HIPAA o listas de verificación internas; los auditores a menudo solo verifican que haya un WAF presente, no que sea eficaz.
  • Varios señalan que PCI-DSS permite alternativas (por ejemplo, DAST continuo), pero WAF+reglas OWASP suele ser la evidencia más fácil de presentar.
  • Esto conduce a “WAFs de mentira” con reglas de bloqueo mínimas o nulas, usados solo para marcar casillas.

Eficacia, evasión y alcance

  • Los críticos argumentan que los WAF basados en regex/firma pueden eludirse trivialmente por atacantes con habilidad moderada, especialmente las ofertas genéricas en la nube.
  • Otros responden que los WAF bloquean ataques reales en la práctica (por ejemplo, inyecciones SQL que pasaron revisiones de código y herramientas) y elevan el listón al filtrar escaneos automáticos y exploits obvios.
  • Varios enfatizan que los WAF no son una panacea, sino parte de la defensa en profundidad; depender solo de ellos es peligroso.

Rendimiento y superficie de ataque

  • Algunos señalan importantes impactos en latencia y rendimiento, especialmente con motores al estilo ModSecurity, y observan que aplicaciones bien construidas pueden responder 404 más rápido de lo que un WAF puede inspeccionar.
  • Preocupan también los WAF por añadir ellos mismos una gran base de código expuesta a Internet y no segura en memoria, además de nuevos riesgos de mala configuración; en casos extremos han sido el vector de intrusión.

Realidades operativas y organizativas

  • Los WAF de nivel empresarial (por ejemplo, de clase Imperva) pueden requerir un ajuste considerable, personal dedicado y cuidado continuo de reglas; muchos terminan en modo de “configurar y olvidar”.
  • Otros dicen que los WAF en la nube son lo bastante fáciles de gestionar a tiempo parcial y útiles para filtrado básico de bots, reputación de IP y limitación de tasa en L7.
  • Los equipos de AppSec a menudo pueden cambiar reglas del WAF más rápido que las configuraciones de la aplicación o del servidor web, lo que hace atractivos a los WAF para el “parcheo virtual” (por ejemplo, cargas útiles de Log4j, bloqueo de endpoints específicos).

Falsos positivos e impacto en el usuario

  • Se dan múltiples ejemplos de tráfico legítimo bloqueado: redirecciones OpenID, palabras comunes como “Union” en direcciones, comportamientos estándar de frameworks.
  • Los conjuntos de reglas predeterminados pesados (por ejemplo, “habilitar todo”) se señalan como especialmente problemáticos y a veces provocan soluciones alternativas inseguras.

Alternativas y complementos

  • Fuerte énfasis en el diseño seguro de aplicaciones: SQL parametrizado, análisis estático, tipado estricto de API, aislamiento de procesos, acceso con privilegio mínimo.
  • Algunos sugieren bloqueos básicos a nivel de red, listas de denegación de IP y gateways de API/routers frontales como alternativas o complementos más simples o más transparentes.