Existe un viejo truco que con sorprendente regularidad aparece en los informes de pentest: algunas pantallas web analizan solo los primeros n bytes del cuerpo de la petición HTTP. Todo lo que sea más largo puede pasar «tal cual» hasta la aplicación. De ahí la idea: añadir al inicio del cuerpo de la petición un gran bloque de datos neutrales y ocultar la carga útil más adelante en el flujo. Si el filtro no lee hasta el final, simplemente no ve el «aguijón».
Suena casi a magia, pero no lo es, sino un compromiso de ingeniería. En la vida real un WAF tiene límites estrictos de buffer y tiempo de análisis, sobre todo con tráfico intenso. Los desarrolladores equilibran la profundidad de la comprobación y el rendimiento. En algunos sitios hay un umbral en el tamaño del cuerpo inspeccionado, en otros se simplifican las reglas para cargas largas. Como resultado surge una ventana en la que se pueden colar cargas útiles específicas.
Y sí, el truco no es universal: las soluciones modernas saben procesar el flujo en partes, reensamblar fragmentos, descomprimir adjuntos y reconocer «suplantaciones de formulario». Pero los modos extremos y las configuraciones exóticas aparecen con más frecuencia de la deseada. Especialmente en cadenas formadas por CDN, balanceadores de capa 7 y la propia aplicación, donde un componente confía en el siguiente sin verificación adicional.
Expliquemos cómo funciona este enfoque a nivel conceptual, dónde están las zonas vulnerables, cómo probar legal y seguramente sus sistemas y qué pueden hacer los equipos azules. Una aclaración importante: más abajo no hay instrucciones paso a paso para eludir defensas ni ejemplos de explotación — solo panorama, metodología y defensa. Si usted está del lado «azul», esto le será incluso más útil: entender el truco permite cerrarlo correctamente.
Cómo funciona el truco de los límites: sin magia ni heroísmos
En el fondo está la suposición de que el WAF no siempre analiza todo el volumen del cuerpo de la petición HTTP (POST, PUT, PATCH, etc.) y corta el flujo según un umbral. Puede ser un número fijo de bytes, una regla dinámica según el tipo de contenido, o un tratamiento especial para cargas grandes. Para el firewall web es una forma de seguir siendo rápido y no sobrecargar la aplicación.
El atacante aprovecha esta economía: construye una petición con un «prólogo» de datos neutrales y después coloca la carga útil. El filtro solo ve el «prólogo», lo ignora y deja pasar el flujo. En el lado de la aplicación la carga útil se procesa ya sin supervisión. Si a nivel de la lógica de negocio no hay validadores, normalización y límites de patrones permitidos, el problema está cerca.
¿Por qué funciona? Primero, muchas firmas históricamente se orientan a los primeros bytes y al tamaño «típico» del cuerpo de un formulario. Segundo, la descompresión y decodificación (gzip, deflate, base64) consumen recursos y a menudo se desactivan en el perímetro. Tercero, los proxies frontales y los CDN no siempre informan correctamente al backend el tamaño y tipo real del contenido, y el WAF confía en el upstream. Cuanto más complejo sea el trayecto, más probabilidades de desajuste.
Caso aparte es la entrada fragmentada: codificación chunked en HTTP/1.1, tramas DATA en HTTP/2, tráfico mixto a través de proxies intermedios. Si la inspección solo está implementada como «bufferiza los primeros X bytes y compáralos con firmas», la entrega por flujo con un «largo prólogo» amplía la ventana para el ataque.
La conclusión es simple: si parte del tráfico no se inspecciona en profundidad, el «prólogo» se convierte en una pantalla. A este nivel conviene mantener el foco en el problema procesal: no en los «bytes mágicos», sino en el desajuste entre la profundidad de inspección y el nivel de riesgo.
Qué es la herramienta nowafpls y cómo es útil en pruebas legales
El año pasado el equipo de Assetnote publicó una herramienta minimalista para investigación y pentests: nowafpls. Es una extensión para herramientas proxy que ayuda a construir peticiones con un «prólogo» controlado y a observar cómo cambia el comportamiento del filtrado. Conceptualmente es un asistente muy sencillo para comprobar la hipótesis «¿y si el WAF solo mira los primeros n bytes?».
La utilidad está en que elimina la rutina: no hay que rellenar manualmente el cuerpo de la petición ni temer romper el formato. En laboratorio o en una prueba de seguridad autorizada, usted ajusta el «ruido de fondo» y observa dos métricas: qué ve el filtro en los logs y cómo responde la aplicación. Esto ayuda a determinar si merece la pena profundizar y activar herramientas de análisis más exhaustivas.
Importante: no publicamos instrucciones de explotación. Cualquier acción con herramientas que simulan eludir defensas solo está permitida con permiso escrito del propietario del sistema y dentro del alcance del plan de pruebas aprobado. Para detalles de instalación y uso remítase a la documentación oficial del proyecto —es suficientemente clara y no necesita reproducirse aquí. Enlace al repositorio: github.com/assetnote/nowafpls.
Si trabaja con Burp o Caido, la idea es la misma: la extensión añade una «capa» al repeater para experimentar con el volumen de inserción y observar la reacción. Desde el punto de vista profesional es simplemente otra herramienta de prueba, como un checklist para distintas codificaciones, cabeceras de cacheo y tipos multipart. Ni más ni menos.
Un consejo honesto: trate estas utilidades como indicadores, no como «llaves mágicas». Su objetivo es señalar zonas sospechosas en la configuración. El trabajo serio empieza cuando entran en juego desarrolladores, SRE y equipos de seguridad para alinear el trayecto: desde el CDN y los balanceadores hasta el framework y los validadores de negocio.
Ética y metodología: cómo probar sin perder la calma
Cualquier verificación del perímetro para evaluar la resistencia aludir al WAF es una zona de alta responsabilidad. A diferencia de la validación habitual de formularios, aquí se crean proposicionalmente peticiones atípicas y pesadas para ver cómo responde la infraestructura. Hacerlo sin mandato es como comprobar las cerraduras del vecino «por curiosidad». Por eso la primera regla es obvia: permiso por escrito y un plan de pruebas acordado.
La segunda regla es la minimización del impacto. Trabaje en entornos de ensayo y en ventanas de baja carga, use marcadores seguros en lugar de cargas útiles reales, notifique previamente a los equipos de monitorización para que no confundan sus pruebas con un incidente. Los logs serán útiles: registre cabeceras, tiempos, respuestas y el comportamiento de pasos intermedios.
La tercera es la reproducibilidad. Toda observación debe repetirse: cambie solo un parámetro a la vez, lleve un protocolo y capture trazas de red en una zona autorizada. Es tedioso, pero luego lo agradecerá cuando tenga que defender conclusiones ante el propietario del producto o el integrador del WAF.
La cuarta son los límites del escenario. No profundice en la lógica de negocio si el objetivo es comprobar únicamente la «profundidad de visión» del filtro. No intente explotar vulnerabilidades que no estén acordadas: de una prueba limitada de evasión es fácil pasar a un ejercicio completo de Red Team, y eso implica otros riesgos y acuerdos.
Y la quinta es la comunicación. Un hallazgo bien descrito es la mitad del éxito. Al cliente le importan menos los bytes y más respuestas claras: cuál es el riesgo, dónde están las responsabilidades (CDN, WAF, aplicación) y qué acciones concretas tomar. Cuanto más claro y sereno explique esto, más rápido se corregirá.
Qué deben hacer los equipos azules: detección y contramedidas
Si usted está en operaciones o seguridad, la buena noticia es que el truco del «prólogo largo» suele dejar rastro en la telemetría. La mala es que, con umbrales mal ajustados, puede pasar desapercibido en el ruido. Se necesitan medidas técnicas y de proceso. Empecemos por la observabilidad: aprenda a ver cuerpos de petición grandes y distribuciones de tamaño atípicas por endpoint. La mayoría de ataques van dirigidos a un conjunto reducido de rutas.
Después —correlación. Compare lo que vio el perímetro (logs del WAF/CDN) con lo que vio el backend (access log de la aplicación, APM). Cualquier discrepancia en tamaño o tipo de contenido es señal de alarma. Heurísticas sencillas mejoran la visibilidad: cambios bruscos en el tamaño medio del cuerpo, picos de peticiones grandes muy similares, aumento de la proporción de formularios largos en horas de baja actividad.
Las contramedidas dependen de la pila, pero los principios básicos son comunes. Primero, active la inspección completa del cuerpo en rutas sensibles: autorización, subida de archivos, formatos serializados. Mejor sacrificar rendimiento allí donde el riesgo es alto que resolver incidentes después. Segundo, alinee el trayecto: acuerde quién descomprime qué y dónde, para evitar la «ceguera doble» entre CDN, proxy y WAF.
Tercero, implemente validadores en la aplicación. El WAF es solo la primera línea. Normalización de entradas, esquemas estrictos para JSON/XML, listas blancas de campos y tamaños permitidos, verificación de cabeceras y coherencia entre Content-Type y el contenido real son las cosas aburridas que más salvan. Y por supuesto límites: tamaños máximos, timeouts y mecanismos de back-pressure.
Finalmente, ajustes operativos. Experimente con límites y perfiles en el propio WAF: en zonas sensibles aumente la profundidad de análisis, prohíba rutas «simplificadas» para cuerpos largos e active la decodificación e inspección tras la descompresión. Compruebe también cómo se comporta la solución con peticiones fragmentadas (chunked, HTTP/2) y si realmente «ve» el contenido después del prólogo.
| Síntoma | Qué observar | Por qué importa |
|---|---|---|
| Muchas peticiones POST grandes a un mismo endpoint | Distribución de tamaños del cuerpo, tiempo de respuesta, correspondencia de patrones | Señal de intento de «empujar» lo malicioso hacia la cola del cuerpo |
| Desajuste de tamaños entre WAF y la aplicación | Logs del perímetro vs access logs del backend | Indicador de inspección incompleta o estratificación del trayecto |
| Formularios multipart anormalmente largos | Parseo del boundary, número de partes, campos no rellenados | Intento de ocultar la carga útil entre partes «vacías» |
| Compresiones sospechosas |
Correlación de Content-Encoding y el contenido real
|
Ocultamiento de la carga útil dentro de empaquetados para evitar la decodificación |
Lista rápida y conclusión
Para cerrar el asunto en la práctica, tenga en mente cinco puntos sencillos. Son aburridos, pero funcionan una y otra vez y reducen mucho la probabilidad de sorpresas desagradables.
- Visibilidad: implemente métricas económicas pero informativas sobre tamaños de cuerpos de petición y por rutas concretas. Sin eso está ciego.
- Alineación del trayecto: acuerde quién descomprime, quién normaliza y quién valida. Elimine las «zonas de nadie» entre CDN, proxy, WAF y aplicación.
- Profundidad en zonas sensibles: autorización, subidas y formatos serializados — máxima verificación y mínimos compromisos.
- Validación estricta en el backend: esquemas, listas blancas, correspondencia de tipos y límites de tamaño — la clásica rutina que protege.
- Gestión operativa: perfiles de WAF para rutas de riesgo, inspección tras descompresión y tratamiento correcto de chunked/HTTP/2.
Una reflexión final. «Basura al inicio de la petición» no es «magia hacker», sino síntoma de deuda técnica en el perímetro. No se arregla a martillazos con firmas; se corrige con una arquitectura transparente y sentido común. Si es pentester — documente las observaciones con rigor y ética, destacando riesgo y zona de responsabilidad. Si está en operaciones — no dude en aumentar la profundidad de verificación donde hay datos y dinero en juego. Para detalles de herramientas de investigación consulte siempre sus guías oficiales: nowafpls en GitHub, y para metodología consulte OWASP WSTG. Sin fanatismo, pero sin autocomplacencia.
Descargo de responsabilidad. No puedo proporcionar instrucciones paso a paso para instalar o usar herramientas destinadas a eludir defensas. Use la información de este artículo exclusivamente para mejorar la resistencia de sus sistemas y llevar a cabo pruebas legales con el consentimiento por escrito del propietario de los recursos.
