DoS vía WAF body size — agotar inspection budget en Cloudflare/Akamai

Respuesta rápida

Cuando un WAF recibe un body más grande de lo que puede inspeccionar, tiene dos opciones: fail-open (pasar sin inspección, el caso jugoso) o fail-closed (bloquear). Pero hay un tercer comportamiento, mucho menos documentado: si el atacante puede forzar que la respuesta del server caiga en el cache con un payload malicioso reflejado en una cookie, conviertes el oversize bypass en DoS persistente por víctima — cada request futura de la víctima trae la cookie payload, el WAF bloquea, la app es inaccesible para ella durante el cookie TTL (1 día a 1 mes). Combinado con XSS para entrega remota → DoS masivo + targeting selectivo.

1. El concepto core

Setup: WAF (Cloudflare/Akamai/AWS) protege un site. El WAF tiene límite de inspección:

Si el body excede ese límite y la WAF está configurada con fail-open (default en Cloudflare/AWS WAF) → la inspección se salta, el origin recibe la request completa.

Esto, por sí solo, ya es bypass para SQLi/XSS clásicos. El twist del DoS-via-WAF: si el payload se refleja en una cookie que la app retorna en el Set-Cookie, las futuras peticiones del user llevan esa cookie y el WAF sí las inspecciona (Headers/Cookies typically tienen otro límite, normalmente más bajo). Una vez detectada cookie maliciosa → WAF bloquea → app inaccesible.

2. Los componentes del ataque

Real-world: parámetros tipo tracking_id, last_search, marketing_source, user_preference que la app guarda en una cookie persistente para analytics o personalización.