WAF Bypass | The Hack Sparrow

What it is

A WAF (or similar filter) blocks the 'obvious' shape of a payload, but the underlying vulnerability is completely untouched — the WAF is pattern-matching on syntax, not understanding intent, so a differently-encoded or restructured payload sails straight through.

Why it matters

It turns an already-fixed-looking finding back into a live one, and it's usually the difference between a program dismissing a report as 'already mitigated' and accepting it as critical.

Where to look

Anywhere a payload gets a generic 403/406 block page instead of the app's normal error handling — that mismatch is the signature of a WAF sitting in front, not application logic

How I test it

Confirm it's actually a WAF: does the block page differ from the app's own error pages? Does it trigger on keywords rather than on malformed syntax?
Try case variation, whitespace/comment insertion, and alternate encodings — URL, double URL, Unicode, HTML entities.
Try HTTP parameter pollution — repeating the same parameter name with different values.
Try wrapping the payload in a format the WAF doesn't parse but the backend does — nested encoding, an unexpected Content-Type, JSON where XML was expected or vice versa.
Once a variant slips through, re-confirm the original vulnerability's impact still holds with the modified payload — a bypass without impact is just a curiosity.

Hunting checklist

Confirmed the block is coming from a WAF, not app logic
Tried case/whitespace/comment variations
Tried at least two encoding schemes
Tried parameter pollution
Tried an alternate content wrapping/Content-Type
Re-confirmed the underlying vulnerability still fires with the bypass payload

Evidence to collect

The blocked payload and its block response
The bypass payload and its accepted response
Proof the underlying vulnerability still triggers (screenshot/response showing the actual impact, not just '200 OK')

Recommended fix

Fix the underlying vulnerability — a WAF rule is not a patch
Normalize and decode input consistently before both the WAF and the application evaluate it, so they see the same thing
Treat WAF rules as defense in depth, never as the only control

Qué es

Un WAF (u otro filtro similar) bloquea la forma 'obvia' de un payload, pero la vulnerabilidad de fondo sigue intacta — el WAF hace pattern-matching sobre sintaxis, no entiende la intención, así que un payload codificado o reestructurado de otra forma pasa sin problema.

Por qué importa

Convierte un hallazgo que parecía ya corregido en algo vigente de nuevo, y suele ser la diferencia entre que un programa descarte un reporte como 'ya mitigado' y que lo acepte como crítico.

Dónde buscar

Cualquier sitio donde un payload reciba una página de bloqueo genérica 403/406 en vez del manejo de errores normal de la app — esa discrepancia es la firma de un WAF por delante, no de la lógica de la aplicación

Cómo lo pruebo

Confirma que es de verdad un WAF: ¿la página de bloqueo es distinta de las páginas de error propias de la app? ¿Se dispara por palabras clave más que por sintaxis mal formada?
Prueba variación de mayúsculas/minúsculas, inserción de espacios/comentarios, y encodings alternativos — URL, doble URL, Unicode, entidades HTML.
Prueba HTTP parameter pollution — repetir el mismo nombre de parámetro con valores distintos.
Prueba envolver el payload en un formato que el WAF no parsea pero el backend sí — encoding anidado, un Content-Type inesperado, JSON donde se esperaba XML o viceversa.
Cuando una variante pase, reconfirma que el impacto de la vulnerabilidad original se sostiene con el payload modificado — un bypass sin impacto es solo una curiosidad.

Checklist de hunting

Confirmado que el bloqueo viene de un WAF, no de la lógica de la app
Probadas variaciones de mayúsculas/espacios/comentarios
Probados al menos dos esquemas de encoding
Probado parameter pollution
Probado un envoltorio de contenido/Content-Type alternativo
Reconfirmado que la vulnerabilidad de fondo se sigue disparando con el payload de bypass

Evidencias para el reporte

El payload bloqueado y su respuesta de bloqueo
El payload de bypass y su respuesta aceptada
Prueba de que la vulnerabilidad de fondo sigue disparándose (captura/respuesta mostrando el impacto real, no solo un '200 OK')

Mitigación

Corregir la vulnerabilidad de fondo — una regla de WAF no es un parche
Normalizar y decodificar el input de forma consistente antes de que lo evalúen tanto el WAF como la aplicación, para que ambos vean lo mismo
Tratar las reglas de WAF como defensa en profundidad, nunca como único control