WAF y protección inyectable
1) Por qué WAF en la era de la API
Incluso con una validación y parametrización estrictas, las inyecciones surgen de:- «largas colas» integraciones (código hereditario, webhooks de afiliados),
- discrepancias de parsing (proxy ↔ framework),
- nuevas técnicas de protocolo/ofuscación de circunvalación.
- WAF da una frontera de falla temprana (early deny) y un «parche virtual» antes de la liberación del código, pero no reemplaza el desarrollo seguro.
2) Modelo de amenazas: tipos de inyecciones para API
SQLi/ORMi: classic/boolean/time-based/stacked; blind a través de los retrasos.
NoSQLi (Mongo/Elastic): operadores '$ ne/$ gt', inyección JSON, regex-DoS.
Inyección de comando/RCE: shell-metasimvoles, sustitución de argumentos, deserialización unsafe → código exec.
XXE: entidades externas/DTD en XML.
SSRF: acceso al '169. 254. 169. 254 '/servicios internos; DNS-rebinding.
Template Injection: Jinja/Thymeleaf/Handlebars; `{{77}}`.
LDAP/EL Injection, XPath, Header injection (CRLF), Path traversal.
GraphQL es específico: '__ schema' introspección, profundidad/complejidad de las consultas.
JSON/JS-específico: Prototipo Pollution ('__ proto __', 'constructor').
gRPC/Protobuf: mensajes sobreestimados, campo smuggling a través de circuitos de no coincidencia.
3) Arquitecturas WAF
Perímetro CDN-WAF: filtrado geo/ASN rápido, control bot básico, caché/antipadding.
Perímetro L7 (NGINX/Envoy/APISIX/Kong): parsing preciso, reglas profundas, integración con PDP/límites.
Sidkar/mash (Envoy WASM/Filter): un servicio de PER cercano a los datos menos falsos positivos para las API internas.
Recomendación: modelo de doble capa (CDN-WAF + L7 WAF).
4) Parking, normalización y anti-bypass
WAF debe ver la misma representación canónica que la aplicación:- Normalización de rutas ('/a/% 2e% 2e/b '→ fallo),' UTF-8 '/Unicode confusables, NUL bytes.
- Decodificación unificada: URL-/HTML-/Unicode-/Capas Base64, prohibición de decodificación dual.
- Restricciones: 'max _ headers', 'max _ header _ size', 'max _ body _ size', 'max _ args', profundidad JSON, límite de piezas multipart, prohibición de bombas 2x gzip/zip.
- Políticas Content-Type: 'application/json' sólo en endpoints JSON; rechazar «polyglot».
5) Modelos de reglas
Negativo (firmas): OWASP CRS (SQLi/XSS/SSRF/Java/Node RCE, etc.). Comienzo rápido.
Positivo (allow-list): esquemas estrictos (JSON Schema/Protobuf), tipos y rangos; a lo largo de las rutas.
Anormal/Screening: sumando los signos «sospechosos» → el umbral de bloqueo.
Contextual: diferentes perfiles para 'POST/payments' y 'GET/status'; menos FP.
6) Bloques de protección (en el ligamento)
1. Esquemas y tipos: validación JSON Schema/Protobuf a la lógica empresarial.
2. Parametrización: expresiones preparadas, vendajes ORM, prohibición de concatenación.
3. Salida-escape: HTML/JS/SQL contextualmente.
4. Políticas corporales: Content-Type, tamaño, restricciones multipart, prohibición de binarios en lápices JSON.
5. Reglas WAF: CRS + personalizado negativo/positivo.
6. Rate/Quota/Concurrency: supresión de brute/tortuga DDoS, capchas protectoras/challenges para formas públicas.
7. Aislamiento de redes: políticas de egresos para SSRF (deny RFC1918/metadata/Unix sockets).
8. Headers-higiene: 'X-Content-Type-Options: nosniff', 'Content-Security-Policy' para el frente, 'Referrer-Policy'.
9. GraphQL guard: límites de profundidad/complejidad, prohibición de la introspección en la venta (o gate de rol).
7) Ejemplos de configuraciones
7. 1 NGINX + ModSecurity (OWASP CRS)
nginx load_module modules/ngx_http_modsecurity_module.so;
modsecurity on;
modsecurity_rules_file /etc/modsecurity/modsecurity.conf;
modsecurity_rules '
SecRuleEngine On
Подключаем CRS
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/.conf
Позитивные правила: только JSON и ограничение размера
SecRule REQUEST_HEADERS:Content-Type "!@rx ^application/json($;)" "id:10001,phase:1,deny,status:415,msg:'Only JSON allowed'"
SecRequestBodyLimit 1048576
SecRequestBodyNoFilesLimit 1048576
Блок локальных адресов (SSRF)
SecRule REQUEST_HEADERS:Host "@ipmatch 127.0.0.0/8 10.0.0.0/8 169.254.0.0/16 192.168.0.0/16" \
"id:10002,phase:1,deny,status:403,msg:'Blocked private range'"
';
server {
listen 443 ssl http2;
server_name api.example.com;
client_max_body_size 1m;
proxy_request_buffering on; # защита от slow-POST proxy_read_timeout 300ms;
proxy_connect_timeout 100ms;
location /v1/ {
proxy_pass http://app_backends;
}
}
7. 2 Envoy HTTP WAF (WASM + JSON Schema + SSRF egress-deny)
yaml http_filters:
- name: envoy.filters.http.wasm typed_config:
config:
vm_config: { vm_id: waf, code: { local: { filename: /plugins/waf.wasm } } }
configuration:
"@type": type.googleapis.com/google.protobuf.Struct value:
crs_profile: "strict"
deny_patterns: ["(?i)union.select", "(?i)(sleep benchmark)\\s\\("]
json_schema:
"/v1/payments:create": "/schemas/payments_create.json"
- name: envoy.filters.http.router
Egress SSRF guard (L4): deny private ranges from gateway filter_chains:
- filters:
- name: envoy.filters.network.tcp_proxy typed_config:
stat_prefix: egress cluster: internet access_log: [...]
tunneling_config:
hostname: "%REQ(:authority)%"
transport_socket:
name: envoy.transport_sockets.tls
7. 3 APISIX: restricción de tipos y anti-ofuscación
yaml routes:
- uri: /v1/
plugins:
cors: { allow_origins: "https://app.example.com" }
request-validation:
body_schema:
{"type":"object","properties":{"amount":{"type":"number","minimum":1}},"required":["amount"]}
uri-blocker:
block_rules: ["..","%2e%2e","%2f..","\\x00"] # traversal/NULL proxy-rewrite:
headers:
set:
X-Content-Type-Options: "nosniff"
8) Afinación y reducción de falsos positivos (FP)
Perfiles per-route: reglas estrictas sólo cuando son adecuadas (por ejemplo, '/search 'permite '/'%').
Shadow/Report-Only: lógica de activación antes de la unidad; A/B comparación métrica.
Listas personalizadas allow para parámetros legítimos «ruidosos».
Puntuación: bloquear sólo cuando la suma de indicadores> umbral.
Experimentos: un pequeño porcentaje del tráfico a las nuevas reglas → auto-rollback.
9) Observabilidad y fuerza
Метрики: `waf_block_total{rule}`, `waf_anomaly_score`, `request_body_rejected_total`, `schema_violation_total`, `ssrf_block_total`.
Registros (sampleados): regla, parte de la consulta (editada), 'trace _ id', 'tenant', 'route', causa. Enmascarar PII/secretos.
Dashboards: top rules/paths, FP cluster, dinámica post-lanzamiento.
Incidentes: guardar artefactos (payload, pcap si es necesario), productos RCA y «parches virtuales».
10) Pruebas y escenarios de caos
Chasis de bypass WAF (SQLi/XSS/SSRF), codificaciones dobles/triples mezcladas por Unicode.
Diferencias de parsing: envía un payload donde el proxy y el framework pueden divergir (tomas de parámetros, matrices, ';' vs '&').
Slow-POST/oversize, bombas zip, formas de múltiples partes, boundary erróneo.
GraphQL: generador de profundidad/complejidad, verificación de límites y tiempos de espera.
11) Antipattern
«Encendieron el CRS y se olvidaron»: sin esquemas, sin afinar las rutas.
Registros con el cuerpo crudo de la solicitud y PII.
No hay normalización/límites de tamaño → bypass, DoS en el parsing.
Pase de 'Content-Type '/cheques de charset → un ataque políglota.
No hay filtros egress → SSRF al metadato de la nube.
Un perfil común para las API externas e internas.
Excepciones incontrolables «para el compañero» → agujeros en el perímetro.
12) Especificidad de iGaming/finanzas
Perfiles reforzados en los bolígrafos de pago/salida: pequeños límites de cuerpo, esquemas estrictos, listas deny para recuento/IBAN/campos PAN (enmascaramiento, validaciones de formato).
Webhooks de PSP/KYC: firma HMAC/TLS mutual, perfiles WAF separados, anti-replay.
Filtros Geo/ASN y límites de comportamiento para evitar registros de bot y bonus abius.
Registros de incidentes sin cambios (auditoría), almacenamiento por jurisdicción.
13) Lista de comprobación prod
- WAF de doble capa (CDN + L7), normalización única y límites de tamaño.
- OWASP CRS habilitado, reglas personalizadas per-route; JSON Schema/Protobuf en lápices de escritura.
- Políticas Content-Type/charset; prohibición de doble decodificación/NULL/traversal.
- Bloque SSRF-egress en bandas privadas/metadata; Protección DNS-rebinding.
- Rate/Quota/Concurrency y anti-bot (Challenges) en formularios públicos.
- Shadow/Report-Only → canary → enforce; auto-rollback por SLO y FP.
- Métricas/registros/tracks enmascarados; dashboards «top rules »/FP.
- Playbucks de parche virtual y RCA; pruebas regulares de circunvalación.
- Perfiles individuales para PSP/KYC webhooks, bolígrafos de pago y API internas.
14) TL; DR
Construya la protección por capas: normalización y límites → esquemas/tipos → parametrización de → WAF (CRS + casta) → filtros rate/bot → bloque egress SSRF. Afine per-route, ejecute nuevas reglas en shadow → canary, siga las métricas/FP y haga «parches virtuales» antes de fix de código. Para las rutas de pago/webhook: perfiles estrictos individuales, HMAC/mTLS y ventanas de confianza mínimas.