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.
La checklist que repaso en cada objetivo nuevo
47 comprobaciones ordenadas por coste: primero lo que te puede meter en un lío, luego lo barato, y al final lo caro — que es donde están los bounties grandes. Te la mando al correo ahora mismo.
Te das de baja en un clic, desde cualquier correo.
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.
