DoS vía WAF body size — agotar inspection budget en Cloudflare/Akamai
Cómo abusar del límite de inspección de body en WAFs (Cloudflare 100kb, Akamai 32kb) para drenar budget de inspección y forzar bypass — útil tanto para evasión como para DoS controlado.
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:
| WAF | Límite inspección |
|---|---|
| Cloudflare Free | ~8 KB |
| Cloudflare Pro/Business | default bajo, hasta 1 MB con soporte |
| Cloudflare Enterprise | 128 KB |
| AWS WAF (ALB) | 8 KB |
| AWS WAF (CloudFront) | 16-64 KB |
| Akamai | ~16-32 KB típicamente |
| Imperva/Incapsula | configurable, default ~24 KB |
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
| Componente | Función |
|---|---|
| Endpoint POST con padding tolerado | Carrier del payload (bypass de body inspection) |
| Parameter que el server refleja en cookie | Vector de persistencia |
| Falta de CSRF protection | Permite delivery via HTML del atacante |
| WAF que inspecciona cookies en cada request | Engine del DoS posterior |
| Cookie TTL largo | Duración del DoS por víctima |
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.
Sigue leyendo el chain completo
La parte que falta incluye el PoC paso a paso, código de explotación y la cadena completa que llevó al impacto. Disponible para suscriptores.
Practica esto en un lab
Dos Via Waf Size
Sigue aprendiendo · cuenta gratis
Guarda tu progreso, desbloquea payloads avanzados y rankea tus flags.
Artículos relacionados
Client-side admin bypass — boolean manipulation + BAC en SPA moderna
Report real Quora: SPA con isAdmin boolean en localStorage que controla UI + backend que no valida server-side. Cómo encadenar boolean flip con BAC para admin takeover.
Cloudflare WAF — payload size bypass, oversized body, plan-specific limits
Bypass de Cloudflare WAF mediante exploitation de body size limits por plan (Free 100kb, Pro 100kb, Business 500kb, Enterprise 1mb): oversize payload trick + chunked transfer encoding.
Headless browsers — SSRF y RCE en endpoints que renderizan URLs
Endpoints que aceptan URLs para screenshots/PDF (Puppeteer, Playwright, wkhtmltopdf) son SSRF goldmine: cloud metadata, file://, gopher://, JS injection con XSS-to-RCE en chromium sandbox.
Contenido educativo de Kerb3r0ps. Úsalo solo sobre sistemas para los que tengas permiso. Volver al buscador.