GH GambleHub

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.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.