- No hay mucha gente en contra de usar WAF, así que escribo este texto. La mayoría de los resultados de búsqueda sobre WAF están escritos por proveedores de WAF
- Los WAF se crearon en los inicios de internet y bloquean solicitudes similares a SQL, código de shell, etc., interceptando todas las solicitudes HTTP y evaluando cientos de expresiones regulares
- En los primeros tiempos de la ciberseguridad, los WAF parecían una buena idea, pero hoy en día ya no lo son
- Debido a los problemas de rendimiento de los WAF, la posibilidad de evadirlos, el riesgo de que se conviertan en un vector de ataque y su alta tasa de falsos positivos, hoy existen mejores tecnologías de seguridad
El rendimiento de los WAF es terrible
- Los WAF ejecutan cientos de expresiones regulares para cada solicitud, lo que degrada el rendimiento
- Al usar un WAF, se necesita una cantidad considerable de RAM adicional y aumentan el tiempo promedio de carga, la velocidad de procesamiento de solicitudes, el uso de CPU y también se producen bloqueos erróneos
Los WAF se evaden fácilmente
- En la competencia constante entre los WAF y los atacantes, los atacantes llevan la ventaja
- Es posible evadir las reglas de un WAF usando sintaxis complejas y técnicas de codificación
- Por ejemplo, el ataque Log4shell no puede bloquearse con una simple revisión de cadenas, y el atacante puede usar varias técnicas de evasión (Log4J Lookup)
- Además, si se rellena la cadena de ataque con unos 8 KB de caracteres inútiles pero inofensivos, el WAF deja de ser útil porque ya no puede seguir almacenándola en búfer en RAM y se corta
Los WAF son un vector de ataque
- En 2019, CapitalOne sufrió una filtración de 100 millones de solicitudes de crédito debido a un error de configuración del WAF
- Según se informó, el atacante engañó al WAF para enviar solicitudes al servicio de metadatos de EC2 y obtuvo credenciales con las que pudo leer archivos sensibles en S3
- Es decir, pueden ocurrir incidentes de seguridad por una configuración incorrecta del WAF
- La mayoría de los WAF son complejos y con frecuencia están hechos en código cerrado, lo que amplía la superficie de ataque
- Como son productos “empresariales” costosos, las compañías los llenan de funciones innecesarias para destacar más que la competencia
- A menudo se ignoran principios básicos de seguridad en los productos de seguridad
Alta tasa de falsos positivos en los WAF
- Durante los últimos 20 años, los conjuntos de reglas de WAF de código abierto se han ampliado considerablemente para detectar tipos modernos de ataques. Es probable que los WAF propietarios estén haciendo lo mismo
- Eso significa que cada vez hay más cadenas que, al ejecutar el WAF, pueden hacer que una solicitud sea bloqueada
- Cada vez que aparecen nuevas reglas, la expansión de las reglas del WAF aumenta la tasa de falsos positivos
- Los WAF de “próxima generación” afirman resolver este problema revisando múltiples solicitudes o usando sistemas de reputación de IP
- Tal vez puedan mejorar las tasas de falsos positivos (
false positive rates), pero no pueden resolver por completo el problema de los falsos positivos
- Los falsos positivos pueden dejar a los usuarios y a los equipos de soporte sin un procedimiento claro para resolver el problema
Alternativas al WAF
- Aislamiento (Isolation): técnica para que, aunque una parte del sistema sea comprometida, no afecte a las demás
- Los navegadores lo hacen ejecutando todo el código dentro de procesos especiales en sandbox que no tienen acceso arbitrario a cookies, contraseñas guardadas, otras pestañas, etc.
- Los microservicios fueron diseñados pensando en el aislamiento, pero también puede lograrse en un monolito usando varias bibliotecas y lenguajes
- Inmutabilidad (Immutability): eliminar categorías de ataque mediante sistemas de archivos de solo lectura, gestores de paquetes que requieren reinicio, respaldos de solo anexado, etc.
- Análisis estático (Static Analysis): usar sentencias preparadas (
prepared statements) para evitar inyección SQL e inspeccionar el código con análisis estático en el pipeline de CI
- Seguridad basada en capacidades (Capability-based Security): no todos los endpoints de API necesitan acceso ilimitado a la base de datos y al sistema de archivos; se debe adoptar un enfoque de otorgar solo los permisos necesarios
5 comentarios
:+1:
Con una combinación de
nginx+naxsi, parece que no aplican varios de los puntos mencionados arriba.El conjunto de reglas del WAF debe llevarse de una manera en la que lo gestione el desarrollador del servicio.
Los especialistas en seguridad, al hacer configuraciones genéricas sin comprender el servicio, terminan generando una alta tasa de falsos positivos y, al ir eliminando las reglas una por una según las solicitudes, hacen que el WAF pierda su función original.
Estoy parcialmente de acuerdo en la parte de los bypass y los falsos positivos, pero en general da mucho la impresión de que se enumeran datos poco sólidos como si fueran hechos. Si tengo tiempo, también tendré que revisar el contenido original. En particular, señalar el caso de CapitalOne como un problema del WAF hace pensar que el autor original no entiende muy bien qué es un WAF. Un WAF no es una solución que mitigue vulnerabilidades de raíz. Las vulnerabilidades que se originan en el código deben resolverse en el código; esa es la forma correcta de solucionarlas. Pero en la práctica no siempre es así, así que se necesita algo adecuado en la primera línea para inspeccionar entradas sospechosas o maliciosas. Si se opera bien, puede ser una herramienta realmente excelente; si se opera mal, puede convertirse en una herramienta que te haga daño. La doble cara de una herramienta siempre existe, pero este tema parece resaltar demasiado solo el lado negativo.
En los comentarios de Hacker News hay diversas opiniones y contraargumentos sobre esto. Revísenlos también. https://news.ycombinator.com/item?id=38255004