La comunidad
Dentro se pregunta, se enseña lo que se ha encontrado y se resuelve en grupo lo que atascaría a cualquiera solo. Se entra gratis: sin cuenta, sin plan y sin dejar el correo.
Es gratis y abierto. No hace falta tener cuenta en BBLABS para entrar.
Qué es un WAF, cómo fingerprintearlo y las técnicas de bypass más usadas —encoding, alternancia de mayúsculas, comentarios inline, HPP, chunked encoding y payloads alternativos— aplicadas a XSS y SQL injection. Enfoque práctico y estrictamente ético, dentro de scope.
Gorka El Bochi
Fundador de BBLABS
Deja de leer sobre bugs y empieza a cazarlos
Sin tarjeta · Academy gratis · cancela cuando quieras
Respuesta rápida: Un WAF (Web Application Firewall) filtra peticiones buscando patrones maliciosos. Un "bypass" consiste en reescribir tu carga para que no coincida con esas firmas sin perder su efecto: codificándola, alternando mayúsculas, insertando comentarios, dividiéndola con HPP o usando sintaxis alternativa. Se hace solo en objetivos autorizados y para demostrar que la vulnerabilidad subyacente existe pese al filtro.
Un WAF es una capa que inspecciona el tráfico HTTP y bloquea lo que parece un ataque, comparándolo con firmas y reglas (por ejemplo, "si ves <script> o UNION SELECT, bloquea"). Es una defensa útil, pero tiene una debilidad de fondo: filtra por patrones, no entiende la intención. Si consigues expresar la misma carga con una forma que la regla no reconoce pero el navegador o la base de datos sí interpretan, pasas.
Importante para no engañarte: un WAF bypass no es en sí una vulnerabilidad. Es la demostración de que una vulnerabilidad real (XSS, SQLi…) sigue siendo explotable pese al filtro. Sin fallo detrás, evadir el WAF no vale nada. Lo que reportas es el fallo; el bypass es la prueba de que el WAF no lo mitiga.
Ética por delante: todo esto se practica en laboratorios propios o en programas con scope que lo permita. Evadir defensas de un sistema sin autorización es ilegal. Aquí el objetivo es entender la técnica para reportar y para construir defensas mejores.
Antes de evadir conviene saber a qué categoría te enfrentas, porque cada una tiene puntos ciegos distintos:
La clave común: todos, en mayor o menor grado, deciden con información incompleta. Cuanto más se apoye un WAF en firmas rígidas, más margen tienes para reescribir la carga sin que la reconozca.
Antes de evadir, identifica a qué te enfrentas. Cada WAF tiene tics reconocibles:
?q=<script>alert(1)</script>) y observa: ¿un 403, un 406, un "Access Denied", una página de challenge? El formato delata al producto.wafw00f es el clásico para fingerprintear el producto; sqlmap tiene --identify-waf. Te dan una pista del vendor, y cada vendor tiene bypasses documentados.Saber qué WAF hay delante te ahorra horas: orientas las técnicas a sus puntos ciegos conocidos en lugar de probar a ciegas.
No hay una bala de plata: se combina y se itera. Estas son las familias que más funcionan.
Muchas reglas buscan la cadena literal. Codifícala y quizá la regla no la vea, pero el servidor la decodifica antes de usarla:
Original: <script>
URL enc: %3Cscript%3E
Doble enc: %253Cscript%253E
HTML enc: <script> (según contexto)
Para SQLi, el URL-encoding de caracteres clave o el uso de codificación hexadecimal de cadenas es un recurso habitual.
Si la firma busca union select en minúsculas y el motor SQL no distingue mayúsculas, alterna:
UnIoN SeLeCt password FROM users
Lo mismo con XSS: <ScRiPt> puede saltarse una regla que solo mira <script> en minúsculas.
En SQL, los comentarios inline de MySQL parten palabras clave que el WAF busca completas, sin romper la consulta:
UNI/**/ON SEL/**/ECT
1/**/OR/**/1=1
En XSS, insertar caracteres que el navegador tolera dentro del tag puede romper la firma sin romper la ejecución.
La forma más robusta: no uses el payload de manual. Para XSS, si <script> está bloqueado, hay decenas de vectores con otros tags y manejadores de eventos:
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<body onpageshow=alert(1)>
Para SQLi, si OR 1=1 está filtrado, existen equivalentes lógicos y funciones alternativas que consiguen el mismo efecto. Entender la vulnerabilidad por dentro (en Academy) es lo que te permite improvisar vectores en vez de depender de una lista.
Enviar el mismo parámetro varias veces puede confundir al WAF y al back-end sobre cuál procesar. Si el WAF inspecciona la primera ocurrencia y el servidor concatena o toma la última, puedes partir la carga entre varias apariciones del parámetro y colar cada mitad por separado.
Fragmentar el cuerpo con Transfer-Encoding: chunked, jugar con espacios, saltos de línea o el Content-Type puede impedir que el WAF reconstruya la carga tal y como la ve el back-end. Es un terreno que conecta con técnicas de desincronización como el request smuggling.
Muchas firmas esperan un espacio literal entre tokens (UNION SELECT). SQL acepta otros separadores que el WAF puede no contemplar: tabuladores, saltos de línea, comentarios (/**/), o caracteres de control. En SQL también sirven paréntesis para prescindir de espacios:
UNION(SELECT(password)FROM(users))
Otra vía es la normalización unicode: si el back-end normaliza ciertos caracteres unicode a su equivalente ASCII después de que el WAF haya inspeccionado, un carácter "raro" pasa el filtro y luego se convierte en el peligroso. Lo mismo con overlong encodings o el mal manejo de bytes nulos en algunos stacks. La idea de fondo se repite: explota cualquier diferencia entre lo que ve el WAF y lo que interpreta la aplicación.
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.
Evadir un WAF es un proceso empírico:
Herramientas como Burp Intruder (para automatizar variaciones) y los tamper scripts de sqlmap (para SQLi automatizada, ver el tutorial de sqlmap) aceleran el paso 5, pero el criterio de qué probar es tuyo.
Probar decenas de transformaciones a mano es tedioso, así que se automatiza con cabeza. En Burp Intruder puedes cargar una lista de variantes de un mismo payload (mayúsculas, comentarios, encoding, sintaxis alternativa) y lanzarlas contra el parámetro, observando qué respuestas no disparan el bloqueo del WAF. La columna de longitud y código de estado te dice de un vistazo cuáles pasaron.
Para SQLi, los tamper scripts de sqlmap encadenan estas transformaciones automáticamente (--tamper=space2comment,randomcase,between), y --identify-waf orienta qué combinación probar. Para XSS, colecciones de payloads como las de PayloadsAllTheThings te dan cientos de vectores listos para iterar.
Aviso importante: automatizar bypass genera mucho ruido y puede activar rate limiting o baneos de IP. Controla la velocidad, rota si el programa lo permite y no conviertas la búsqueda en un ataque de fuerza bruta que degrade el servicio. La automatización acelera, pero el objetivo sigue siendo entender por qué una variante concreta evade el filtro, no lanzar miles a ciegas.
Un fallo que el WAF bloquea con la carga de manual pero que tú demuestras explotable con un bypass vale mucho más en un reporte: pruebas que la mitigación es insuficiente y que el riesgo real persiste. Los equipos de seguridad lo valoran porque les señala que su defensa da falsa sensación de seguridad.
Y del otro lado: entender los bypasses también te enseña a defender. Un WAF es una capa, no una solución; la corrección de verdad es arreglar la vulnerabilidad en el código, no confiar en el filtro.
¿Evadir un WAF es ilegal?
Depende del objetivo. En tus labs o en un programa de bug bounty con scope que lo permita, es una técnica legítima para demostrar que una vulnerabilidad sigue explotable. Contra un sistema sin autorización, es ilegal.
¿Un WAF bypass cuenta como vulnerabilidad reportable?
Por sí solo, normalmente no. Lo reportable es la vulnerabilidad de fondo (XSS, SQLi…); el bypass es la prueba de que el WAF no la mitiga. Un fallo explotable pese al WAF vale más porque demuestra que la defensa da falsa seguridad.
¿Existe un payload universal que evada cualquier WAF?
No. Cada WAF y cada configuración es distinta. Evadir es un proceso empírico de fingerprintear, observar qué bloquea e iterar combinando técnicas. Quien te venda un "bypass mágico" te vende humo.
¿Cómo se defiende de verdad una app frente a estos bypasses?
Arreglando la vulnerabilidad en el código: consultas parametrizadas contra SQLi, codificación de salida contextual contra XSS, validación estricta. El WAF es una capa de mitigación temporal, nunca la solución de fondo.
Los bypasses no se memorizan de una lista: se entrenan entendiendo la vulnerabilidad por debajo. Cuando sabes por qué un <img onerror> ejecuta o por qué un comentario inline no rompe una consulta SQL, generar variantes es natural. Estudia la teoría de XSS y SQLi, practica en labs que replican reportes reales y sigue una ruta ordenada. El WAF bypass es la prueba de que dominas la vulnerabilidad, no un truco aislado.
hunters entrenando
labs de hackeos reales
completaciones
pagados por estos bugs
Crea tu cuenta gratis y practica sobre labs basados en hackeos reales que pagaron miles de euros. La Academy es gratis para siempre.
Sin tarjeta · Academy gratis · cancela cuando quieras
Aprende a identificar y explotar vulnerabilidades IDOR (Insecure Direct Object Reference) en aplicaciones web. Desde los conceptos básicos hasta la escritura de reportes efectivos.
Explora las técnicas más comunes para atacar implementaciones inseguras de JSON Web Tokens: desde el algoritmo none hasta inyección de JKU/JWK.
Aprende a escalar vulnerabilidades SSRF desde una severidad baja hasta un impacto crítico. Técnicas de explotación, bypass de filtros y cadenas de ataque en entornos cloud.