Lo que todavía pasa por WAF: técnicas de derivación y cómo mitigarlas

La creencia de que tener un WAF equivale a tener un perímetro de seguridad es una de las más costosas que puede sostener un equipo técnico. Los WAF operan según representaciones de solicitudes: reciben bytes, interpretan según reglas y deciden si el patrón coincide con un ataque conocido. El problema es que entre la interpretación WAF y la interpretación de la aplicación existe una brecha. Los atacantes que son conscientes de esta brecha la explotan con técnicas que existen desde hace más de una década y siguen siendo efectivas porque se basan en ambigüedades en los protocolos HTTP, no en fallas específicas del producto.

Cómo la doble codificación evita la inspección de la carga útil

La codificación de URL es un mecanismo HTTP legítimo: ' (comillas simples) se puede representar como %27. La mayoría de los WAF decodifican esta codificación antes de aplicar las reglas: comportamiento correcto, ya que la aplicación también la decodificará.

El problema aparece con la doble codificación. La cadena %2527 se decodifica en dos pasos: primero a %27, luego a '. Un WAF que realiza solo una ronda de decodificación ve %27 y lo considera una representación inofensiva de comillas simples. La aplicación, al procesar la petición, hace su propia decodificación y llega al ' que el atacante quería introducir. La carga útil llegó intacta.

Las variaciones incluyen la codificación de espacios como %09 (tabulación en lugar de espacio, equivalente en muchos contextos SQL) y la combinación de codificaciones de mayúsculas y minúsculas que algunos motores de expresiones regulares no normalizan.

Cloudflare aplica la normalización de solicitudes antes de ejecutar reglas: canonicalización que deshace múltiples capas de codificación. Esto mitiga la mayoría de las técnicas de doble codificación, pero la efectividad depende de la integridad de la normalización aplicada a cada campo inspeccionado.

Contrabando de solicitudes HTTP: cuando WAF y el origen no están de acuerdo

HTTP/1.1 permite dos formas de indicar el tamaño del cuerpo de una solicitud: Content-Length, que especifica bytes exactos, y Transfer-Encoding: chunked, que envía el cuerpo en partes. Cuando hay dos encabezados con valores en conflicto, el comportamiento no lo define el protocolo, sino la implementación de cada servidor.

Un WAF que prioriza Content-Length y un servidor de origen que prioriza Transfer-Encoding no estarán de acuerdo sobre dónde termina una solicitud. Un atacante que controla este conflicto hace que el WAF vea una solicitud inofensiva mientras que el servidor ve dos: la primera legítima y la segunda con contenido malicioso que nunca pasó la inspección. El contrabando de solicitudes HTTP ha afectado a múltiples WAF comerciales a lo largo de los años, requiriendo soluciones específicas en cada uno de ellos.

Cloudflare normaliza las solicitudes antes de reenviarlas al origen. Para que el ataque funcione en una arquitectura Cloudflare, el servidor de origen debería recibir conexiones directas, lo que nos lleva a la mitigación más importante y menos aplicada.

Lo que Cloudflare realmente no puede proteger

La lógica empresarial es el caso más claro. El WAF no tiene contexto para su aplicación: no sabe que una transferencia de R$ 50.000 en secuencia rápida es sospechosa, que sólo se debe acceder al endpoint /api/export con el rol admin, o que discount_percentage no debe aceptar valores negativos. Los ataques IDOR, la manipulación de los parámetros de precios y el abuso de los flujos de autenticación llegan como solicitudes válidas desde la perspectiva del WAF, porque lo son. Esta protección pertenece a la aplicación.

Los días cero son el segundo caso. Cuando se publica un CVE crítico, Cloudflare necesita tiempo para desarrollar una firma. Este intervalo puede ser de horas o días y durante el mismo la aplicación queda expuesta incluso con conjuntos de reglas administrados activos. Las reglas WAF no reemplazan los parches de la aplicación.

El bypass más simple: accede directamente a la fuente

Todo el modelo de protección WAF de Cloudflare depende de una condición: el tráfico debe pasar a través del proxy para ser inspeccionado. Los registros DNS en modo solo DNS (la nube gris en el tablero) no pasan a través del proxy. Si el subdominio que sirve la aplicación es solo DNS, el WAF simplemente no existe para ese tráfico.

La segunda condición es la IP de origen. Si un atacante descubre la IP real del servidor, puede conectarse directamente al puerto 443 con el encabezado Host correcto y evitar el borde por completo. Es posible que esta IP haya quedado expuesta a través de DNS históricos indexados por SecurityTrails antes de la migración, registros de transparencia de certificados TLS emitidos directamente a la IP o encabezados de correo electrónico enviados por el servidor.

La mitigación es configurar el servidor de origen para aceptar conexiones solo desde los rangos de IP de Cloudflare publicados en https://www.cloudflare.com/ips/. Un grupo de seguridad o una regla de firewall que acepte solo estos rangos elimina el contacto directo con la fuente. Para aquellos que desean eliminar por completo los puertos abiertos a Internet, Cloudflare Tunnel establece una conexión saliente desde el servidor hasta el borde sin exponer ninguna IP.

El modelo de amenaza que hay que comunicar

WAF es eficaz contra una categoría específica de atacantes: aquellos que utilizan herramientas de escaneo automatizadas, no adaptan las cargas útiles y buscan objetivos fáciles a escala. Frente a los escáneres de vulnerabilidades, los scripts de exploits genéricos y los bots que prueban la inyección SQL y XSS en cada parámetro que encuentran, un WAF bien configurado bloquea la gran mayoría de los intentos sin esfuerzo manual.

Contra un atacante dedicado que estudia la aplicación, mapea los puntos finales y adapta las cargas útiles específicamente para esa pila, la protección es diferente. Existen técnicas de derivación, algunas funcionan según el estado de normalización y la especificidad de las reglas, y aún se puede acceder directamente al origen si se filtra la IP. WAF gana tiempo, reduce la superficie de ataque automatizado y agrega una capa de visibilidad a lo que se intenta, pero no reemplaza la autenticación sólida, la validación de entradas de aplicaciones, los parches de dependencia y el control de acceso granular a nivel empresarial.